Device identity certificates at the endpoint: client auth tested

At a glance

What this is: This is a client authentication walkthrough showing how device identity certificates were issued to an iPhone endpoint and used to verify access through HENNGE One integration.

Why it matters: It matters because endpoint-bound certificates are only as strong as the lifecycle, device ownership, and offboarding controls around them, which is a familiar failure pattern across NHI, device, and human identity programmes.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 69% of organisations now have more machine identities than human ones.

👉 Read Cybertrust Japan's walkthrough of client authentication with device identity certificates

Context

Device identity certificates are a way to bind trust to a specific endpoint rather than to a reusable password or broad network location. In this article, Cybertrust Japan demonstrates client authentication by issuing a device certificate to an iPhone and using it with HENNGE One, which puts endpoint identity and access control into the same governance conversation.

For IAM teams, the practical issue is not whether certificate-based access can work. It is whether the organisation can keep device ownership, enrollment, issuance, and revocation aligned as endpoints move, change hands, or leave service. That is the same lifecycle problem seen in other identity domains, only here the identity subject is the device itself.

Key questions

Q: How should security teams govern device certificates on managed endpoints?

A: Security teams should treat device certificates as governed identities with owners, lifecycle states, and revocation triggers. The certificate should be issued only after the device is enrolled, mapped to an asset record, and tied to a clear decommissioning path. That keeps access decisions aligned to current device state rather than stale trust.

Q: Why do endpoint certificates create governance risk if lifecycle is weak?

A: Endpoint certificates create risk when they outlive the device state they were meant to represent. If the certificate is still valid after a device is retired, reassigned, or lost, access can continue without an accountable owner. The result is dormant trust that behaves like standing privilege for a device.

Q: What breaks when certificate revocation is manual?

A: Manual revocation breaks at scale because the organisation cannot reliably keep pace with device turnover, reassignment, and incident response. Stale certificates accumulate, endpoint inventories drift, and access continues longer than intended. The control failure is not cryptography, but operational lag between device change and certificate removal.

Q: How do teams decide whether to use certificates or passwords for endpoint access?

A: Certificates are better when the goal is to bind access to a specific managed endpoint and reduce shared or reusable secrets. Passwords are weaker for device-level trust because they do not prove device possession. Teams should choose certificates when they can support enrollment, revocation, and asset reconciliation as part of normal operations.

Technical breakdown

How device identity certificates bind access to an endpoint

A device identity certificate is a cryptographic credential issued to a specific endpoint and presented during authentication. Unlike a password, it proves possession of a private key tied to that device. In the article, the certificate is used as part of client authentication, so the access decision depends on both the identity provider and the endpoint holding the correct certificate. This pattern reduces reliance on user memorisation, but it also makes enrollment, key protection, and certificate issuance integrity the real control plane. If the certificate can be copied, exported, or installed outside policy, the trust model collapses.

Practical implication: Treat device certificates as governed identities, not just technical artefacts, and track issuance to a named device owner and enrollment state.

Client authentication versus endpoint authentication

Client authentication verifies that the connecting client possesses a valid credential. Endpoint authentication goes further by trying to confirm the device itself, often through device IDs, managed status, or hardware-backed identity signals. The article’s workflow combines certificate issuance with device registration data such as the iPhone UDID, which creates a stronger link between the credential and the endpoint. The security value depends on how tightly that device binding is enforced and whether the certificate remains valid after the device changes state. Without lifecycle control, certificate-based trust can outlive the device that was originally enrolled.

Practical implication: Make certificate validity contingent on managed device state, not just on initial enrollment.

Why certificate lifecycle matters more than certificate issuance

The hardest part of certificate-based access is not creating the certificate, but managing what happens after issuance. Enrollment, replacement, retirement, and revocation determine whether the certificate still represents a trusted device. The article’s manual steps, including registration through the service console and prompt installation on the endpoint, show how much operational discipline is required even in a simple rollout. That same discipline becomes fragile at scale when dozens or thousands of devices need policy-consistent handling. In identity terms, this is lifecycle governance applied to endpoints rather than people or service accounts.

Practical implication: Build revocation and replacement workflows before broad deployment, because issuance alone does not create durable trust.

NHI Mgmt Group analysis

Device certificate governance is endpoint identity governance, not a niche authentication add-on. When an organisation issues a certificate to a phone or laptop, it is creating a governed identity with a lifecycle, an owner, and an offboarding requirement. The article shows that access control becomes inseparable from device registration and certificate handling. Practitioners should treat endpoint certificates as a formal identity class, not as a convenience feature.

