Certificate-based authentication exposes the limits of password-era IAM

At a glance

What this is: This is an explanation of certificate-based authentication and the operational controls it depends on, with the key finding that stronger login methods still rely on disciplined certificate and token management.

Why it matters: It matters because IAM teams cannot treat phishing-resistant authentication as a finish line when certificate lifecycle, hardware security and credential issuance remain governance problems.

Context

Certificate-based authentication is a password alternative that uses a trusted certificate, a hardware token or smartcard, and a PIN to prove identity before access is granted. The article argues that the primary problem is not whether the login method is stronger, but whether IAM teams can govern certificates with the same discipline they apply to passwords and other authenticators.

For identity programmes, the issue is lifecycle control. Certificates live on devices, depend on a Certificate Authority, and must be issued, protected, presented and eventually retired in a controlled way. That makes the control relevant to human IAM, but also to broader identity governance because the failure mode is not just weak authentication, it is unmanaged authenticators.

Axiad positions certificate-based authentication as mature and widely supported across operating systems, applications and IAM platforms, but the operational burden shifts to provisioning, user support and certificate management. That is a typical starting point for organisations moving beyond password-era assumptions.

Key questions

Q: How should security teams govern certificate-based authentication for machines and devices?

A: Security teams should govern certificates as identities with owners, lifecycles, and revocation triggers, not as static configuration files. That means linking issuance to approved use cases, enforcing expiry and renewal, and revoking certificates when a device, vendor, or system is retired. Without lifecycle control, certificate-based authentication can preserve stale trust instead of reducing risk.

Q: Why do certificates reduce phishing risk compared with passwords and OTPs?

A: Certificates reduce phishing risk because the attacker is no longer trying to harvest a reusable secret from the user. Access depends on possession of a trusted hardware token or smartcard, plus a local PIN and a valid certificate chain. That makes remote credential capture much harder, but it does not remove the need for secure storage and revocation.

Q: What breaks when certificate lifecycle management is not integrated with PKI operations?

A: Manual certificate management does not scale once certificate counts rise and lifetimes shrink. Without integrated lifecycle management, renewals become inconsistent, revocations lag, and teams lose visibility across internal, public, and cloud-native authorities. That creates outage risk and weakens trust assurance, especially in environments with many applications, workloads, and device identities.

Q: What should teams do when moving from passwords to certificate-based authentication?

A: Teams should redesign authentication around device-bound credentials, not simply swap one sign-in factor for another. That requires integration with IAM platforms, user support for self-enrolment, a trusted Certificate Authority process and clear offboarding rules for lost or compromised tokens. The goal is to make certificate use operationally sustainable before broad rollout.

Technical breakdown

How PKI-based certificates prove identity at login

An authentication certificate is a cryptographic credential issued by a Certificate Authority and trusted by a relying system during sign-in. The user presents the certificate through a hardware token or smartcard, and the system checks that the certificate is valid, trusted and bound to the intended identity before access is granted. In practice, the certificate is not the whole control. The hardware store, the PIN and the trust chain together make the authentication event work. This is why certificate-based authentication can resist phishing better than passwords: the credential is not simply typed into a fake page. Practical implication: treat certificate trust chains and token security as part of the authentication design, not as back-office administration.

Practical implication: design authentication around certificate trust, token protection and PIN enforcement as one control surface.

Why password-era IAM breaks under phishing-resistant authentication

Password-era IAM assumes the secret is memorised, reusable and exchangeable across many services. Certificate-based authentication breaks that assumption by tying access to a device-bound credential and a local proof such as a PIN. That changes the attack surface. Phishing can still target users, but it is no longer sufficient to trick them into revealing a reusable secret. The remaining risk shifts toward token theft, certificate extraction, weak PIN practices and poor lifecycle governance. This is why the article places so much weight on credential management systems and hardware hardening. Practical implication: evaluate IAM controls by whether they govern certificate issuance and revocation, not by whether they only handle passwords and OTPs.

Practical implication: map your IAM controls to certificate issuance, revocation and device binding rather than password workflows.

What certificate lifecycle management must cover

Certificate-based authentication depends on a lifecycle that starts with issuance and ends with retirement. Between those points, teams need inventory, storage protection, access to the token or smartcard, PIN governance and revocation when the credential is no longer valid. A certificate that is technically strong but operationally unmanaged becomes a standing identity risk, especially when users move, devices are replaced or trust relationships change. The article also points to self-enrolment and cloud-based credential management as operational capabilities, which means the governance challenge is not just about cryptography. It is about who can create, control, recover and disable the credential over time. Practical implication: govern certificate lifecycle as an identity process, not as a purely technical PKI function.

