Client certificate provisioning on devices: zero trust trade-offs

At a glance

What this is: This is a hands-on blog about issuing and installing client certificates on endpoints to support device authentication and zero trust access control.

Why it matters: It matters because device-bound identity controls only reduce risk when IAM, lifecycle, and revocation processes are tight enough to keep certificate trust aligned with actual device state.

By the numbers:

• 69% of organisations now have more machine identities than human ones.
• Only 38% have automated certificate lifecycle management in place.

👉 Read Cybertrust Japan's walkthrough of client certificate setup for device authentication

Context

Client certificate authentication is a device identity pattern, not just an encryption feature. In practice, it binds access to an endpoint-specific credential, which can improve control over who or what is connecting, but only if the certificate is issued, stored, and revoked with the same discipline as the device itself.

The governance problem is that certificate-based device trust often assumes the endpoint remains known, managed, and current. Once devices move across users, operating states, or ownership boundaries, the certificate becomes a non-human identity lifecycle issue, not merely a deployment detail.

Key questions

Q: How should security teams govern client certificates for managed devices?

A: Treat client certificates as identity credentials with a full lifecycle, not as deployment artifacts. That means tying issuance to enrollment, maintaining ownership metadata, monitoring expiry, and revoking certificates when devices change state or leave service. Without those controls, the certificate can remain trusted long after the endpoint should not be.

Q: Why do client certificates create governance risk if revocation is weak?

A: Because the certificate can outlive the device assurance that justified it. If a certificate stays valid after a laptop is reassigned, lost, or rebuilt, the access path still looks legitimate to the service. The risk is not the certificate itself, but the gap between issuance and retirement.

Q: What is the difference between device authentication and device trust?

A: Device authentication proves possession of a credential, while device trust is the broader judgement that the endpoint is still authorised, managed, and acceptable for access. A certificate can support authentication, but it does not automatically prove current trust. That is why lifecycle controls and posture checks matter.

Q: How can organisations reduce risk from stale endpoint credentials?

A: Use short certificate validity periods, automated renewal, and immediate revocation when devices are offboarded or reassigned. Then enforce certificate acceptance only through services that check current policy state. This reduces the chance that an old credential remains a valid access route.

Technical breakdown

How client certificate authentication binds access to a device

Client certificate authentication uses a certificate and private key on the endpoint to prove possession during TLS-based connection setup. The server validates the certificate chain, trust anchor, and policy conditions before granting access. In identity terms, the certificate becomes the device’s credential, and the private key becomes the control point. This pattern can reduce password dependence and support stronger endpoint assurance, but it does not verify the device’s current security posture by itself. The access decision still depends on issuance policy, certificate validity, revocation handling, and whatever conditional checks sit around the connection.

Practical implication: tie certificate issuance to device enrollment and revocation to device offboarding, not to ad hoc provisioning steps.

Why certificate lifecycle is the real control plane

Certificate-based access fails when lifecycle management is weak. Issuance, renewal, rotation, suspension, and revocation are the actual governance controls, because the credential’s trust value is entirely time-bound. If certificates are distributed manually, stored without ownership metadata, or left valid after a device changes hands, the trust model becomes stale. For NHI governance, this is the same failure pattern seen in workload identities and service accounts: the credential outlives the assurance that justified it. A certificate is only as current as the process that retires it.

Practical implication: treat certificate lifecycle events as identity events and put them under explicit ownership and audit.

What zero trust does and does not solve here

Zero Trust Architecture does not remove the need for device identity. It assumes continuous verification, but that verification still relies on trustworthy identity evidence such as certificate status, device posture, and policy context. If the endpoint certificate is copied, stale, or issued without enough device binding, zero trust becomes a gate around a weak credential rather than a meaningful assurance model. The strongest designs combine device certificates with conditional access, short validity windows, and clear recovery paths for lost or replaced endpoints. Zero trust is an operating model, not proof that the endpoint itself is trustworthy.

Practical implication: pair certificate authentication with continuous validation signals and defined revocation triggers.

Threat narrative

Attacker objective: The objective is to preserve or reuse trusted endpoint access after the device no longer meets the conditions under which the certificate was issued.

1. Entry occurs when a device certificate is provisioned onto a managed endpoint and used as the primary access credential.
2. Escalation occurs if that certificate remains valid after the device changes owner, state, or trust context, allowing access beyond the intended lifecycle.
3. Impact is unauthorized access through an identity that still looks legitimate to the control plane even though the underlying device assurance is no longer current.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Device certificates are only as strong as the lifecycle behind them. The article shows a familiar pattern: strong endpoint authentication on paper, but trust that depends on manual issuance, distribution, and installation discipline. That is not an access control problem alone. It is a governance problem in which certificate state, device state, and ownership state must stay aligned, or the credential becomes a durable exception instead of a control.

