Passkeys Change the Recovery Path: Audit an AI-Written Rollout Plan

Audit an AI-written passkey rollout for enrollment, recovery, fallbacks, WebAuthn boundaries, telemetry, and a defensible release decision.

The most dangerous sentence in an AI-written passkey rollout may not concern cryptography at all. It may be a casual line such as, “Users who lose access can verify by email and enroll again.” That sentence quietly defines who can take over an account, which evidence is accepted after device loss, and whether the new sign-in method is stronger than its easiest fallback.

Passkeys change more than the login screen. They change credential enrollment, device portability, account mapping, authenticator loss, recovery, revocation, support procedures, and the evidence needed for a release decision. A polished plan can still omit those connections. The audit therefore has to follow the whole credential lifecycle, including failure paths that the generated document treats as footnotes.

This guide uses the final NIST SP 800-63B-4, FIDO Alliance deployment and UX guidance, and the W3C WebAuthn Level 3 specification specifically as the May 26, 2026 Candidate Recommendation Snapshot. That W3C document is a Candidate Recommendation Snapshot, not something this article represents as a final Recommendation. The result is an audit method, not production code, configuration, or a universal assurance claim.

An AI Plan Is a Hypothesis, Not an Approval

Begin by separating proposed behavior from verified behavior. AI-generated plans often mix standards language, product assumptions, browser behavior, and business decisions into one confident narrative. Mark every statement as a requirement, design choice, assumption, test result, or unresolved question. A sentence that says synced passkeys “solve recovery,” for example, is an assumption until the team has defined provider changes, lost devices, disabled synchronization, shared devices, and users who cannot complete the expected cross-device flow.

Require a source and an owner for security-relevant claims. Standards can define ceremony semantics; they do not choose the organization’s supported populations, recovery evidence, risk thresholds, customer communications, or rollback triggers. Those decisions need accountable human approval.

The audit target is not whether the plan sounds technically informed. It is whether every important claim can be traced to a standard, a documented product decision, or authorized test evidence.

Give the Rollout an Identity Card

Before reviewing individual screens or test cases, reduce the plan to a one-page rollout identity card. If the team cannot complete it without guessing, the proposal is not ready for implementation review.

Field	What the audited plan must state
Population	Eligible account types, excluded roles, regions, age groups, managed users, and shared-account cases.
Credential scope	The RP ID, permitted origins, applications, and whether related-origin or embedded contexts exist.
Account mapping	How credential IDs and user handles resolve to one account without relying on mutable display identifiers.
Authenticator model	Synced, device-bound, roaming, platform, or an explicitly supported combination.
Enrollment authority	What authenticated state permits a new authenticator to be bound and which sensitive changes require reauthentication.
Fallback and recovery	Every alternate path, its evidence, rate limits, notifications, waiting periods, and escalation owner.
Release evidence	Required positive and negative tests, telemetry thresholds, accessibility findings, and support readiness.
Rollback	Who can pause enrollment, what remains usable, and how security checks remain intact during rollback.

The card should also name the plan version, source versions, risk approver, product owner, identity owner, accessibility owner, support owner, and incident contact. “Passkeys for all users” is not a population definition, and “standard WebAuthn settings” is not an RP identity decision.

Lock Down RP Identity and Account Mapping

A WebAuthn credential is scoped to a relying party. The RP ID is established when the credential is created and becomes a core credential property. The browser checks whether the calling context is permitted to use that RP ID, while the authenticator binds operations to it. Separately, the relying party must validate the origin returned in client data during both registration and authentication. The May 26, 2026 WebAuthn Level 3 Candidate Recommendation Snapshot warns against accepting unexpected origins.

An audit should therefore demand explicit lists, not examples with “such as.” Record the canonical RP ID, every accepted origin, expected cross-origin or embedded use, and the treatment of preview, regional, mobile-web, and legacy domains. A broad wildcard copied from an AI suggestion deserves a HOLD until its scope and consequences are understood. Migration between domains also needs its own reviewed design; it should not be improvised inside a rollout checklist.

