When a website stores only the public key, a server breach does not expose reusable login secrets. An attacker may recover the public key, but that alone cannot authenticate to the account and cannot be reverse engineered into the private key. This design limits server side credential theft and shifts trust toward the user’s device or password manager.
Why Storing Only the Public Key Changes the Breach Equation
With passkeys, the server keeps a public key and a credential identifier, while the private key stays on the user’s device or in a password manager. That means a database breach usually exposes only verifiable public material, not a reusable secret. The practical effect is that credential theft becomes much harder to turn into account takeover, because the server no longer holds the thing an attacker needs to sign in.
What an Attacker Can and Cannot Do with the Public Key
A public key is designed to be shared. It can verify a signature, but it cannot create one, and it cannot be converted back into the private key. So a stolen public key does not let an attacker impersonate the user, replay the login, or mint a valid passkey assertion. The attack value is therefore very different from a stolen password or shared secret.
In practice, the remaining risk shifts away from server-side secret theft and toward other weaknesses around enrollment, recovery, and device trust. If an attacker compromises the user’s device, browser session, or recovery path, passkeys can still be abused through the surrounding identity process even though the server-side public key itself is not reusable for authentication.
Why This Is Stronger Than Traditional Password Storage
Traditional password storage creates a reusable server-side secret or a derivable verifier that still supports offline attack if exposed. Passkeys remove that dependency by making the server a verifier, not a custodian of the secret itself. That materially reduces the blast radius of a database breach and also reduces the value of credential stuffing, password spraying, and many phishing flows that depend on the user typing a shared secret.
For a clean implementation, the important design question is not whether the public key should be protected, but whether the system correctly binds the challenge, origin, and relying party ID so the assertion is only usable for the intended site. The public key alone is not the weakness, the surrounding authentication ceremony is where implementation errors can still create exposure.
Risk and Threat Considerations
The main security gain is that a server breach does not automatically become a login breach. However, organisations can still lose the protection if they treat passkeys as a drop-in replacement for passwords without hardening account recovery, phishing-resistant enrollment, and device trust controls.
Failure mechanism: The attacker does not need to break the cryptography, they only need to exploit the trust boundary around recovery, session reuse, or a weak fallback factor. If those paths remain weaker than the passkey flow, the account can still be taken over even when the server stores only the public key.
Impact: Public-key-only storage sharply limits reusable secret theft, but it does not eliminate account takeover risk from compromised devices, malicious recovery, or badly designed fallback authentication. The residual risk is concentrated in the identity lifecycle, not in the public key record itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkeys and phishing-resistant authentication are core digital identity concerns. |
| Recommendation — Use phishing-resistant authenticators and recovery rules that preserve the assurance level. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The question turns on storing and protecting authenticating material correctly. |
| IA-2 — Identification and Authentication (Organizational Users) | Passkeys are an authentication method for user sign-in and account access. | |
| Recommendation — Manage authenticators so only non-reusable public material is stored server-side. Require strong user authentication and block weaker fallback paths from bypassing it. | ||
| OWASP ASVS | V6 — Authentication | Passkey login behavior and assurance are verified through authentication requirements. |
| V7 — Session Management | A valid passkey login still depends on safe session establishment after authentication. | |
| Recommendation — Verify challenge binding, origin checks, and secure fallback authentication. Protect issued sessions so successful authentication is not undermined afterward. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Passkeys change how access is granted and how fallback access should be governed. |
| Recommendation — Enforce access paths that preserve phishing-resistant sign-in and limit weak fallback access. | ||
Practitioner Guidance
What to verify: Confirm that the implementation stores only public key material server-side, that each authentication uses fresh challenge-response binding, and that recovery paths do not silently reintroduce password-like fallback secrets. If any fallback can be used to bypass the passkey, treat the deployment as only partially phishing-resistant.
What practitioners underestimate: The public key being harmless does not mean the account is safe by default. The real control question is whether device possession, origin binding, and recovery governance are all strong enough that the weakest path is still harder to abuse than the passkey itself.
Practitioner takeaway: Public-key-only storage is valuable because it removes the server as a secret repository, but the security outcome depends on whether every alternate sign-in and recovery path preserves the same phishing-resistant standard.
Related resources from NHI Mgmt Group
- What is the difference between private key encryption and public key encryption for practitioners?
- How should security teams govern public key vs private key management at scale?
- Why do public and private key pairs reduce trust assumptions in authentication workflows?
- What breaks when a website does not properly manage its private key or certificate trust chain?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
