WebAuthn keeps a passkey's private key off the server

The workload

Supporting passkeys is a build-layer decision, not a vendor bill: a founder's authentication stack, whether self-built or bought from a vendor elsewhere in this batch, must implement a published protocol rather than invent its own password-replacement scheme. The WebAuthn Level 3 specification, a W3C Recommendation developed jointly with the FIDO Alliance, defines what "supporting passkeys" means technically. As retrieved on 16 September 2026, it states, as verified standards-body text, that "a credential private key is bound to a particular authenticator" and "is expected to never be exposed to any other party, not even to the owner of the authenticator." Implementing this correctly is the workload: the private key material never transits the founder's servers at all.

What the documents show

The specification's own verified text states a credential, once created "at the behest of a WebAuthn Relying Party," can afterward "only be accessed by origins belonging to that Relying Party," the mechanism the standard relies on for phishing resistance, since a credential scoped to the genuine site's origin cannot be replayed against a look-alike domain. The FIDO Alliance's own specifications page adds, as a second verified source, that "FIDO2 is comprised of the W3C Web Authentication specification and corresponding Client-to-Authenticator Protocols (CTAP) from the FIDO Alliance," WebAuthn being the browser-facing half of the standard, with CTAP governing how a browser talks to a hardware key or platform authenticator. The Alliance's page also states "the protocols do not provide information that can be used by different online services to collaborate and track a user," a privacy property related to but distinct from phishing resistance.

The operating cost

Neither document states a licensing fee or per-credential cost for implementing WebAuthn; it is a royalty-free specification, not a paid product, so this batch's entries for Auth0, Clerk, WorkOS and Cognito are where the priced cost of running passkey-capable authentication appears, typically bundled into the same per-MAU or per-connection fee those vendors already charge. What the specification costs a founder is engineering time to implement or verify a vendor's claimed conformance, a workload this entry does not quantify since neither source states an hours figure; naming one would be an estimate not attempted here.

The stop condition

The specification names no sunset date or point at which support becomes unnecessary; as a living W3C Recommendation it remains in force until superseded. Editorially, the practical stop condition for a solo founder sits outside the standard: it is the point at which the chosen authentication vendor's own documentation confirms WebAuthn or passkey support, since verifying protocol-level conformance independently is not a task most one-person teams can perform.

• Does the chosen auth vendor state, in its own documentation, that it supports WebAuthn or passkeys specifically?
• Is the private key genuinely never transiting a server this founder controls, per the standard's own design?
• Does the product need CTAP-level hardware-key support, or is a phone or laptop's platform authenticator sufficient?

WebAuthn's phishing-resistance claim rests on origin-scoped credentials and non-exportable private keys, both stated in the standards bodies' own text; no adoption-rate figure for any population of users appears in either document, and none is claimed here.