For privileged access, first specify the assurance you require, then choose the authenticator and recovery process that can prove it. A passkey is a FIDO credential; a physical security key is a device that can hold a device-bound passkey. The two are therefore not opposing login methods. A synced passkey can give strong, phishing-resistant sign-in with convenient recovery, while a qualified physical FIDO2 key can support a policy requiring managed custody and a non-exportable private key. Hardware form alone does not prove those properties. The choice changes if policy or a regulator requires particular authenticator properties, attestation, device control or an assurance level. FIDO Alliance's enterprise guidance distinguishes synced and device-bound passkeys; NIST SP 800-63B-4 describes their different assurance limits.
Do not decide from the button label “Sign in with passkey.” Verify whether the credential is synced, device-bound or unknown; whether the authentication event included user verification; and whether the relying party has enough evidence to enforce its privileged policy. A WebAuthn credential without user verification may be only one authentication factor. OTP and manually entered codes are not phishing-resistant under NIST's phishing-resistance definition.
Illustrative case: a cloud administrator and a product administrator
Illustrative company and policy. Falcon Ledger has ordinary users, application administrators and four staff who can alter production cloud infrastructure. Ordinary users need a usable phishing-resistant option across their devices. Product administrators can approve access to customer-facing reports. Cloud administrators can change infrastructure roles and recovery settings, so the security leader requires evidence that each privileged sign-in used a hardware-bound authenticator. The policy also requires a safe way to handle a lost key.
Falcon chooses synced passkeys as an option for ordinary users, with required user verification and recovery controls. A qualifying passkey ceremony can itself provide multifactor authentication; adding an OTP is not what makes that ceremony phishing-resistant. For cloud administrators it issues two managed physical FIDO2 security keys per person, registers both ahead of time, and requires user verification for the privileged sign-in. For product administrators it evaluates the same hardware policy based on what those roles can do. This is a decision example, not a statement that any specific standard mandates physical keys for every SaaS administrator.
The distinction matters during an incident. If a cloud admin loses a laptop but still has a registered spare key, the admin can regain access without relaxing the hardware rule. If both keys are missing, support does not turn on email-only admin login: it invokes a separately approved identity recovery procedure, restricts access while identity is established, enrolls new keys, and records the authorization. OWASP's passkey guidance emphasizes credential recovery and revocation; OWASP's MFA guidance treats factor replacement as high risk.
Compare the properties that actually decide the policy
| Question | Synced passkey | Device-bound passkey on a physical security key |
|---|---|---|
| Phishing resistance | WebAuthn verifier-name binding can provide it when implemented correctly. | The same WebAuthn protection can apply. |
| Key movement | Credential secret can be copied through a protected sync fabric to another device. | Key is intended to remain in the physical authenticator. |
| Loss and recovery | Provider account and sync recovery can restore availability; that path becomes part of the threat model. | Spare keys and controlled replacement are needed; loss can be operationally disruptive. |
| User verification | Must inspect the actual ceremony and flags; a “passkey” label alone is insufficient. | Must also require and verify PIN/biometric or other qualifying local verification when policy needs multifactor use. |
| Enterprise evidence | May need device-management, provider, backup-state and policy evidence; do not infer it all from a credential name. | Registration, custody, authenticator characteristics and possibly attestation support an enforceable hardware policy. |
| High-assurance rule | NIST describes syncable keys as exportable and therefore incompatible with AAL3's non-exportability requirement. | A suitable non-exportable authenticator can support an AAL3 design, but the entire ceremony and other requirements still need assessment. |
The table compares common deployments, not every product. Platform authenticators can also be device-bound, and a security key can hold several kinds of FIDO credentials. NIST's syncable-authenticator appendix and OWASP's Passkey Security Cheat Sheet give the relevant distinctions. The WebAuthn backup flags are useful risk inputs, but they do not alone prove which provider or physical device is trustworthy.
Ask for the evidence behind “hardware MFA”
Falcon's cloud-admin policy requires phishing resistance, user verification and a non-exportable authentication key. Three synthetic evidence packets show why a familiar button label is insufficient:
| Packet | Evidence supplied | Decision for Falcon's hardware-only action |
|---|---|---|
| A | IdP assertion says mfa; no method policy or credential evidence |
Insufficient to establish the required properties |
| B | WebAuthn ceremony has verified origin/RP/challenge and user verification; credential is syncable | Strong phishing-resistant authentication may be present, but does not meet this non-exportability requirement |
| C | Qualified managed authenticator enrollment, trustworthy device-binding evidence, verified ceremony and user verification, current account binding | Eligible if the complete policy and current permission checks pass |
Packet C is a list of evidence requirements, not a claim that a particular key or IdP supplies them. Where attestation is used, verify its trust chain and the policy for accepted authenticators; where federation hides the ceremony, qualify the exact IdP configuration and meaning of its context claims. A backup flag alone does not establish hardware provenance or certification.
NIST requires non-exportable keys for AAL3 and explains why syncable keys do not satisfy that property. It also imposes other requirements; buying a physical key does not make the entire service AAL3. See SP800-63B-4. Falcon's policy is an illustrative private-company choice, not a universal legal requirement for administrators.
Run the lost-key decision before an emergency
A cloud administrator loses the primary key but has a registered spare. The response should identify and revoke the lost credential, assess affected sessions, authenticate with the qualified spare, and preserve the same privileged policy. Merely adding a new key while leaving the lost one enrolled does not close the credential exposure.
If both keys are lost, the administrator enters restricted recovery. Falcon's example uses two authorized approvers and independent identity evidence before enrolling replacement authenticators. Until the new qualification is complete, the recovered account cannot perform the hardware-only action. A temporary email code may help communicate or initiate recovery; it must not silently become the privileged authentication method.
| Recovery state | Allowed work in Falcon's example | Privileged role change |
|---|---|---|
| Primary lost, qualified spare available | Revoke lost credential; use spare under current policy | Allowed only after qualifying fresh ceremony |
| Both lost, identity unresolved | Recovery intake and evidence collection | Denied |
| Identity approved, replacement enrollment pending | Restricted enrollment | Denied |
| Replacement qualified and fresh ceremony complete | Restore current approved role access | Allowed if authorization also holds |
These are planned synthetic outcomes, not a performed drill. The drill should inspect the final cloud or application resource decision, including fallback login and support override paths. A strong primary method is undermined if support can issue a fully privileged session from the same email address alone.
The decision record should therefore name both the permitted authenticator evidence and the recovery exception owner. OWASP's passkey guidance discusses the credential lifecycle; the worked packets make clear what Falcon still needs to establish before claiming its hardware policy is enforced.
When the evidence is incomplete
An authenticator may be phishing-resistant yet lack evidence that its private key is non-exportable. That is a valid reason to permit it for some roles and withhold hardware-only actions, rather than calling it insecure in general. Conversely, a physical key in someone's hand does not prove the application checked user verification, recent authentication or the right account. If the IdP cannot supply trustworthy, current assurance information, use an application-controlled step-up that can, or suspend the privileged route until the federation contract is qualified.
Write a policy that an administrator can actually follow
Falcon's hardware-only rule needs to describe the protected actions, the acceptable evidence, and the recovery route in operational language. “All admins must use a security key” leaves questions unanswered: which administrative roles, which sign-in paths, which authenticator qualifications, and which fallback methods? A precise policy lets the platform team configure enforcement and lets an administrator understand what to do before losing access.
For the four cloud administrators, Falcon can maintain a nonsecret enrollment record showing the person, the qualified credential identifiers, the responsible owner, and the revocation process. The record need not contain private key material or recovery secrets. It should distinguish a spare that was actually enrolled and qualified from a spare merely purchased and left in a drawer.
The policy should also state when fresh qualifying authentication is required. A strong ceremony at initial login does not itself describe the lifetime of the resulting session or the rule for a later privileged action. Review those decisions with the session and sensitive-route controls, and make sure the final resource server receives enough trustworthy evidence to enforce them.
Compare usability costs before choosing the wider rollout
Falcon's ordinary users and cloud administrators have different operational needs. An ordinary user may move between personal devices and need a recovery experience that does not depend on an IT office. A cloud administrator may have managed equipment, a small set of approved actions, and access to an enrolled spare. Those differences can justify different policies without calling one credential category universally safe or unsafe.
A bounded pilot should record enrollment completion, failed sign-ins, recovery requests, and whether the intended assurance could actually be established. These are proposed measurements, not results from Falcon. Include the effort required from identity administrators and support. A policy that users cannot complete may produce pressure for undocumented exceptions, which should be addressed through design rather than ignored.
Keep the security acceptance condition separate from convenience. A smooth login cannot compensate for missing evidence of the required authenticator properties. Equally, a cumbersome process is not stronger merely because it is cumbersome. The decision should explain which risk requirement each additional control serves and what evidence would show it is enforced.
Review an exception as a separate privileged path
If Falcon allows emergency access when both keys are unavailable, inventory that path with the same care as normal sign-in. Who can authorize it? Which actions become available? How long does it last? What evidence ends the exception and restores the ordinary policy? The exact approval structure is Falcon's choice, but the exception cannot remain an undefined promise that support will “sort it out.”
A restricted recovery state can preserve availability for enrollment without authorizing cloud changes. If the business requires an emergency privileged session, document its narrower scope and risk decision explicitly. Do not continue reporting that every privileged action required the normal hardware evidence while that alternative was available. The assurance statement should describe the whole set of accepted paths, including recovery and override behavior.
The security leader's next action is to pick one high-impact role and fill the decision record with real authenticator evidence, a fallback inventory and a lost-key drill. Pair it with how to check MFA on every sensitive route and how to review password reset without bypassing MFA, since recovery is often the easiest place to unintentionally weaken an otherwise sound policy.