Use x.509 certificates when you need broad enterprise coverage across managed devices, legacy applications, and workflows where passkeys are not yet consistently supported. Passkeys are strong for passwordless web access, but certificates fill the gaps where platform coverage and application compatibility are still uneven.
When x.509 certificates deserve priority over passkeys
Prioritise x.509 certificates when authentication has to work across a mixed estate, not just modern browsers and user devices. Certificates remain the more dependable choice for device auth, mutual TLS, VPNs, service-to-service flows, and older enterprise applications that expect PKI-based trust. Passkeys are excellent where platform support is mature, but they do not yet replace certificates everywhere.
In practice, this is less a question of which method is stronger and more a question of coverage. If the application, endpoint, or workflow needs interoperable cryptographic identity across managed devices, embedded clients, or legacy systems, certificates often provide the broadest operational fit.
For teams rolling out both, the safest pattern is usually to let passkeys become the preferred human sign-in method where supported, while certificates remain the compatibility layer for everything else. That keeps modern user journeys simple without creating outages in systems that still depend on PKI.
Where certificates fit better than passkeys in the architecture
Certificates are most useful when authentication is tied to a device, workload, or connection rather than a browser-centric user login. A certificate can be used in Machine Identity, PKI and Certificate Lifecycle Guide use cases such as mTLS, API clients, service identities, and managed endpoints, where trust must be established automatically and at scale.
That makes them especially relevant for environments that need consistent cryptographic proof across many systems, including regulated estates, thin clients, kiosk-like setups, and internal applications that have not been rebuilt for WebAuthn. Passkeys can be the better user experience, but certificates are often the more complete interoperability answer.
When the question is coverage rather than convenience, the deciding factor is whether the relying party can actually consume the authenticator. Workforce Identity Security Guide is useful for understanding where passkeys fit cleanly into employee access, while certificate-based auth still fills the support gaps around non-browser flows and recovery-heavy enterprise processes.
What passkeys still do better, and why that matters to priority
Passkeys are strongest when the goal is phishing-resistant human authentication with low user friction. They reduce password dependence, shrink the attack surface of credential reuse, and work well for interactive sign-in where platform support is stable. The limitation is not cryptographic weakness, but uneven deployment across apps, device classes, and administrative workflows.
That is why many organisations treat passkeys as the default for workforce login and keep certificates for the places where the rollout is incomplete. The operational question is whether the authentication method can be enrolled, recovered, and supported without creating exceptions that become the real control failure.
Passwordless and Passkeys Guide is the right reference when you are deciding whether a passkey-first journey is feasible, while IAM and Identity Provider Buyer’s Guide helps when platform selection must account for both passkey support and certificate-backed access patterns.
Risk and Threat Considerations
The main risk is choosing a method that is secure in theory but incomplete in coverage. If passkeys are adopted before critical applications, device classes, or recovery paths can support them, teams tend to create temporary exceptions, fallback mechanisms, or parallel legacy access paths that become the weaker control.
Failure mechanism: unsupported workflows push users and administrators toward bypasses such as shared accounts, fallback passwords, ad hoc recovery steps, or delayed migration of high-value systems. That can preserve access, but it also preserves exposure.
Impact: the organisation gets inconsistent assurance, uneven user experience, and a longer-lived attack surface. In mixed estates, the practical risk is not that certificates are obsolete, but that they remain necessary until the last legacy and non-browser dependency is safely retired or redesigned.
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, NIST SP 800-57 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 | Covers phishing-resistant auth and authenticator choice for workforce sign-in. |
| Recommendation — Use phishing-resistant authenticators where supported and verify enrollment and recovery paths. | ||
| NIST SP 800-57 | Key Management Recommendations | Certificates depend on key lifecycle, rotation, and protection decisions. |
| Recommendation — Set key lifecycle rules for certificate-backed authentication and rotate keys before expiry. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Relevant where certificates authenticate services, devices, or external-facing actors. |
| Recommendation — Use strong cryptographic authentication for non-organizational identities that access systems. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supports selecting and governing appropriate authentication methods for access paths. |
| A.8.5 — Secure authentication | Applies to choosing secure authentication mechanisms across supported platforms. | |
| Recommendation — Define access-control requirements that match the application's supported authentication methods. Require secure authentication methods that fit the platform and the use case. | ||
Practitioner Guidance
What to prioritise: Decide by application compatibility and operational reach, not by security fashion. If the system needs device trust, mTLS, or non-browser authentication, certificates should stay in the design even if passkeys are the preferred human sign-in method elsewhere.
What to verify: Test the full authentication journey, including enrollment, recovery, admin support, and cross-platform behaviour. A method only counts as a rollout option if it works for the actual apps and endpoints in production, not just for the pilot group.
Decision rule: Use passkeys where the user experience is interactive and supported end to end; use x.509 certificates where you need durable enterprise coverage across managed devices, legacy applications, or machine-facing flows. The right answer is often dual-track, not either-or.
Practitioner takeaway: Treat passkeys as the modern default for human sign-in, but keep certificates wherever compatibility, device trust, or workload authentication would otherwise force unsafe exceptions.
Related resources from NHI Mgmt Group
- When should organisations prioritise OAuth over simpler authentication for MCP?
- When should organisations prioritise recertification over authentication improvements?
- When should security teams prioritise passkeys over other authentication upgrades?
- When should organisations prioritise passwordless authentication over incremental password policy changes?