Certificate-based authentication for users, devices, and machines

At a glance

What this is: This is a practitioner guide to certificate-based authentication, showing how certificates can secure users, BYOD devices, and machines when managed through trusted identity lifecycles.

Why it matters: It matters because certificate-based controls are only as strong as the governance around issuance, revocation, and visibility across human, NHI, and device identities.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Axiad's guide to certificate-based authentication for users, devices, and machines

Context

Certificate-based authentication replaces shared trust with device- or identity-bound trust, using certificates to prove that a user, laptop, or machine is authorized to connect. For identity teams, the governance question is not whether certificates work, but whether the organisation can manage certificate lifecycle, revocation, and inventory at enterprise scale.

That makes this topic relevant across human IAM and NHI programmes. User access, BYOD device access, and machine authentication all depend on the same underlying controls: trusted issuance, timely revocation, and reliable visibility into where certificates live and how long they remain valid.

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 matter for non-human identities?

A: Certificates matter because they give service-connected machines, kiosks, and devices a verifiable identity that is harder to guess or reuse than a password. The security value comes from binding access to a cryptographic credential, but the governance burden shifts to visibility, revocation, and rotation. If those controls are weak, certificate-based trust can become hidden privilege.

Q: What breaks when certificate revocation is slow or incomplete?

A: When revocation is slow or incomplete, identities continue to authenticate after they should have been removed from trust. That creates stale access on decommissioned devices, orphaned machines, and former vendor-managed endpoints. The result is residual access that looks legitimate to systems but no longer matches business intent.

Q: How do organisations know if certificate-based authentication is actually reducing risk?

A: Organisations should measure certificate inventory accuracy, revocation latency, and the percentage of endpoints using current trust stores. If they cannot prove which certificates are active and who owns them, the control is only partially effective. Risk reduction shows up when expired or orphaned certificates are removed quickly and consistently.

Technical breakdown

How certificate-based authentication works across users and devices

Certificate-based authentication uses a trusted certificate authority to bind an identity to a cryptographic credential. At sign-in, the relying system checks whether the presented certificate chains to a trusted root, whether it is still valid, and whether it has been revoked. For users, the certificate may replace a password prompt. For devices and machines, it becomes the durable proof of identity used before network access or API communication is allowed. The control is only as strong as certificate inventory, revocation checking, and renewal discipline.

Practical implication: inventory every certificate path and enforce revocation checks before access is granted.

Why machine authentication raises NHI governance issues

Machine authentication turns certificates into non-human identities for endpoints, kiosks, and IoT devices. These identities often outlive the teams or vendors that originally provisioned them, which creates lifecycle drift. Hardcoded credentials are risky because they are easy to copy and hard to retire; certificates improve the model only when private keys are protected and expiry, rotation, and offboarding are enforced. The real failure mode is not authentication weakness alone, but unmanaged persistence of machine trust.

Practical implication: treat machine certificates as governed NHIs with ownership, expiry, and offboarding controls.

Certificate management, revocation, and trust stores

Certificate management is the operational layer that makes certificate-based authentication viable. It includes certificate issuance, renewal, revocation, distribution to endpoints, and maintenance of trust stores used by applications and devices. If revocation is delayed or trust stores are stale, authentication continues to accept identities that should no longer be trusted. In practice, certificate authentication fails less from cryptography and more from governance gaps around certificate lifecycle and exception handling.

Practical implication: connect certificate issuance and revocation to automated lifecycle workflows and monitor stale trust stores.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate-based authentication is only as mature as the identity lifecycle behind it. The mechanism can reduce password dependence, but it does not remove the need to know who or what owns each certificate, where it is deployed, and when it should be revoked. In practice, certificate trust becomes another form of identity sprawl if inventory and ownership are weak. Practitioners should treat certificates as governed identities, not just technical artifacts.

Machine certificates are NHI assets, not just endpoint configuration. The article’s machine authentication use case maps directly to NHI governance because kiosks, IoT endpoints, and service-connected devices behave like non-human identities with cryptographic credentials. When those certificates are hard to trace, the programme loses visibility into privilege, expiry, and offboarding. The practitioner conclusion is that machine trust must sit inside the same governance model as service accounts and API credentials.

