Beyond the passkey rollout: who controls your authentication keys?

What changed—and what did not

NIST published the final SP 800-63B-4 authentication guidance in July 2025. Its publication record now carries a 6 October 2026 notice that implementation resources are available. That is useful support for applying the guidance, not a new edition of the standard. [1] [3]

For an identity team, the important question is not simply whether users have enrolled a passkey. It is whether the organisation understands how authentication keys are protected, recovered and removed when access should end.

Choose the assurance you actually need

NIST distinguishes authentication assurance levels. At AAL2, verifiers must offer a phishing-resistant authentication option. AAL3 requires phishing resistance and a non-exportable authentication key. Syncable authenticators can support AAL2 when the relevant requirements are met; synchronising keys conflicts with AAL3’s non-exportability requirement. [2]

That does not make synced passkeys inherently unsuitable. It means workforce, customer and privileged-access scenarios need deliberate decisions. Nor does buying a hardware key, by itself, prove that an entire authentication process meets AAL3.

The sync account is part of the security boundary

NIST’s syncable-authenticator guidance addresses encrypted storage, access controls and MFA protection for access to authentication keys in a sync fabric. It also distinguishes a user-verified authentication transaction from one without local user verification. A WebAuthn credential should not be assumed to make every transaction multifactor. [2]

This turns a rollout into a governance exercise: who owns the sync account, which devices may hold credentials, and who can recover access? A strong sign-in method can still sit alongside weak recovery or incomplete offboarding.

A practical rollout checklist

Our recommended starting point is a small, documented pilot:

1. Separate the use cases. Identify privileged administration, ordinary workforce access and customer sign-in. Record the assurance needed for each.
2. Decide where syncing is acceptable. Document approved credential and sync arrangements rather than relying on individual preference.
3. Assign ownership. Make account ownership, device management, access removal and recovery responsibilities explicit.
4. Test the awkward cases. Rehearse a lost device, an unavailable primary authenticator and a departing employee using approved test accounts.
5. Measure real coverage. Check which applications and sign-in paths use the intended methods, not just how many users completed enrolment.

Make the access decision before the rollout decision

A useful outcome is a short authentication policy and a tested recovery process—not an enrolment percentage alone. Vula Connect’s IAM Advisory can be scoped around those architecture and governance decisions.

Explore more insights →