Passkeys replace passwords with public-key cryptography. The user’s authenticator keeps the private key. The online service stores a public key and verifies a signed challenge when the user signs in.

The authentication ceremony is straightforward. An enterprise rollout requires decisions about identity proofing, credential registration, recovery, synced passkeys, shared devices, authorization, and applications that were built before WebAuthn.

Attendees raised these issues during the FIDO Alliance webinar Enterprise Passkeys: What Works, What Doesn’t, and How to Roll Them Out. The discussion drew on a banking deployment, and the same questions apply to most organizations preparing to deploy passkeys.

1. Can one passkey authenticate a user across different domains?

A passkey is registered for a specific Relying Party ID (RP ID), usually associated with a domain. This origin binding gives passkeys their phishing resistance: a credential created for one relying party cannot produce a valid authentication response for an unrelated site.

Enterprises commonly give users access to several services through one of 3 models:

• Federation through a central identity provider. The user signs in to the identity provider with a passkey. The provider then issues tokens or assertions to connected applications. This is the usual enterprise model.

• Related Origin Requests. WebAuthn Level 3 defines a controlled way for related domains to use the same credential through a /.well-known/webauthn configuration. Check browser support before using it in production.

• Separate credentials for separate relying parties. Independent brands, organizations, and security boundaries usually keep their own passkeys.

Authentication and authorization remain separate. A user can authenticate once to an identity platform, then receive access to several applications, tenants, or business entities according to policy.

An accountant who manages several companies is a useful example. One passkey can verify the accountant’s identity, while the application decides which customer accounts that person can open.

2. Can one user access several companies through the same platform?

Yes. The passkey verifies the user’s identity. Application policy decides which companies, customers, or business units the user can access.

This separation is especially useful in multi-tenant systems. An employee at an accounting firm may manage dozens of customer organizations through one identity. After authentication, the system grants access to the appropriate customer resources.

Each customer can still have its own authentication policy. One organization may require passkeys while another keeps a legacy method during migration. This lets a platform change security requirements by tenant without creating another identity for the user.

3. Can an organization create a passwordless account from the start?

Yes. An organization can create an account without issuing a password. It first needs a reliable way to establish who the person is.

A passkey proves possession of a cryptographic credential. Identity proofing establishes the person’s identity. These are separate processes:

1. Identity verification establishes who the user is.

2. Credential registration binds a passkey to the verified account.

The verification method depends on the organization and its regulatory duties. It may use:

• Know Your Customer (KYC) checks;

• government-issued identity documents;

• a trusted digital identity;

• verification at a branch;

• an existing customer relationship;

• an employer-issued credential;

• another approved identity-proofing process.

After verification, the passkey can become the account’s primary authentication method.

During a migration, existing customers can enroll a passkey after signing in with their current method. New customers can enter a passwordless onboarding process from the beginning.

4. How should organizations verify identity before passkey registration?

Identity verification should precede registration. The required assurance level should follow the risk attached to the account and the requested action.

For example:

• An existing customer adding another authenticator may confirm the request with current trusted credentials.

• A new digital customer may complete KYC or present an accepted electronic identity.

• A privileged administrator may need stronger checks before enrolling another authenticator.

• A user who has lost every credential may need to repeat identity proofing before receiving access again.

Many organizations also ask for a recent authentication event before accepting a new passkey. The user might confirm the enrollment with an existing passkey, a TOTP code, an approved MFA method, or another verification step.

This protects accounts when an attacker obtains an active session. A stolen session cookie alone should not give someone the ability to add a permanent authenticator.

Registration policy belongs in the full identity lifecycle, alongside onboarding, credential changes, recovery, and account closure.

5. How should account recovery work?

Recovery often gives attackers an easier route into an account than the primary authentication method. Design it before deployment and test it during the pilot.

Common recovery controls include:

• another registered passkey;

• a dedicated recovery credential;

• identity verification;

• administrator approval for privileged accounts;

• a delay before sensitive changes take effect;

• an independent notification to the user;

• immediate revocation of lost credentials;

• a complete audit record for each recovery event.

Organizations often keep current recovery methods during the first rollout stage. They can strengthen or retire weaker paths after passkey adoption grows and the new procedures have been tested with real users.

Every route back into an account should provide assurance that matches the risk of the account.

6. What does Microsoft’s move away from SMS mean for passkey projects?

Microsoft’s retirement of SMS and voice authentication in Microsoft Entra ID gives organizations a reason to review where those methods are still used.

The review should identify:

• users who depend on SMS or voice authentication;

• applications that cannot use phishing-resistant authentication yet;

• frontline and recovery cases that need another method;

• legacy systems that could delay the migration.

A staged transition reduces disruption. Many organizations first add passkeys beside familiar methods. After users have enrolled and recovery procedures have been tested, the organization can retire methods that are easier to intercept, phish, or manipulate through social engineering.

7. Why require extra verification before registering a passkey?

Adding a passkey changes who can access the account. The enrollment process therefore needs enough assurance to confirm that the account owner requested the change.

An attacker with a stolen session cookie should not be able to turn temporary access into a permanent credential. Organizations commonly require one of the following before activation:

• a recent authenticated session;

• a TOTP code;

• an existing passkey;

• another approved MFA method;

• an identity check suited to the account’s risk.