Account mapping is equally important. The relying party stores a credential record containing the credential ID and public key in the correct user account. For discoverable credentials, the user handle helps identify that account when a username was not supplied first. The handle should be stable and opaque rather than an email address or display name that can change or expose personal information.

Test both account-first and username-free journeys where supported. An assertion must never be accepted merely because its credential ID exists somewhere. The returned credential, user handle when applicable, and stored account relationship must agree. Include account merges, email changes, renamed users, duplicate enrollment attempts, and deleted or disabled accounts in the mapping review.

Keep Registration and Assertion Verification Separate

AI plans frequently describe WebAuthn as one “passkey verification” operation. That hides two ceremonies with different inputs, outputs, and failure conditions.

Registration Creates and Binds a Credential

The server initiates registration with a fresh challenge and defined RP and user information. After the client and authenticator respond, the relying party verifies the response type, challenge, expected origin, RP ID hash, required user-presence and user-verification results, credential data, supported algorithm, and any attestation policy it actually chose. It then stores the credential ID, public key, account mapping, and relevant credential properties only after verification succeeds.

The audit should ask how challenges expire, become single-use, and remain bound to the correct authenticated enrollment session. It should also verify duplicate-credential handling and the authority required to add another authenticator. Attestation is not a decorative field: if the business does not require it, the plan should say so; if it does, trust anchors, metadata, privacy effects, failure handling, and ownership must be documented.

Authentication Verifies an Assertion

Authentication starts with a new challenge and returns an assertion rather than a newly created key. The relying party identifies the stored credential record, checks the ceremony type, challenge, expected origin, RP ID hash, user-presence result, required user-verification result, account mapping, and signature using the stored public key. It also handles credential backup signals and signature-counter information according to documented policy.

A generated plan that says only “verify the signed challenge” is incomplete. The signature is one check in a chain. Reject-path tests must cover a stale or replayed challenge, wrong ceremony type, unexpected origin, RP ID hash mismatch, invalid signature, unknown credential, credential mapped to another account, inconsistent user handle, and a missing verification flag when verification was required.

Read BE and BS as Signals, Not Verdicts

WebAuthn authenticator data includes Backup Eligibility (BE) and Backup State (BS). In the cited Candidate Recommendation Snapshot, BE is fixed when the credential is created: BE=0 denotes a single-device credential, while BE=1 denotes a multi-device credential that is eligible for backup. BS is current state and may change. BE=1 with BS=0 means eligible but not currently backed up; BE=1 with BS=1 means currently backed up. BE=0 with BS=1 is invalid.

Store and observe these values if policy depends on them, but do not inflate their meaning. BE does not prove that a specific sync provider is trustworthy, and BS does not prove that the user can recover the provider account at this moment. They are credential signals, not a complete assessment of provider recovery, device ownership, enterprise controls, or account risk.

The final NIST SP 800-63B-4 guidance for syncable authenticators treats synchronization as an exportability and lifecycle question. It permits certain assurance uses only subject to stated controls and explains that synchronization conflicts with AAL3’s non-exportability requirement. Consequently, an AI plan must not label every passkey deployment “AAL2,” “AAL3,” “compliant,” or “passwordless” without evaluating the entire implementation and its remaining fallback paths.

A transition from BS=1 to BS=0 should generate an evaluated event, not an automatic lockout invented by the model. Depending on risk, the product might guide the user to validate another authenticator or add one. The decision and user experience must be explicit.

Keep Biometrics on the Local Side of the Line

When a user unlocks a passkey with a fingerprint, face, or device PIN, the relying party verifies the resulting authenticator assertion and flags. It should not receive the user’s biometric sample from the passkey ceremony. FIDO’s passkey guidance describes biometric processing as remaining on the device, while NIST treats biometrics as an activation factor used with a physical authenticator rather than an independent authenticator.

