Enterprise Passkey Deployments Have Moved Past Adoption—Now Come Attestation, Recovery, and Step-Up Auth

The debate over whether passkeys can replace passwords at scale is largely over. The harder questions—about device trust policy, account recovery under lockout, and what happens when a passwordless session reaches a sensitive action—are not.

At the FIDO Alliance's Authenticate 2026 conference in Carlsbad last week, executive director Andrew Shikiar framed the shift in terms his organization does not usually use for a technology still in rollout: "A few years ago, people came here to ask whether passkeys could really replace passwords at scale. This year, they're talking about what comes next." The FIDO Alliance estimates more than 7 billion passkeys are now in use worldwide, per Shikiar's October 19 conference post. The same post cites a FIDO/Imprivata report finding that the average organization surveyed lost 32,400 hours of frontline work annually to authentication issues—a cost framing that is driving enterprises from evaluation to execution.

Execution surfaces friction that pilots do not. The three friction points engineering and identity teams report most consistently are attestation policy, account recovery design, and step-up authentication after passwordless login.

The Attestation Problem

Passkeys come in two varieties with meaningfully different trust properties. Synced passkeys—provisioned through Apple, Google, or Microsoft platform credential managers—back up the private key to a cloud account and replicate across the user's devices. Device-bound passkeys, backed by hardware like a FIDO2 security key or a TPM, do not leave the authenticator.

Attestation is the mechanism by which a relying party asks the authenticator to cryptographically prove what hardware or software manages the key. During WebAuthn registration, the attestationObject carries a signed statement from the authenticator manufacturer or platform. A relying party that implements verification can check that statement against the FIDO Metadata Service to confirm the authenticator model, its certification level, and whether it has been revoked.

For most consumer deployments, attestation is irrelevant. As Safeguard's October 22 attestation explainer states directly: "Synced passkeys send no attestation, so consumer sites cannot lock you to approved devices. Enterprises can, and should, for admins and maintainers." Apple and Google omit or anonymize attestation on platform passkeys to preserve privacy across synced credentials.

For enterprises with Conditional Access policies requiring phishing-resistant MFA for privileged roles, attestation is not optional—it is the mechanism that distinguishes a hardware-backed credential from a platform synced one. HardenedHost's enterprise FIDO2 guide describes the configuration in Microsoft Entra ID terms: isAttestationEnforced = $true at the FIDO2 method level, combined with AAGUID whitelisting that restricts registration to verified corporate hardware UUIDs.

The operational difficulty is that attestation verification requires actively maintained infrastructure: a relying party server that fetches and caches the FIDO Metadata Service, parses fmt and attStmt from the attestation object, validates the certificate chain, and enforces policy on authenticator AAGUID. Many off-the-shelf WebAuthn libraries skip this step by default. Teams that want attestation-gated enrollment must implement or configure it explicitly—and then operationalize the policy as authenticator models change or get revoked.

// Simplified: what a server must verify when attestation is required
const { fmt, attStmt, authData } = parseAttestationObject(response.attestationObject);
const aaguid = extractAAGUID(authData);
const metadataEntry = await fidoMDS.getEntry(aaguid); // requires live MDS fetch
assertCertificateChain(attStmt, metadataEntry.metadataStatement);
assertStatusIsAcceptable(metadataEntry.statusReports); // check for revoked models

Most deployments that skip this block accept any passkey credential silently, regardless of authenticator provenance.

Requiring attestation also narrows enrollment options. Corbado's enterprise deployment challenges guide lists overly strict AAGUID allow-lists and Conditional Access policies that create circular dependencies among the most frequent configuration mistakes. Users who lack an approved authenticator cannot enroll until IT provisions one—a friction point that can stall rollouts where employees bring their own devices.

Recovery Is a Rollout Risk, Not an Afterthought

The enrollment path for a passkey is straightforward. Recovery—what happens when a user loses their device, or is locked out before registering a second authenticator—is where rollouts fail.

IAM Roadmap's October 18 workforce rollout guide frames the core structural risk: the credential is no longer something the user knows or manages. The device handles the authentication, which means a lost device without a recovery path becomes a hard lockout rather than a password reset.

Synced passkeys partially mitigate this—a credential synced to an Apple ID or Google account survives device loss and is available on the user's next device. But that sync depends on the cloud account being accessible. And cloud account recovery paths often fall back to phone numbers or email addresses that are themselves phishable. The phishing resistance of the passkey does not extend to the account that holds its backup.

For device-bound passkeys, or enterprise scenarios where sync is disabled (common in high-security environments), recovery requires a separate channel. Corbado's guide recommends offering multiple recovery methods for phone-replacement scenarios: a self-service recovery kiosk using a laptop as a bootstrap device, manager-assisted Temporary Access Pass (TAP) issuance, and self-service account recovery with Verified ID for edge cases.