Certificate-based device trust is a Non-Human Identity problem in disguise. The credential is not human, but it still needs inventory, ownership, rotation, and revocation. Organisations that manage device certificates as an infrastructure task rather than an identity lifecycle task usually discover the gap only after the endpoint fleet grows or the offboarding process fails.

Certificate lifecycle drift: the trust gap appears when a certificate remains valid after the endpoint context has changed. The article’s workflow makes clear that issuance is easy and retirement is the hard part. That is the point where zero trust programmes often become performative, because the access decision still depends on a credential whose original assurance no longer exists. Practitioners should read this as a lifecycle failure mode, not a tooling limitation.

Device-bound authentication can improve assurance, but it does not remove the need for conditional policy. A certificate proves possession of a key, not that the device is compliant, current, or still in service. Mature governance therefore has to combine certificate trust with posture checks, renewal controls, and revocation that is tied to asset change events. Otherwise the organisation is simply extending password-era assumptions into a stronger-looking credential model.

The market signal is clear: endpoint identity and non-human identity governance are converging. Device certificates, workload identities, and service credentials are all lifecycle-managed trust objects. The organisations that will manage this well are the ones that stop treating issuance as the finish line and start treating revocation and renewal as first-class controls. For practitioners, that means aligning IAM, endpoint, and platform teams around one identity governance model.

From our research:

• Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
• 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility.
• The lifecycle problem is broader than certificates alone, so practitioners should also read Ultimate Guide to NHIs , Key Challenges and Risks for the governance patterns behind visibility and ownership gaps.

What this signals

Certificate-based device trust is becoming an identity governance issue, not just an endpoint-security one. As organisations scale managed devices, the operational burden shifts from issuance to renewal, revocation, and ownership discipline. Teams that do not connect endpoint management with IAM will keep seeing valid credentials attached to invalid trust states.

With 88.5% of organisations saying non-human IAM lags human IAM, per the 2024 Non-Human Identity Security Report, endpoint certificates fit the same maturity gap pattern. The control may look different, but the governance failure is the same: trust objects are managed without enough lifecycle rigor. That gap is where access persists beyond intent.

The practical signal for IAM, endpoint, and security architecture teams is to unify device certificates, workload credentials, and service accounts under one governance model. If ownership, expiry, and revocation are handled differently in each domain, the organisation will keep creating stale trust paths that look compliant until they are tested.

For practitioners

• Map certificate ownership to device ownership Assign a business and technical owner to every device certificate, then require ownership updates when the endpoint is reassigned, retired, or repurposed.
• Bind certificate issuance to managed enrollment Only issue client certificates through controlled enrollment flows tied to asset inventory, so manual installation does not become an uncontrolled trust path.
• Automate revocation on device change events Trigger certificate revocation when devices are lost, replaced, decommissioned, or reassigned, and verify revocation is enforced at the relying service.
• Pair certificates with conditional access checks Require posture, compliance, or risk signals alongside certificate validation so a valid credential is not the only factor granting access.

Key takeaways

• Client certificates strengthen device authentication only when the organisation can also prove lifecycle control.
• The evidence points to a familiar NHI pattern: issuance is easy, but ownership, revocation, and auditing are where governance fails.
• Zero trust does not eliminate certificate trust assumptions, so practitioners need lifecycle controls and conditional access together.

Key terms

• Client Certificate Authentication: A method of proving a device or user possesses a trusted private key and certificate during connection setup. In identity programmes, it functions as an authentication credential, but its security depends on how tightly issuance, storage, renewal, and revocation are governed across the endpoint lifecycle.
• Certificate Lifecycle Management: The operational control set for issuing, renewing, rotating, suspending, and revoking certificates. For NHI governance, it is the difference between a credential that reflects current trust and one that keeps granting access after the underlying device state has changed.
• Device-bound Identity: An identity model where access is tied to a specific endpoint or managed device rather than a person alone. It is useful for reducing password dependence, but it creates governance obligations around enrollment, reassignment, decommissioning, and proof that the device still deserves trust.
• Zero Trust Architecture: A security model that assumes no connection is trusted by default and requires continuous verification. In practice, certificate-based device trust only supports Zero Trust when the certificate state, endpoint state, and policy state are checked together, not treated as interchangeable.

What's in the full article

Cybertrust Japan's full blog covers the operational detail this post intentionally leaves for the source:

• The exact CloudGate UNO configuration steps used to issue and install the device certificate.
• The registration workflow for device identifiers, certificate names, and email delivery settings.
• The practical setup sequence for enabling client authentication and device restriction on managed endpoints.
• The CSV-based bulk registration method for environments with many managed devices.

👉 Cybertrust Japan's full post shows the configuration flow, device registration steps, and endpoint installation details.

Deepen your knowledge

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