Certificate trust depends on the same ownership discipline that governs NHIs. A certificate only proves something useful when the organisation can answer who enrolled it, which endpoint it belongs to, and when it must be revoked. That is the same ownership problem that weakens service account governance when inventories and revocation processes are incomplete. The implication is straightforward: visibility and accountability matter as much for devices as they do for machine identities.

Ephemeral endpoint trust debt: the moment a device certificate is issued, the organisation also assumes a future revocation obligation. If enrollment, replacement, and decommissioning are handled manually, that debt accumulates across every managed endpoint. The practical conclusion is that endpoint certificate programmes fail when lifecycle operations remain ad hoc.

Client authentication strengthens access decisions only when device state is continuously governable. The article’s approach demonstrates that a certificate can be paired with device metadata to make access more selective. But selectivity is not the same as resilience. If access remains valid after device handoff, loss, or retirement, the control becomes a static permission rather than a living trust signal. Practitioners should view certificate-based access as a governance programme with cryptographic plumbing, not a standalone security fix.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly identity inventories degrade when ownership is unclear.
• That same governance gap is why teams should start with the Top 10 NHI Issues when they need to prioritise lifecycle controls and visibility work.

What this signals

Endpoint certificate programmes will increasingly be judged on lifecycle quality, not enrollment success. The real question for IAM and device teams is whether revocation, reassignment, and asset reconciliation happen quickly enough to keep certificate trust meaningful. Where that process is weak, endpoint certificates become another form of stale identity entitlement rather than a control.

With 57% of organisations lacking a complete inventory of their machine identities, per the Ultimate Guide to NHIs, the same inventory problem is likely to surface wherever certificates are issued without lifecycle ownership. Device identity is no exception to the visibility rule.

Certificate trust debt: every device certificate issued today creates future work for revocation, reassignment, and audit. If organisations do not connect endpoint management, IAM, and offboarding discipline, they will accumulate silent access drift across the fleet.

For practitioners

• Map certificate issuance to a named device owner Require every endpoint certificate to record the user, business purpose, and managed device record before access is granted. This creates a clear revocation path when the device changes status or leaves service.
• Tie certificate validity to device lifecycle state Revoke or suspend certificates when the endpoint is retired, reassigned, or removed from management. The certificate should fail closed if the device no longer satisfies enrollment policy.
• Automate enrollment and revocation workflows Replace console-only issuance steps with policy-driven workflows that can issue, replace, and revoke certificates consistently across fleets. Manual handling does not scale once device counts increase.
• Audit endpoint certificate inventory regularly Check for orphaned certificates, stale enrollments, and devices that no longer match the asset record. Certificate inventories should reconcile with endpoint management records and access logs.
• Use device certificates as one signal, not the only signal Combine certificate trust with managed device posture, ownership, and access policy so a stolen or misassigned certificate does not become a free pass.

Key takeaways

• Device certificates improve endpoint-bound access only when ownership and lifecycle controls are explicit.
• The main governance failure is not issuance, but stale trust after device change or retirement.
• IAM and endpoint teams need shared inventory and revocation discipline before certificate use scales.

Key terms

• Device Identity Certificate: A device identity certificate is a cryptographic credential issued to a specific endpoint so it can prove possession of a trusted private key during authentication. In practice, it turns the device into a managed identity with an enrollment record, lifecycle state, and revocation requirement.
• Client Authentication: Client authentication is the process of verifying that the connecting client is allowed to access a service. In certificate-based setups, the service checks a presented certificate and its trust chain, then combines that signal with policy, device state, or user context before granting access.
• Certificate Lifecycle: Certificate lifecycle is the full chain of issuance, deployment, renewal, replacement, suspension, and revocation. For endpoint identities, lifecycle quality determines whether a certificate still represents the right device or has become stale trust that outlives the asset it was meant to protect.
• Endpoint Binding: Endpoint binding is the practice of linking a credential to a specific device or managed asset so it cannot be treated as a reusable secret. The control is only as strong as the organisation's ability to keep the asset record, enrollment state, and revocation logic in sync.

What's in the full article

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

• The step-by-step device certificate issuance flow from the HENNGE One admin console.
• The exact endpoint registration choices used to bind the certificate to the iPhone UDID.
• The operational sequence for installing the certificate on the client device and validating access.
• The vendor's trial and deployment notes for teams evaluating certificate-based client authentication.

👉 Cybertrust Japan's full post shows the setup steps, endpoint registration flow, and validation process.

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 identity lifecycle management, it is worth exploring.