Certificate-based authentication reduces one risk while exposing another: hidden trust persistence. A certificate can remain technically valid long after the business relationship, device assignment, or operational need has changed. That makes revocation timing and trust-store hygiene central controls, not administrative details. The governance lesson is that strong authentication does not equal strong lifecycle control.

Certificate trust is a control plane for identity, but not a substitute for identity governance. Organisations that adopt certificates without ownership, recertification, and exception management often create a quieter version of credential sprawl. The right question is not whether certificates are secure in theory, but whether the programme can prove every certificate still belongs in the trust fabric. Practitioners should measure certificate governance with the same rigour used for privileged access.

Identity blast radius is the real metric that certificate programmes change. Certificates can narrow exposure by binding access to known devices and machines, but only if scope, revocation, and inventory are aligned. If they are not, the blast radius simply shifts from password compromise to stale trust. Identity teams should evaluate certificate-based authentication as a containment model, not a complete control set.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Visibility gaps remain structural, not exceptional, and 97% of NHIs carry excessive privileges that widen the attack surface.
• For a broader view of lifecycle control and access sprawl, see 52 NHI Breaches Analysis.

What this signals

Certificate-based authentication will only become more valuable as organisations try to reduce password dependence across human and machine identities. The governance challenge is that certificate trust can expand faster than teams can inventory, recertify, and revoke it. That is why certificate programmes should be evaluated as lifecycle controls, not just authentication features.

Trust fabric drift: when certificate trust stores, issuance systems, and revocation processes fall out of sync, authentication starts accepting identities that the business no longer owns. That failure mode matters because it turns a cryptographic control into hidden standing access. The programme response is to bring certificates under the same governance discipline used for privileged NHI credentials and endpoint lifecycle.

As device fleets, kiosks, and hybrid work endpoints continue to multiply, identity teams will need better visibility into where certificates are deployed and which ones still map to active business need. In practice, the next maturity step is not broader certificate adoption but tighter ownership, faster revocation, and continuous trust-store hygiene.

For practitioners

• Map certificate ownership to every identity type Assign a business owner and technical owner to each user, device, and machine certificate so revocation decisions are unambiguous when roles change or devices are retired.
• Tie certificate revocation to offboarding events Link certificate revocation to JML, device retirement, and vendor offboarding workflows so trust is removed when the identity is no longer active.
• Track trust store drift continuously Scan applications and endpoints for stale trust stores, expired roots, and unmanaged certificate chains that still validate access.
• Separate human, device, and machine certificate policies Use different issuance, renewal, and expiry rules for people, BYOD devices, and machines because their risk profiles and lifecycle timings are not the same.

Key takeaways

• Certificate-based authentication is a governance problem as much as a technical control.
• Machine and device certificates behave like NHIs, so lifecycle ownership and revocation matter as much as cryptography.
• Without visibility and offboarding discipline, certificate trust can become stale access rather than reduced risk.

Key terms

• Certificate-Based Authentication: A method of proving identity with a digital certificate instead of a shared password. In practice, the certificate binds a user, device, or machine to a trusted cryptographic identity, but its security depends on issuance discipline, revocation speed, and accurate trust-store management.
• Trust Store: A set of certificates that a system accepts as trusted for authentication or encryption decisions. If the store is stale or poorly maintained, systems may continue accepting identities that should no longer be valid, which turns trust management into an operational security risk.
• Machine Identity: A non-human identity used by devices, workloads, or connected systems to authenticate and communicate. Certificates are one common form of machine identity, but they only deliver value when ownership, renewal, and offboarding are managed as a lifecycle, not a one-time setup.

Deepen your knowledge

Certificate-based authentication, NHI lifecycle governance, and revocation discipline are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for devices, kiosks, or machine identities, it is worth exploring.

This post draws on content published by Axiad: 3 Key Use Cases for Certificate-Based Authentication. Read the original.