This requirement protects enrollment. Everyday passkey authentication can remain quick because the stronger check applies when the account’s credential set changes.

8. Are synced passkeys phishing-resistant?

Yes. Synced and device-bound passkeys use the same WebAuthn origin binding. A phishing site cannot obtain a valid authentication response for the legitimate domain.

Synced passkeys add credential custody to the risk assessment. A credential provider may make a passkey available on several devices through the user’s account. Security teams should examine:

• protection of the credential manager account;

• authentication required for that account;

• enrollment of new devices;

• account recovery controls;

• the effect of a compromised synchronization account.

The right policy can differ by user group. Synced passkeys give consumers a practical way to retain access after replacing a phone or computer. Privileged administrators may need device-bound credentials or hardware security keys that cannot sync.

The choice depends on usability, recovery needs, and the risk attached to the account.

9. How should organizations handle synced passkeys on new devices?

Possession of a valid passkey confirms the credential. Device policy determines whether the organization trusts the device using it.

When a passkey appears on a new device through synchronization, the organization may require:

• confirmation with an existing trusted method;

• approval through another registered authenticator;

• device registration;

• a risk check before future sign-ins are allowed.

This approach preserves the recovery and convenience benefits of synchronization while giving the organization control over device access. It is useful for shared consumer accounts and credential managers that sync across several personal devices.

The answer depends on the deployment.

Attestation can provide information about the authenticator that created a credential. Available details vary by authenticator, privacy settings, and deployment model. They may identify an authenticator family, manufacturer, or other properties.

In a workforce deployment, attestation can confirm that employees use approved hardware or managed devices.

Customer services face a wider device mix: Windows Hello, Apple devices, Android credential managers, and hardware security keys. A short allowlist of individual models can block legitimate customers without adding much protection.

Many organizations therefore set policy around authenticator families, user-verification requirements, device-management status, or assurance level. Attestation can contribute to the risk decision without becoming the only allow-or-deny control.

11. Why limit the number of registered passkeys?

WebAuthn does not set a maximum number of passkeys per user. Each organization chooses a limit that fits its security and support model.

Unlimited registration can leave accounts with forgotten phones, retired laptops, and obsolete security keys. Every active credential needs to be visible, auditable, and revocable.

A very low limit can create recovery requests whenever users replace devices or add a hardware key. A practical policy gives legitimate users enough room while keeping the credential list manageable.

The account interface should show:

• a recognizable credential or device name;

• registration date;

• last authentication date;

• authenticator type, when available;

• synced or device-bound status;

• a self-service removal option.

Adding or deleting a passkey should require recent authentication. The organization should also notify the user through an independent channel whenever the credential list changes.

12. Can existing applications support passkeys without source-code changes?

Yes. An authentication layer placed in front of an application can handle WebAuthn, identity integration, and access policy while the application continues to run with its existing code.

This model can:

• bring legacy and modern applications into the same authentication program;

• keep policy management in one place;

• reduce the number of application-specific development projects.

The organization still needs to review every component involved in authentication:

• identity providers;

• load balancers and reverse proxies;

• session management;

• audit and logging systems;

• support tools;

• recovery processes;

• fallback methods.

The banking deployment discussed in the webinar used this approach. The organization introduced passkeys without changing the banking application’s source code.

13. How should organizations secure authentication code outside the application?

Authentication code needs the same engineering controls as other security-sensitive production software, regardless of where it runs.

Required controls commonly include:

• secure development practices;

• code review;

• penetration testing;

• dependency management;

• vulnerability scanning;

• integrity checks;

• controlled deployment.

Keep private keys, certificates, and other secrets out of source code and configuration files. Store them in a dedicated secret-management system with access controls and audit logs.

Every component that participates in authentication becomes part of the trusted computing base. A proxy, browser component, or external authentication layer deserves the same scrutiny as the protected application.

14. What belongs in a passkey rollout plan?

Plan the operating model before the first user enrolls. A passkey program should define:

• identity-verification requirements;

• registration procedures;

• account recovery;

• accepted authenticator types;

• policy for synced and device-bound credentials;

• audit logging;

• device trust;

• administrator and help-desk processes;

• legacy application integration;

• fallback authentication;

• user education and communication.

The pilot should include representative users. Frontline workers, administrators, contractors, customers, and executives may need different authenticators, enrollment paths, and recovery procedures.

Use pilot feedback to fix policies and support processes before a wider rollout. Review those policies as applications, devices, regulations, and business requirements change.

Plan policy and operations with the technology

Public-key cryptography gives passkeys strong phishing resistance. An enterprise deployment also needs clear rules for identity proofing, registration, recovery, device trust, authorization, and legacy applications.

The banking example shows that an external authentication layer can bring passkeys to an existing application without a source-code rewrite. A staged rollout gives teams time to test enrollment, recovery, support, and policy with real users before older authentication methods are removed.

Passkeys work best when the organization treats them as part of the identity lifecycle, from onboarding through recovery and credential revocation.

Sources

• W3C Web Authentication Level 3

• W3C Secure Payment Confirmation

• FIDO Alliance: Passkeys

• Microsoft: Passkeys by default and retirement of SMS and voice authentication

• Secfense: What we do

• Secfense Platform

• Secfense Ghost

• Secfense: Passwordless in practice