Passkeys have won the argument. WebAuthn and FIDO2 give you phishing-resistant authentication, the platform support is mature, and every identity provider now ships a rollout guide. What the rollout guides do not cover is what happens next: once passwords stop being the perimeter, the credential lifecycle becomes the perimeter — registration, attestation, recovery, and revocation. Those are governance questions, and they are exactly what your NIS2 or ISO 27001 auditor will ask about once the novelty wears off.
This post is not about whether to adopt passkeys. It is about the policy decisions that determine whether your deployment is actually as strong as the cryptography underneath it.
Synced versus device-bound is a policy decision, not a feature flag
Synced passkeys — stored in iCloud Keychain, Google Password Manager, or a third-party manager — are recoverable and low-friction, but the private key leaves the device boundary and inherits the security of the user's cloud account. Device-bound credentials, on hardware security keys or platform configurations that prevent syncing, offer stronger assurance at the cost of a harder lifecycle. The sane enterprise answer is tiered: synced passkeys as the workforce baseline, device-bound authenticators mandatory for privileged access — domain admins, production deployment, financial approval flows. Document the tiers against assurance levels (NIST AAL2 and AAL3 give you shared vocabulary) so the policy survives an audit.
Attestation and the AAGUID problem
If you have authenticator requirements, you need to enforce them at registration. WebAuthn attestation lets the relying party verify what kind of authenticator is enrolling, and the AAGUID identifies the model, with the FIDO Metadata Service as the reference dataset. Here is the trade-off nobody advertises: synced platform passkeys frequently return no meaningful attestation, so a strict attestation policy can block the very authenticators most of your workforce uses. Decide deliberately — strict attestation with an AAGUID allowlist for the privileged tier, permissive for the baseline tier — and test the policy against the actual devices in your fleet before enforcement day.
Recovery is the new attack surface
The publicly reported social-engineering incidents of recent years — the 2023 MGM Resorts compromise being the canonical example — went through IT helpdesks, not through cracked credentials. Passkeys make the primary authentication path phishing-resistant, which pushes attackers to the reset path. If your recovery flow is a helpdesk call plus an SMS code, your passkeys inherit the security of SMS. Design recovery in tiers of friction: require multiple registered passkeys so self-recovery is the norm; for genuine lockouts, use verified identity proofing for high-risk roles, manager attestation plus a waiting period for standard ones; and simply do not offer same-day recovery for privileged accounts.
Credential inventory and the leaver problem
Your identity provider holds a registry of every enrolled credential — treat it as an inventory, not a log. Feed registration events into the SIEM and alert on enrollments from unusual locations or bursts of new credentials on a single account, which is the modern equivalent of a forwarded-mail rule. For departures, disabling the account neutralizes the passkeys — a key pair is useless without a live relying-party account — but the account is not the whole story: hunt down active sessions, OAuth refresh tokens, and above all the password fallback. A dormant password on a passkey-enabled account is a shadow authentication path that quietly undoes the whole project. Sunset password fallback application by application, and measure the survivors.
A governance checklist worth running this quarter:
1. Write the authenticator policy: which tiers get synced passkeys, which require device-bound. 2. Decide your attestation stance and test it against real fleet devices before enforcing. 3. Define recovery tiers with escalating friction and no same-day privileged recovery. 4. Stream registration and recovery events into the SIEM with alerting. 5. Eliminate password fallback per application and track the remaining count. 6. Fold all of it into your ISO 27001 access-control evidence and NIS2 MFA narrative.
The business value compounds quietly. A governed passkey estate removes the most reliable initial-access vector from your threat model, shrinks helpdesk reset volume, and gives you a clean, defensible answer to the multi-factor questions in every regulatory regime and customer questionnaire now in circulation. The teams that treat passkeys as a lifecycle to govern — not a checkbox to flip — are the ones whose deployments will still look strong when the auditors and the attackers both come looking.