Updated October 13, 2026: An earlier version of this post argued that passkeys are a single point of trust that should not replace a second factor. That was wrong. Under NIST SP 800-63B-4, a passkey that requires the user to unlock it with a biometric or a PIN is treated as a multi-factor cryptographic authenticator on its own. We have rewritten the post to reflect what NIST actually says.
A widely shared essay titled "Passkeys are a trap. Do not use them" made the rounds on Hacker News this week. Its author is not arguing that passkeys are weak. The complaint is about control: that websites can use attestation to decide which devices and software are allowed to hold a passkey, that the many flavors of "passkey" are confusing, and that consumers have little voice in the standards process. Those are fair debates about user freedom. They are not evidence that passkeys fail as an authentication factor, and regulated organizations should not read them that way.
For organizations that must satisfy NIST SP 800-171, CMMC, HIPAA, or PCI DSS, the question that matters is narrower: does a passkey satisfy a multifactor authentication requirement, and what has to be true for it to do so? NIST has answered that question in writing, and the answer is mostly good news.
Key Takeaways
- NIST SP 800-63B-4 treats a passkey with user verification (a biometric or PIN unlock) as a multi-factor cryptographic authenticator, which satisfies Authentication Assurance Level 2 (AAL2) by itself.
- A passkey used without user verification still counts as one factor, a single-factor cryptographic authenticator ("something you have"), and can be paired with a password to reach AAL2.
- Passkeys are phishing-resistant because each key only works for the website that created it.
- Synced passkeys stop at AAL2: NIST says syncable authenticators shall not be used at AAL3. Hardware security keys that never export their keys remain the option for the highest assurance level.
- The real passkey risks are the cloud account that syncs the keys, account recovery, and whether the relying party enforces user verification, not the cryptography.
What a Passkey Actually Is
How Passkeys Work
Passkeys are built on the FIDO2 and WebAuthn standards. When a user registers, the device generates a key pair. The public key goes to the website. The private key stays with the user, either on a single device or inside a platform sync service such as a password manager or an operating system keychain. To sign in, the site sends a challenge, the authenticator signs it, and the site checks the signature against the public key it stored.
Two properties make this stronger than a password plus a code. First, no reusable secret ever crosses the network, so there is nothing for a credential-stuffing attack to replay. Second, the key is bound to the domain that created it. NIST describes passkeys as phishing-resistant for exactly this reason: the key pair's "use is constrained to the domain in which it was created," which "prevents a falsified web page from being able to capture and reuse an authenticator output."
Where the Second Factor Comes From
The most common misunderstanding about passkeys, and the one our earlier version of this post repeated, is that the device is the only thing being checked. It is not. Before most passkeys will sign anything, the device asks the user to unlock it with a fingerprint, a face scan, or a device PIN. WebAuthn calls this user verification, and the authenticator reports to the website whether it happened.
That gives a single sign-in two independent factors: something you have (the device or key that holds the private key) and something you know or are (the PIN or the biometric that unlocks it). This is the same model NIST has long used for smart cards and hardware tokens that require a PIN.
What NIST SP 800-63B-4 Says
NIST published the fourth revision of its Digital Identity Guidelines with a dedicated appendix on syncable authenticators, the category that covers synced passkeys. The relevant language is direct.
- On the user verification flag: it "indicates whether the authenticator can be treated as a multi-factor cryptographic authenticator."
- When that flag is not set: "If the user is not verified, agencies SHALL treat the authenticator as a single-factor cryptographic authenticator."
- On assurance level: "Syncable authenticators may be offered as a new option for applications that seek to implement up to AAL2."
- On the ceiling: "syncable authenticators SHALL NOT be used at AAL3."
- On protecting the sync account: "User access to authentication keys in the sync fabric SHALL be protected by AAL2-equivalent MFA."
At AAL2, NIST requires "either a multi-factor authenticator or a combination of two separate authentication factors." A user-verified passkey is the first option. A passkey without user verification plus a password is the second. Either way, the passkey is doing real authentication work. The guideline also requires verifiers to "offer at least one phishing-resistant authentication option at AAL2," and passkeys are the most practical way most organizations will meet that.
The primary source is NIST SP 800-63B-4, Appendix B and Section 2.2. The publication record is on the NIST Computer Security Resource Center.
Compliance Implications
NIST SP 800-171 and CMMC Level 2
Requirement 3.5.3 of NIST SP 800-171 Rev. 2, which CMMC Level 2 assesses as IA.L2-3.5.3, requires multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. The requirement is about factors, and a user-verified passkey supplies two of them. What an assessor will want to see is evidence that user verification is required, not merely available: the identity provider policy, the authentication method configuration, and sign-in logs that show the method in use. Requirement 3.5.4 calls for replay-resistant authentication for network access to privileged and non-privileged accounts, and the challenge-response design of passkeys is replay-resistant by construction.
Two practical cautions for defense contractors. First, if your environment holds controlled unclassified information, confirm where synced keys are stored and who administers that sync service, because the sync account becomes part of your authentication boundary. Second, document the decision. A passkey rollout with a written rationale that cites NIST SP 800-63B-4 is far easier to defend in an assessment than one that is simply switched on.
HIPAA
The HIPAA Security Rule's person or entity authentication standard at 45 CFR 164.312(d) requires covered entities to "implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed." It does not name a specific method. Passwords and one-time codes can both be captured by a fake sign-in page, so a phishing-resistant method like a user-verified passkey is a strong way to meet that standard, especially for remote access to systems that hold ePHI.
PCI DSS
PCI DSS v4.0 requires multifactor authentication for access into the cardholder data environment. As with CMMC, the point to document is that user verification is enforced, so each passkey sign-in really does present two factors.
The Risks That Actually Matter
None of this means passkeys can be deployed carelessly. The risks are real, they are just different from the ones our earlier post described.
The Sync Account Becomes a Crown Jewel
With synced passkeys, anyone who takes over the cloud account that holds the keys can restore them to a new device. That is why NIST requires AAL2-equivalent MFA on the sync fabric itself. Protect those accounts with a phishing-resistant method, and know which sync providers your users are allowed to use for work credentials.
Recovery Is the Back Door
An account is only as strong as its weakest recovery path. If a user who loses a phone can get back in with an emailed link or a text message, an attacker can too. Recovery procedures deserve the same scrutiny as the primary sign-in.
User Verification Must Be Required, Not Preferred
WebAuthn lets a website ask for user verification as "required," "preferred," or "discouraged." Only "required" guarantees the second factor. If your identity provider or application accepts passkeys without it, NIST says to treat them as single-factor, and you should configure accordingly.
Attestation and Device Choice
This is where the Hacker News essay has a point. Organizations can require attestation so that only approved authenticators, such as a specific model of hardware security key, are accepted. For a regulated workforce that is often a reasonable control. For consumer-facing services it raises the user-freedom concerns the essay describes, and each organization should make that trade-off deliberately.
Phishable Fallbacks Undo the Benefit
Attackers who cannot phish a passkey will try to push the user to a weaker method. If SMS codes, push approvals, or passwords remain enabled as fallbacks, a convincing fake sign-in page can simply ask for those instead. Removing phishable fallbacks for high-value accounts is where much of the real security gain comes from.
What This Means for Regulated Industries
Defense Contractors and the Defense Industrial Base
- Use device-bound passkeys or hardware security keys for privileged and administrator accounts, and require user verification everywhere.
- Decide whether synced passkeys are allowed for accounts that touch controlled unclassified information, and if so, which sync providers are in scope.
- Keep configuration screenshots and sign-in logs as assessment evidence for IA.L2-3.5.3 and IA.L2-3.5.4.
Healthcare Organizations
- Prioritize passkeys for remote access, email, and any portal that exposes ePHI, where phishing is the dominant threat.
- Plan for shared clinical workstations, where per-user hardware keys or badge-based authenticators often fit better than phone-based passkeys.
Legal and Financial Firms
- Move high-value users first: partners, finance staff, and anyone who can approve a wire transfer, since those accounts are the usual targets of business email compromise.
- Remove SMS and push fallbacks for those users once passkeys are enrolled.
Practical Action Plan
- Inventory authentication methods - List every method in use across your identity provider, VPN, email, and line-of-business applications.
- Map requirements - Record which frameworks apply (NIST SP 800-171, CMMC, HIPAA, PCI DSS) and the assurance level each system needs.
- Require user verification - Configure passkey policies so user verification is required, and confirm it in the sign-in logs.
- Choose synced or device-bound per role - Synced passkeys for general staff up to AAL2; device-bound keys for administrators and any AAL3 need.
- Harden the sync accounts - Protect the cloud accounts that hold synced keys with phishing-resistant MFA.
- Fix recovery - Replace email and SMS recovery with identity-verified, help-desk-controlled processes.
- Retire phishable fallbacks - Remove SMS, push, and password-only paths for users who have enrolled passkeys.
- Monitor and respond - Send authentication events to your SIEM and fold suspicious sign-ins into your incident response playbooks.
- Document the decision - Write down the policy and cite NIST SP 800-63B-4 so auditors and assessors can follow your reasoning.
How Petronella Technology Group, Inc. Helps
Petronella Technology Group, Inc. helps regulated organizations choose, configure, and document authentication that stands up to both attackers and assessors.
- Virtual CISO services set identity and access policy, including which passkey types are allowed for which roles.
- CMMC compliance guidance maps your authentication controls to IA.L2-3.5.3 and the evidence an assessor will ask for.
- Managed XDR services watch for suspicious sign-ins and account takeover attempts across your environment.
- Compliance services cover HIPAA, PCI DSS, and NIST SP 800-171 readiness, including authentication policy and documentation.
- Cybersecurity risk assessments find the weak recovery paths and phishable fallbacks that undo a passkey rollout.
Related reading
- Biometric Passkeys for AI Call Centers Secure Access
- Zero Trust with Passkeys for Safer Customer Identity in
- Zero Trust Contact Centers with Passkeys and HIPAA AI
- What Are Passkeys? FIDO2, WebAuthn and Security Keys (2026)
Frequently Asked Questions
Does a passkey count as multifactor authentication under NIST?
Yes, when user verification is required. NIST SP 800-63B-4 says a passkey that verifies the user with a biometric or PIN can be treated as a multi-factor cryptographic authenticator, which meets AAL2 by itself. Without user verification it is treated as a single-factor cryptographic authenticator.
Can synced passkeys be used at AAL3?
No. NIST SP 800-63B-4 says syncable authenticators shall not be used at AAL3. Device-bound authenticators, such as hardware security keys that never export their private keys, are the option for AAL3.
Do passkeys satisfy the CMMC multifactor authentication requirement?
A passkey with required user verification supplies two factors, which is what IA.L2-3.5.3 calls for. Assessors will look for evidence that user verification is enforced and that weaker fallback methods are controlled, so document both.
What is the biggest risk with passkeys?
The accounts and processes around them: the cloud account that syncs the keys, weak account recovery, and phishable fallback methods left enabled. The passkey sign-in itself resists phishing; the paths around it may not.
Passkeys are not a trap for regulated organizations. Deployed with required user verification, protected sync accounts, sound recovery, and no phishable fallbacks, they are one of the strongest authentication options available, and NIST says so. If you want help planning a passkey rollout that holds up in a CMMC, HIPAA, or PCI DSS assessment, contact Petronella Technology Group, Inc. at 919-348-4912 or visit https://petronellatech.com to learn how our managed detection and response, virtual CISO, and compliance readiness services can help.
Source: "Passkeys are a trap. Do not use them" (via Hacker News)
To discuss how these risks apply to your organization, call Petronella Technology Group, Inc. at 919-348-4912.
Free, practical, and specific to regulated environments. We will email it to you.
No spam. Unsubscribe anytime.
