Use the method that fits the use case and document why. In many environments, that means keeping certificate-based authentication for device or workload scenarios while adopting FIDO for human sign-in. The goal is consistent assurance, not uniformity for its own sake.
Choose the Fallback Without Diluting Assurance
When FIDO does not cover a required use case, the right move is to choose the strongest method that fits the actual scenario, then document the rationale. FIDO is excellent for phishing-resistant human sign-in, but it is not a universal answer for every device, workload, federation, or recovery path. Teams should optimise for consistent assurance across different actor types, not force one authenticator pattern everywhere.
That distinction matters because authentication is not just a login ceremony. A human browser session, a managed device certificate, and a service-to-service credential can each need different proofing, lifecycle, and revocation rules. The practical question is whether the control is delivering the assurance the use case requires, not whether it matches a preferred modern pattern.
Where the use case is human sign-in, FIDO or passkeys remain the natural first choice for phishing-resistant authentication, supported by NIST SP 800-63 Digital Identity Guidelines. Where the use case is device or workload authentication, a certificate-based approach may be the better fit because the subject is not a person but an endpoint or automated system that needs machine-appropriate trust and rotation mechanics.
Match the Control to the Actor and the Operational Reality
The common mistake is to treat "modern" as synonymous with "universal." That leads teams to reject an effective control because it is not FIDO, or to deploy FIDO into a context where it cannot cover the full access path. A better lens is to ask what is actually being authenticated, what failure modes matter, and which control can be operated safely at scale.
This is why certificate-based authentication still has an important place. It can support managed devices, service endpoints, and other non-human scenarios where attestation, issuance, renewal, and revocation are part of the control. FIDO can then be reserved for the contexts it fits best, such as interactive user sign-in, step-up authentication, and phishing-resistant recovery flows.
For teams building a broader authentication programme, Passwordless and Passkeys Guide is useful for understanding where FIDO and passkeys are strongest, while Workforce Identity Security Guide helps connect that choice to SSO, federation, recovery, and help-desk workflows. Those surrounding controls often determine whether the authentication method is truly secure in practice.
Document the Exception and Keep the Assurance Model Consistent
When FIDO does not fit, the answer should not be a vague exception. Record the use case, the reason FIDO is insufficient, the compensating control, and the assurance target you expect the alternative method to meet. That documentation becomes important for auditability, architecture review, and future standardisation decisions.
Teams should also avoid creating inconsistent policy just because the implementation differs. A certificate for a workload and a passkey for a user may look different operationally, but both can still be part of the same assurance model if they are governed consistently. The important discipline is that revocation, expiry, recovery, and ownership are explicit in both cases.
If the broader environment depends on identity and session controls, Identity Provider and SSO Security Guide is a useful companion because many authentication failures are actually federation, token, or recovery failures. For the human-authentication baseline, the NIST guidelines remain the clearest external reference for aligning assurance to the interaction type.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | FIDO and passkey assurance choices map directly to digital identity guidance. |
| Recommendation — Align authenticators to the required assurance level and use phishing-resistant methods where appropriate. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about selecting and documenting the right access method for each use case. |
| A.8.5 — Secure authentication | The answer concerns choosing between authentication methods such as FIDO and certificates. | |
| Recommendation — Define access methods by use case and enforce them through documented access control policy. Select authentication mechanisms that fit the actor type and required assurance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The issue includes issuance, renewal, revocation, and lifecycle of authenticators and credentials. |
| IA-9 — Service Identification and Authentication | Certificate-based authentication is often relevant to workloads and services, not only people. | |
| Recommendation — Manage authenticator lifecycle explicitly, including rotation, revocation, and recovery. Use service authentication controls for non-human actors that need machine-appropriate trust. | ||
Practitioner Guidance
What to prioritise: Decide first whether the use case is human, device, or workload driven. That classification usually tells you whether FIDO, certificates, or another method should be primary.
What to verify: Confirm that the selected method can support the full lifecycle, including issuance, renewal, revocation, recovery, and ownership. A control that works at login but fails at lifecycle management is not a complete solution.
Decision rule: If FIDO covers the sign-in flow end to end, use it for that use case. If it does not, choose the strongest fit-for-purpose method and document why it is the better control.
Practitioner takeaway: The goal is not to standardise on one authentication method, it is to standardise on defensible assurance for each use case.
Related resources from NHI Mgmt Group
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
- How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?
- How do security teams decide whether biometrics are appropriate for a use case?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org