HardenedHost's rollout blueprint includes a Phase 3 step dedicated to a TAP engine—issuing a time-limited Temporary Access Pass for zero-password onboarding before the passkey is registered, rather than falling back to a password.

NHIMG's FAQ on misapplied passkey rollouts notes a consistent failure pattern: "Fallback options become the real primary path, which means the rollout is only as strong as the weakest recovery method. The result is often more helpdesk churn, more exceptions, and less confidence in the authentication posture." The post cites NIST SP 800-63 as reinforcing that authenticator assurance and recovery design must be treated as a single workstream, not separated. In practice, NHIMG observes, many enterprise passkey failures surface only after support tickets expose gaps the pilot never tested.

Ciphers Security's Entra and Workspace rollout guide puts the readiness bar plainly: the rollout is ready to expand "when people can sign in, recover, and recognize an unexpected request—not simply when the policy toggle is enabled."

Schutz IT's analysis of high-trust rollouts recommends capturing enrollment at high-assurance session moments—immediately after a successful legacy MFA or password validation, during a payment confirmation, or during a session step-up event—rather than sending a cold enrollment prompt. That approach binds enrollment to a moment when trust is already established and reduces the risk that users defer and later face lockout.

Step-Up Auth After Passwordless Login

Passwordless login removes the password from the authentication ceremony. It does not automatically make the resulting session sufficient for every subsequent action.

The WebAuthn and FIDO specifications are authentication-layer protocols. Authorization policy—what a session can do after login—is outside their scope. Whether a passkey-authenticated session is sufficient to approve a wire transfer, modify an admin role, or export regulated data depends entirely on the relying party's step-up logic.

OpenID Connect's Authentication Context Class Reference (acr) and Level of Assurance (loa) claims are the standard mechanism for signaling session assurance level. An acr_values parameter in an authorization request tells the identity provider what assurance the client requires; the provider returns an acr claim in the ID token reflecting what was achieved. If the existing session's acr falls below the required level, the provider should issue a step-up challenge.

In practice, this chain has a documented failure mode. TT Lab's Keycloak enterprise rollout guide highlights account recovery and attestation as the problems "every enterprise inevitably runs into," and notes that step-up flows depend on identity provider configuration that many teams leave at defaults. If a session cookie is still valid, some identity providers do not re-trigger a step-up challenge even when the requested acr_values exceeds the session's authenticated level—depending on how the provider evaluates existing session state.

HardenedHost describes the "Dangerous Conditional Access Fallback Trap" in similar terms: configuring passkeys in Entra ID or Okta while leaving a "Use your password instead" escape hatch in Conditional Access leaves users vulnerable to AiTM phishing regardless of passkey enrollment. The attacker does not need to compromise the passkey—they redirect to the fallback. BrightWorks IT's 2027 migration guide notes that Microsoft's Conditional Access can enforce phishing-resistant authentication for specific roles, applications, or risk conditions, which addresses step-up requirements at the policy-enforcement layer rather than relying solely on session ACR values.

The practical guidance from multiple implementers converges: do not treat a passkey-authenticated session as a blanket authorization upgrade. Define which actions require re-authentication, map those to explicit acr_values requirements, and verify that the identity provider challenges existing sessions correctly rather than honoring stale cookies.

What This Story Is and Is Not

This is an implementation-state story, not a product launch. The 7 billion passkey figure and the Authenticate 2026 framing are sourced directly to the FIDO Alliance's own post by Andrew Shikiar. The 68% enterprise deployment figure comes from Tech Insider's reporting on the FIDO Alliance's May 2026 global survey of more than 11,000 respondents—it has not been independently verified against the primary survey document. The October 2026 FIDO Passkey Index is referenced in the MojoAuth blog analysis; specifics from that index beyond what MojoAuth's page confirms directly should be treated as MojoAuth's characterization of the index, not primary FIDO Alliance data.

The concerns about attestation verification complexity, recovery path design, and step-up auth gaps are documented across Safeguard, HardenedHost, TT Lab, Corbado, Ciphers Security, NHIMG, IAM Roadmap, Schutz IT, and BrightWorks IT—a consistent practitioner consensus, though none of those sources are primary FIDO Alliance or W3C documents.

Sources: FIDO Alliance, Authenticate 2026 Day 1; Safeguard, passkey attestation explainer; HardenedHost, enterprise FIDO2 guide; TT Lab, Keycloak enterprise rollout; Corbado, enterprise deployment challenges; Ciphers Security, Entra and Workspace rollout; Schutz IT, passkey default authentication; IAM Roadmap, workforce passkey rollout; NHIMG, misapplied passkey rollouts; BrightWorks IT, passkey migration; Tech Insider, passkey setup 2026