Review product copy for this boundary. “We verify your face” is misleading if the platform authenticator performs the comparison. Prefer language such as “Use your device’s screen lock.” Also preserve a non-biometric local option where the platform supports it. Accessibility and enrollment must not assume that every user can provide a particular biometric.

Design Enrollment for Loss, Not Just First Success

A successful first registration proves little about resilience. The plan should support multiple credential records per account unless a documented business constraint says otherwise. NIST recommends encouraging subscribers to bind at least two separate means of authentication to reduce recovery pressure, and WebAuthn account records are designed to evolve as credentials are added or removed.

After enrollment, provide a clear account-management view: recognizable credential labels, creation and recent-use context when reliably available, and an individual removal action. FIDO UX guidance recommends making passkeys visible and manageable rather than treating them as invisible browser state. Do not imply that deleting a credential at the relying party also deletes every provider-side copy, or vice versa.

Test adding a second authenticator, canceling midway, re-enrolling after removal, removing one of several credentials, and attempting to remove the last usable method. Sensitive enrollment and removal events should produce independent notifications and auditable events.

Test Real Device Contexts

“Works on mobile and desktop” is too coarse for release evidence. A useful matrix combines supported operating systems and browsers with device ownership, authenticator type, and user context.

• Test a passkey available locally through the user’s provider and one used through an explicitly supported cross-device flow.
• Test a device-bound or roaming authenticator, including loss of one device when another method remains.
• Test personal computers, managed endpoints, and shared devices under the business’s actual policies.
• Test absent or restricted Bluetooth, unavailable camera access, blocked USB or NFC, no phone, and interrupted network connectivity where relevant.
• Test keyboard and screen-reader navigation, zoom and reflow, understandable error text, sufficient time, and recovery without biometric use.

FIDO describes cross-device authentication as allowing a passkey on one device to authorize sign-in on another, commonly beginning with a QR-mediated flow and using proximity signals. That is useful, but it is not a universal fallback. A user may lack a compatible phone, camera access, Bluetooth permission, or the ability to move between screens.

Shared devices require special care. Storing a platform passkey in a shared operating-system profile can expose the credential to the wrong person using that profile. Depending on the environment, a roaming authenticator or a cross-device flow from a user-controlled device may be more appropriate. The audit should record which pattern was selected and test sign-out, profile switching, browser persistence, and device handoff.

Fallback and Recovery Are Part of the Threat Model

Fallback is an alternate way to authenticate while the account still has usable methods. Recovery is the process used after the subscriber can no longer authenticate at the required level. Mixing the two leads teams to offer a convenient reset path that bypasses the protections they just added.

Inventory every surviving route: password, recovery code, help-desk process, recovery contact, repeated identity proofing, federated sign-in, already-bound authenticator, or another business-specific method. For each one, state the evidence required, rate limits, delay, notification, fraud review, support authority, and post-recovery actions. NIST’s final account-recovery guidance recognizes saved and issued recovery codes, recovery contacts, and repeated identity proofing, with requirements that vary by the account’s assurance context.

Do not let an AI plan silently preserve a password and still claim the account has become passwordless. If a password remains capable of resetting or replacing a passkey, it remains part of the effective attack surface. That may be an intentional migration choice, but it needs an expiry or retention policy, monitoring, and honest product language.

Recovery should notify the subscriber through an independent channel and lead to review of authenticators, active sessions, recent account changes, and suspicious events. Test lost-all-devices cases, unavailable recovery contacts, used or expired codes, duplicate support requests, attacker-controlled email scenarios, and recovery followed immediately by a sensitive change.

Stage the Rollout Around Negative Evidence

A launch plan should make failure evidence a gate rather than a post-launch learning exercise. Use only synthetic accounts, authorized test systems, and approved devices for adversarial or negative testing. Do not probe third-party accounts, production credentials, or systems outside the authorized scope.

