PKI and FIDO2 together close authentication gaps

At a glance

What this is: This is a commentary on why FIDO2 alone does not cover all authentication use cases, and why PKI is presented as the complementary control for machines, email, and document trust.

Why it matters: IAM teams need to treat passwordless as part of a broader identity architecture, because human authentication, machine identity, and trusted interactions fail in different ways and are not solved by one control.

By the numbers:

• 90% of IT leaders have seen an increase in cyberattacks since the transition to remote work.
• 87% of large organizations already have adopted MFA solutions.
• 75% of IT leaders plan to increase MFA spending in the next year.

Context

Passwordless authentication is a human identity control, but modern environments also depend on machine identity and trusted digital interactions. When those adjacent identity layers are left outside the design, teams may reduce password risk without closing the broader authentication gap.

The article frames PKI and FIDO2 as complementary rather than competing controls. FIDO2 handles user-facing authentication, while PKI extends trust to devices, email, and documents where a passwordless flow does not apply.

For IAM programmes, the real question is not whether to adopt passwordless, but where authentication assurance stops. If certificate lifecycle, device trust, and signed communications are outside scope, the programme still has unresolved identity exposure.

Key questions

Q: How should security teams combine FIDO2 and PKI without creating overlap?

A: Use FIDO2 for strong human authentication and PKI for machine identities, email signing, encryption, and document trust. The two controls solve different problems. Teams should align each with the identity type and workflow they actually govern, then manage certificates and authenticators through separate but coordinated lifecycle processes.

Q: What breaks if an organisation tries to replace all authentication with FIDO?

A: Machine and device use cases can be left without a practical identity control because FIDO is designed primarily for interactive user authentication. Workload access, legacy environments, and certificate-dependent platforms may still need PKI-based identity assurance, so a FIDO-only plan can narrow coverage rather than improve it.

Q: Why do passwordless programmes still need strong lifecycle governance?

A: Passwordless shifts risk from passwords to issuance, recovery, and revocation. If those lifecycle steps are slow or unclear, users lose access, request exceptions, or reuse weaker paths to keep working. Strong lifecycle governance keeps the credential trusted throughout its usable life, not just at initial enrolment.

Q: What is the difference between human authentication and machine identity trust?

A: Human authentication proves a person is present and can complete a login flow, while machine identity trust proves a device, application, or service is authorised to participate in a transaction. They require different controls, different lifecycle management, and different failure handling. Conflating them is how identity programmes leave non-human access ungoverned.

Technical breakdown

Why FIDO2 does not cover every authentication use case

FIDO2 is designed around WebAuthn and CTAP, which make user login stronger by binding credentials to a device and eliminating shared passwords. That improves phishing resistance for human authentication, but it does not create a trust model for machines, signed email, or document integrity. In other words, it secures an interactive login path, not the full identity surface of a modern enterprise. Where organisations collapse all authentication requirements into one passwordless programme, they end up protecting the person while leaving adjacent trust relationships unmanaged.

Practical implication: Map each access and trust use case to the control that actually authenticates it, rather than assuming FIDO2 covers the full estate.

How PKI extends trust beyond user login

PKI uses asymmetric key pairs and certificate issuance through a trusted certificate authority to prove identity for users, devices, applications, and signed content. That makes it suitable for machine identity, email signing and encryption, and document signing, all of which depend on cryptographic trust rather than interactive user presence. The key distinction is that PKI governs assertion and verification across systems, not just login. For identity teams, PKI is the control family that turns authentication into a broader trust fabric.

Practical implication: Use certificate-based identity where the subject is a device, service, message, or document rather than a person at a browser prompt.

Why lifecycle management becomes the hard part of PKI adoption

The article points to policy, compliance, and lifecycle management as the main reasons PKI is difficult to run at scale. Certificates must be issued, renewed, revoked, and aligned to device and application change, which makes governance more operationally demanding than a single sign-in control. This is why teams often delay PKI even when they recognise the gap. Cloud delivery changes the operating model, but it does not remove the need for inventory, ownership, and renewal discipline.

Practical implication: Treat certificate lifecycle management as an identity governance problem, not a back-office cryptography task.

NHI Mgmt Group analysis

PKI and FIDO2 solve different trust problems, not competing versions of the same problem. FIDO2 hardens interactive user authentication, while PKI governs device, message, and document trust. IAM programmes that treat them as substitutes usually optimise one control path and leave adjacent identity surfaces exposed. The practical conclusion is that authentication architecture should be segmented by subject, not by vendor preference.

The missing control is not stronger login, but broader identity coverage. The article’s central point is that passwordless reduces one attack path without addressing machine identity, signed communications, or document integrity. That is a governance issue as much as a technical one, because the programme scope determines what can be trusted. Identity teams should define authentication boundaries explicitly and avoid calling the estate secure just because human login improved.

Machine identity turns PKI from a legacy control into a current governance requirement. The article notes that machines now outnumber humans by a factor of 3, which means certificate-backed trust is no longer a niche concern. As infrastructure becomes more distributed and cloud-oriented, the absence of machine identity governance becomes a scaling issue, not a feature gap. The implication is that certificate ownership and lifecycle controls belong in core IAM planning.

Trust in email and documents is part of identity governance, not a separate communications problem. Phishing resistance improves when messages can be signed, and contractual integrity improves when documents can be signed and verified. Those are identity assertions with business consequences, so they belong in the same governance conversation as login assurance. Teams that isolate them under separate tooling or ownership miss the fact that identity trust extends beyond the sign-in page.

Named concept: identity trust perimeter. FIDO2 and PKI together define the real perimeter of authentication assurance, which now stretches across humans, machines, messages, and documents. The article shows that perimeter thinking still matters, but the perimeter is identity-centric rather than network-centric. Practitioners should use that lens to decide where passwordless ends and certificate-based trust begins.

From our research library:

• 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.
• Read next: Machine Identity, PKI and Certificate Lifecycle Guide

What this signals

Identity trust perimeter: Programmes that stop at human login are defining the perimeter too narrowly. The practical boundary now includes machine identity, signed email, and signed documents, so governance needs to follow the trust object rather than the user interface.

Passwordless adoption often reduces one class of exposure while leaving certificate ownership, renewal, and revocation as under-governed chores. That gap matters because the same identity programme now has to cover both interactive login and non-interactive trust.

NHI Mgmt Group sees the more durable model as one where FIDO2 and PKI are each assigned to the trust problem they actually solve. That keeps the programme from overselling passwordless and underinvesting in the identity layers that operate outside the browser.

For practitioners

• Define authentication scope by identity type Separate human login, machine authentication, email trust, and document signing into distinct governance scopes before selecting controls.
• Use PKI for non-interactive trust Issue certificates for devices, applications, signed messages, and signed documents where a user-present flow is not appropriate.
• Inventory machine identities and certificate owners Maintain ownership, renewal responsibility, and revocation paths for devices, applications, and service identities that depend on certificates.
• Treat certificate lifecycle as governance Build renewal, revocation, and policy enforcement into the operating model so PKI does not become an unmanaged dependency.

Key takeaways

• FIDO2 strengthens user authentication, but it does not by itself secure machines, email, or documents.
• PKI fills the trust gap by extending cryptographic identity to devices and non-interactive interactions.
• IAM teams should separate login assurance from broader identity trust and govern each with the right control set.

Key terms

• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
• Public Key Infrastructure: Public Key Infrastructure is the trust system that issues, manages, and revokes digital certificates used to prove identity. In practice it binds keys to entities and policies, making authentication, encryption, and non-repudiation possible across users, devices, and services.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.