Practical implication: include issuance, storage, recovery, revocation and retirement in the certificate governance model.

Threat narrative

Attacker objective: The objective is to impersonate a valid user and gain access to enterprise resources without needing the user’s physical token or certificate PIN.

1. Entry occurs when an attacker targets password-based or OTP-based sign-in paths, because those methods remain exposed to phishing and credential capture.
2. Credential compromise follows when a reusable secret is harvested or an MFA method is bypassed, creating a path into enterprise access.
3. Impact occurs when the attacker uses the captured identity to reach Windows, macOS or SaaS resources that still trust password-era authentication patterns.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate-based authentication exposes a governance problem, not just an authentication upgrade. The article shows that stronger login methods still depend on lifecycle discipline, token security and certificate trust management. That means the real question for IAM leaders is whether their programme can govern authenticators that live on hardware, depend on a Certificate Authority and expire or move with the user. The practitioner implication is that authentication modernisation must include credential governance, not only user experience change.

Passwords are not the only thing being displaced here, the control assumption is too. Password-era IAM assumes access can be defended by a memorised secret or a fallback MFA factor. Certificate-based authentication shifts the control boundary to device possession, local PIN protection and trusted issuance, which means the IAM programme must now own the lifecycle of the authenticator itself. The practitioner implication is that certificate governance becomes part of identity architecture, not a support function.

Certificate lifecycle is the hidden control plane behind phishing-resistant authentication. The article makes clear that a certificate on a token or smartcard is only useful if issuance, storage, recovery, revocation and retirement are all managed. That aligns with OWASP-NHI thinking even though the article is about human access, because the same lifecycle mistakes appear whenever credentials outlive their intended use. The practitioner implication is to measure authentication maturity by how well the organisation controls authenticators after they are issued.

Phishing resistance is durable only when IAM programmes stop treating credentials as interchangeable. CBA reduces exposure to password replay, but it does not eliminate the need for trusted hardware, PIN discipline and credential management systems. In NHIMG terms, this is where identity attack surface reduction becomes operational rather than aspirational. The practitioner implication is that organisations should decide whether their current IAM operating model can sustain device-bound credentials at scale before they commit to rollout.

Machine-like control logic is now reaching human authentication, and that narrows the gap between human IAM and NHI governance. The same lifecycle questions that govern service accounts, certificates and tokens now apply to user authenticators as well. That convergence matters because the operational failure mode is identical: a credential exists longer than its governing process can explain or control. The practitioner implication is to align authentication, lifecycle and offboarding governance across human and non-human identity programmes.

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.

What this signals

Certificate-based authentication changes the control problem from secret memorisation to credential lifecycle governance. Teams that modernise sign-in without revisiting issuance, revocation and hardware protection will recreate old risks in a new form. The practical signal is that authentication maturity now depends on whether the organisation can manage certificates as living identities, not static credentials.

Phishing resistance does not eliminate governance debt. A certificate on a token or smartcard still needs inventory, trusted storage, recovery rules and timely revocation. IAM and identity teams should expect rollout friction to move from password policy enforcement into lifecycle orchestration and user support.

For practitioners

• Assess certificate lifecycle ownership Map who issues, stores, renews, revokes and retires authentication certificates across all user populations and devices.
• Harden token and smartcard handling Require hardware-backed storage, local PIN protection and loss-response procedures for every certificate-bearing token or smartcard.
• Separate issuance from access approval Make certificate issuance, renewal and revocation dependent on explicit identity state changes rather than informal help desk action.
• Test phishing-resistant sign-in paths Validate that Windows, macOS and supported SaaS login flows actually accept certificate-based authentication without fallback weakness.
• Build certificate recovery and revocation playbooks Define how to recover access when a token is lost and how to revoke trust immediately when a credential is compromised or no longer needed.

Key takeaways

• Certificate-based authentication is stronger than password-era sign-in, but only if the organisation governs the certificate and the hardware token as part of the identity control plane.
• The article’s core warning is operational, not cryptographic: unmanaged issuance, recovery and revocation can turn a strong authenticator into a standing access risk.
• IAM teams should treat certificate lifecycle management as a prerequisite for phishing-resistant authentication, not as an implementation detail.

Key terms

• Certificate-based authentication: A method of proving identity using a cryptographic certificate and the associated private key rather than a reusable password. In identity programmes, it raises the bar for theft and replay because the secret is bound to lifecycle, issuance, and revocation control.
• Certificate Authority Services: Certificate Authority Services are the trust services that issue and manage digital certificates for users, applications, and machines. They anchor encrypted communication by proving identity and supporting certificate lifecycle controls such as issuance, renewal, revocation, and validation across enterprise systems.
• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• 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.