1. In the specification stage, freeze the identity card, origin list, mapping rules, recovery policy, data-retention choices, and named owners.
2. In a controlled lab, verify supported ceremony paths and the complete rejection matrix using synthetic identities. Confirm that failed responses create no credential record or authenticated session.
3. In an internal opt-in stage, test diverse devices, accessibility needs, provider changes, support scripts, revocation, notifications, and account restoration.
4. In a limited cohort, measure enrollment completion, assertion success, cancellations, fallback use, recovery initiation, lockout, and support demand against written thresholds.
5. Expand only after the risk approver records a RELEASE decision. Pause automatically defined expansion when a HOLD trigger is reached.

Negative testing should include malformed or incomplete responses, expired and replayed challenges, parallel ceremonies, unexpected origins, wrong RP scope, user-handle conflicts, invalid signatures, absent required verification, invalid BE/BS combinations, canceled prompts, unsupported authenticators, device loss, provider migration, and removal during an active session. Race conditions matter: attempt authentication while the same credential is being revoked, and confirm that the documented ordering produces the intended result.

Test the human failure paths too. A user should understand whether a prompt is creating a passkey or using one, which account is affected, why an operation failed, and what safe option comes next. Support agents should be unable to bypass recovery policy simply because a caller knows account-profile details.

Instrument Revocation and Rollback

Telemetry should answer operational questions without collecting raw biometric data, private keys, full ceremony payloads, recovery secrets, or unnecessary identifiers. Useful events include registration offered, started, completed, canceled, and rejected; assertion method and outcome; fallback selection; recovery initiation and completion; credential addition and removal; BS transitions when used by policy; notification delivery; and support escalation.

Segment results by supported platform, browser family, authenticator journey, managed versus unmanaged context, and accessibility-relevant flow where that can be done lawfully and with appropriate privacy controls. Define reason categories before launch so “WebAuthn error” does not become an opaque bucket. Protect logs, minimize retention, and restrict access because authentication metadata can still be sensitive.

Revocation must operate at the relying party’s credential record. Users and authorized administrators need a way to remove a specific credential, while incident procedures need a defined response for a lost device, suspected account takeover, employee departure, or compromised recovery path. Decide whether revocation also terminates sessions or blocks sensitive actions; that is a business-risk decision, not an automatic WebAuthn behavior.

Rollback should disable new offers or revert the user journey through a controlled feature decision without weakening origin, challenge, signature, account-mapping, or verification checks. Preserve valid credential records unless deletion is deliberately approved. A rollback that turns on an unmonitored weak fallback can increase risk even while restoring login volume.

Make RELEASE or HOLD a Named Decision

The final audit output should end with one of two words: RELEASE or HOLD. RELEASE means the named approver accepts the documented scope, residual risks, recovery model, support readiness, negative-test results, telemetry thresholds, revocation behavior, and rollback procedure. It does not mean the deployment is universally secure, compliant, passwordless, or suitable for every assurance level.

HOLD is appropriate when the RP identity is ambiguous, account mapping can cross users, registration or assertion checks are incomplete, recovery evidence is undefined, shared-device behavior is untested, users lack an accessible alternative, revocation cannot be exercised, or rollback would reopen an unreviewed path. Each HOLD item should have an owner, required evidence, and retest condition.

That named decision is the difference between reviewing prose and governing a credential lifecycle. Passkeys can improve authentication outcomes when their boundaries are implemented correctly, but the recovery path determines what happens after the ideal journey ends. An AI-written rollout becomes useful only after those boundaries, exceptions, and failure cases are made explicit and tested.

Source and Version Notes

• NIST SP 800-63B-4: Authentication and Authenticator Management, final publication.
• Web Authentication Level 3, May 26, 2026 Candidate Recommendation Snapshot.
• FIDO Alliance passkey overview, plus its linked deployment and UX guidance.