Passkeys fit best when step-up is driven by transaction risk, not by a one-size-fits-all login rule. In a zero-trust model, the authenticator should be selected and challenged according to context, so stronger proof is used where the access decision warrants it.
Why This Matters for Security Teams
Passkeys are not a substitute for zero trust, but they can be a strong step-up factor when the access decision is based on context and risk. The practical goal is to avoid treating every login or action as equally sensitive. Under NIST SP 800-207 Zero Trust Architecture, trust is continuously evaluated, which means the authenticator should match the transaction, the device, and the assurance level required. That is where passkeys fit well: they can raise assurance without forcing static, universal MFA prompts that frustrate users and still miss risky activity.
For NHI governance, the same pattern shows up when organisations apply identity controls to workloads and secrets. The Ultimate Guide to NHIs — Standards frames this as an identity lifecycle problem, not just an authentication problem, because access must be issued, challenged, and revoked based on context. NHI Mgmt Group research also shows why this matters: 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation. In practice, many security teams discover weak step-up logic only after a high-risk transaction has already been approved with a generic prompt.
How It Works in Practice
In a zero-trust design, passkeys should be used where they add friction to the right action, not where they merely satisfy a policy checkbox. For example, a low-risk session might continue with an existing device-bound assertion, while a money movement, secrets export, admin change, or privilege grant triggers a fresh passkey challenge. That approach aligns with NIST SP 800-207 Zero Trust Architecture, which expects policy decisions to be made from current context rather than from a one-time perimeter trust decision.
Operationally, teams should define step-up rules around transaction sensitivity, not just user role. A practical pattern is to combine device posture, session age, location anomaly, and action type, then require a passkey only when the request crosses a risk threshold. That makes passkeys part of an adaptive authentication workflow instead of a universal second factor. For identity programs that also govern machine access, the same philosophy appears in Guide to SPIFFE and SPIRE, where workload identity is proven cryptographically and short-lived credentials reduce standing risk.
- Use passkeys for step-up on high-impact actions, not every routine login.
- Pair them with risk scoring, device trust, and session re-authentication windows.
- Reserve phishing-resistant step-up for actions that can change data, privilege, or payment state.
- Keep the policy engine separate from the authenticator so challenge logic can evolve.
This guidance tends to break down in legacy environments where every application expects a fixed MFA flow and cannot evaluate transaction risk at request time.
Common Variations and Edge Cases
Tighter step-up rules often increase user friction and policy complexity, so organisations have to balance stronger assurance against workflow disruption. That tradeoff is especially visible in regulated environments, shared workstations, and high-frequency operations where repeated passkey prompts can become operationally expensive.
Current guidance suggests passkeys are most effective when they are one control inside a broader zero-trust policy, not the whole policy. Where session continuity matters, teams may allow a passkey only at transaction boundaries and then rely on continuous evaluation for the rest of the session. Where assurance is extremely high, a passkey may be combined with device binding, PAM, or additional approval workflows. The Ultimate Guide to NHIs — Standards is useful here because it reminds teams to treat identity proofing, credential lifecycle, and revocation as connected controls, not isolated events.
There is no universal standard for exactly when a passkey should replace another factor, but best practice is evolving toward risk-based, context-aware step-up. That is also why zero-trust guidance from NIST SP 800-207 Zero Trust Architecture matters: it supports decisions that change with the transaction rather than a fixed login ritual. In practice, the edge cases appear when organisations try to force passkeys into legacy SSO, shared kiosks, or high-latency remote access flows, because the authentication experience no longer matches the underlying risk model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | SA-3 | Zero trust requires context-driven auth decisions, which is the core of step-up passkey use. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Passkeys complement NHI controls that reduce standing credentials and improve assurance. |
| NIST AI RMF | GOVERN | Risk-based step-up depends on governed policies and accountable decision-making. |
Define ownership, policy review, and exception handling for adaptive authentication decisions.
