Security teams should remove fallback factors that weaken the control, especially SMS and TOTP, and make the key the only permitted second factor for privileged users first. That means updating authentication policies, confirming app compatibility, and documenting recovery paths before rollout. The goal is to ensure phishing resistance is real in practice, not just theoretical, across the accounts that matter most.
Why This Matters for Security Teams
When high-risk accounts can still fall back to SMS or TOTP, the control is no longer phishing-resistant in the way most teams intend. Attackers do not need to break the key if they can push the user, help desk, or recovery workflow into a weaker second factor. That is why the real policy question is not whether security keys are supported, but whether they are the only acceptable second factor for the accounts that would create the most damage if compromised. The governance challenge is usually consistency. Teams often protect administrators, finance approvers, and cloud operators differently across platforms, which leaves gaps in policy enforcement and recovery handling. If one system still allows a backup code path or a legacy authenticator app, the account is only as strong as that exception. Security keys work best when the authentication standard, enrollment path, and recovery process all point in the same direction. NIST Privacy Framework In practice, many teams discover the weakest second factor only after an account has already been targeted, rather than during the policy design stage.How It Works in Practice
Making security keys the only allowed second factor means treating the key as the enforced control, not just the preferred one. Start by identifying which accounts are truly high-risk, then apply a stricter policy set to those populations first. For most organisations, that means privileged administrators, security operators, finance leaders, and any account with access to sensitive production or identity systems. Implementation usually has three layers:- Policy enforcement: disable SMS, push, and TOTP where the platform allows a true second-factor restriction.
- Compatibility testing: confirm that SSO, VPN, PAM, and legacy applications still work when the only second factor is a security key.
- Recovery design: define how a user regains access if the key is lost, damaged, or replaced without reintroducing a weaker everyday factor.
Common Variations and Edge Cases
Tighter second-factor policy often increases user friction and support load, so organisations have to balance phishing resistance against account recovery complexity. That trade-off is manageable for privileged accounts, but it becomes harder when vendors, contractors, or executives use a mix of managed and unmanaged devices. In those cases, the key question is whether the environment can truly enforce the same factor everywhere the account authenticates. Some platforms support security keys only for interactive login but still allow weaker methods for backup, step-up verification, or device re-enrollment. That is not equivalent protection. Teams should treat any alternate path as part of the control design, because attackers frequently target the weakest supported route rather than the primary one. Another edge case is mixed federation: a strong local policy can be undermined if the upstream identity provider still permits fallback methods. Where legacy or regulated systems cannot yet support key-only authentication, current guidance suggests using segmentation and role scoping to keep those accounts away from the most sensitive actions until the authentication stack can be upgraded. For broad user populations, a phased approach is often more realistic than an immediate enterprise-wide cutoff. For high-risk accounts, though, the exception window should be short and explicitly owned. OWASP Cheat Sheet Series The hardest cases are environments with outsourced support or multiple identity providers, because the policy can appear consistent on paper while still failing at the point of authentication.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 CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Key-only second factor policy is an authentication control choice. |
| Recommendation — Enforce phishing-resistant authentication for high-risk accounts and remove weaker fallback methods. | ||
| CIS Controls v8 | 6 — Access Control Management | Restricting second factors is part of controlling account access paths. |
| Recommendation — Harden access policies so privileged accounts cannot authenticate through weaker fallback factors. | ||
| NIST SP 800-63 | AAL2 — Authenticator Assurance Level 2 | Security keys are used to raise authenticator assurance for sensitive accounts. |
| Recommendation — Require phishing-resistant authenticators at the assurance level appropriate for high-risk accounts. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Fallback factors and recovery paths are credential lifecycle risks for governed identities. |
| Recommendation — Eliminate weaker secondary factors and govern recovery credentials tightly for sensitive accounts. | ||
Practitioner Guidance
What to prioritise: Enforce key-only second factor rules first on the accounts whose compromise would create the largest blast radius, especially privileged and administrative roles. Do not start with low-risk populations and assume the same policy will naturally hold at the top end.
What to verify: Confirm that no alternate login path, recovery flow, or step-up challenge still accepts SMS, TOTP, or another weaker factor for those accounts. If even one path remains, the policy is not fully enforced.
Decision rule: If a platform cannot support true key-only enforcement for a high-risk account class, treat that as an architectural constraint, not a minor configuration gap. Restrict the account’s permissions or remove it from sensitive workflows until the control can be enforced cleanly.
Practitioner takeaway: The objective is not to remove every fallback for every user, but to ensure that the accounts with the most dangerous access cannot be satisfied by a weaker factor anywhere in their authentication lifecycle.
Related resources from NHI Mgmt Group
- How should security teams run privileged access reviews without missing high-risk accounts?
- How should security teams implement stronger authentication for high-risk accounts?
- How should security teams use the OWASP NHI Top 10 to prioritise risk reduction across service accounts, API keys, and OAuth apps?
- Why do hardware security keys and passkeys matter more than legacy login methods for high risk accounts?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
