TL;DR: Most organisations still mistake certificates for device identity, but Smallstep argues that long-lived, manually issued, exportable credentials and ticket-based renewal leave Zero Trust enforcement porous. Strong device identity depends on unique, hardware-bound, short-lived credentials with automated lifecycle control, not compliance-visible certificate inventory.
At a glance
What this is: This is an analysis of why device identity fails when certificates are portable, with the key finding that certificate presence alone does not equal enforceable identity.
Why it matters: It matters because IAM, NHI, and Zero Trust programmes can look complete on paper while still allowing replayable credentials, weak audit evidence, and blind spots in access enforcement.
Context
Device identity is the control layer that lets a system decide whether a machine or workload should be trusted. The problem in this article is that many organisations stop at having certificates and assume the identity problem is solved.
That assumption breaks Zero Trust because portable, long-lived, or manually renewed credentials can be copied and replayed outside the original device. In identity governance terms, the gap is not issuance alone but binding, lifecycle control, and enforcement across endpoints and workloads.
The article is centred on device identity, but the governance lesson extends into NHI and IAM because the same failure pattern appears whenever credentials exist without strong ownership, automation, and revocation discipline.
Key questions
Q: What breaks when device identity is portable?
A: When a device credential can be copied or replayed, access logs still show a valid authentication while the original device may be absent. That breaks Zero Trust because the system is trusting the credential, not the bound device. The result is invisible lateral movement, weak forensic evidence, and a false sense of control.
Q: Why do long-lived device certificates create more risk than they remove?
A: Long-lived certificates extend the compromise window and make revocation less effective because attackers can keep using a valid credential long after the device changes state. They also encourage manual processes that produce renewal drift and inconsistent offboarding. The risk is not the certificate itself, but its lifespan and portability.
Q: How can security teams tell whether device identity is actually working?
A: The best signal is not perfect recognition, but stable performance across collision, division, and persistence scenarios. If the system can distinguish similar devices, maintain continuity when one device changes context, and avoid false resets after routine updates, it is likely working as intended.
Q: What is the difference between certificate management and machine identity management?
A: Certificate management focuses on discovery, renewal, monitoring, and revocation for certificates. Machine identity management is broader because it includes the credential, the owning workload, the trust path, the policy, and the lifecycle controls that keep non-human access governable. Organisations need the broader model when certificates are only one part of the access chain.
Technical breakdown
Why certificates are not the same as device identity
A certificate is only a cryptographic assertion; it becomes device identity only when the private key is bound to the device and the credential cannot be exported or replayed elsewhere. Long-lived, manually issued certificates stored in software keystores behave like portable secrets, not device-bound identity. That means authentication can succeed even when the request originates from a different host. In Zero Trust terms, the control is not the presence of a certificate but the strength of the binding between credential, hardware, and lifecycle. Practical implication: treat certificate inventory as evidence of issuance, not evidence of strong identity.
Practical implication: verify whether device credentials are non-exportable, short-lived, and hardware-bound before treating them as identity controls.
How portable credentials undermine Zero Trust enforcement
Zero Trust assumes credentials will be targeted and that trust must be continuously re-evaluated. If a device credential can be copied, the architecture can still log a valid authentication while the actual device is absent. That breaks the core premise of bound trust and makes posture checks, ZTNA decisions, and audit trails vulnerable to replay and impersonation. The technical failure is subtle because the control appears to work, but it authorises the credential rather than the device. Practical implication: design enforcement around proof of possession tied to the original device, not around certificate existence alone.
Practical implication: ensure access decisions depend on device-bound proof, not just a valid certificate or posture signal.
Why lifecycle automation matters for workload and device identity
Device identity becomes weak when renewal, revocation, and issuance depend on tickets or manual workflows. Manual processes create long-lived credentials, renewal gaps, and inconsistent offboarding, especially across endpoints, containers, and Kubernetes workloads. Automated lifecycle management shortens exposure and keeps the identity state aligned with the actual asset state. Without that automation, certificates drift into compliance artefacts while leaving the operational trust model unchanged. Practical implication: lifecycle control is part of identity strength, not an administrative convenience.
Practical implication: automate issuance, rotation, and revocation so device identity remains current across physical and ephemeral environments.
Threat narrative
Attacker objective: The attacker wants to authenticate as a trusted device or workload from outside the original host and use that trust to move laterally without triggering obvious alarms.
- Entry occurs when an attacker obtains a portable device credential, such as an exportable certificate or shared secret, from a software keystore, workflow, or compromised host.
- Credential abuse follows when the attacker replays that credential from a different machine while authentication logs still show a valid identity event.
- Impact emerges as lateral movement and impersonation become hard to distinguish from legitimate device access, weakening detection and response.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Portable device identity is a governance failure, not just a technical misconfiguration: When certificates can be copied, the organisation is not governing identity, it is merely inventorying cryptographic objects. That creates a gap between what compliance sees and what the access plane actually enforces. The practitioner conclusion is simple: if identity can move, the control is not device identity.
Certificate presence is not proof of trustworthiness: Many programmes equate a present certificate with a trustworthy device, but the article shows that long-lived, manually renewed, exportable certificates only prove that issuance occurred. They do not prove the credential is still bound to the right endpoint. The practitioner conclusion is to measure binding strength, not certificate count.
Zero Trust depends on unique identity for devices as much as for users and services: NCSC guidance is clear that all three identity classes must be verifiable before access decisions are trustworthy. The article shows that device identity is often the weakest of the three because it is treated as already solved. The practitioner conclusion is to bring device identity into the same governance discipline as human and service identity.
Cryptographic decoration is the right name for many current device programmes: If the private key is exportable, renewal is manual, or revocation is slow, the environment has the appearance of strong identity without the enforcement properties. That gap explains why logs look healthy while attackers still move. The practitioner conclusion is to redesign for bound, automated, short-lived identity rather than cosmetic certificate coverage.
Strong device identity requires lifecycle control, not just PKI artefacts: The real issue is not whether a certificate exists but whether issuance, storage, renewal, and revocation are aligned with device state. That makes device identity a programme problem spanning IAM, NHI governance, and infrastructure operations. The practitioner conclusion is to treat device identity as a governed lifecycle, not a one-time provisioning event.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- 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
Portable credential debt: When device identity is implemented as certificate inventory instead of hardware-bound trust, the organisation accumulates portable credential debt that Zero Trust cannot absorb. That debt shows up as replayable authentication, weak revocation, and a mismatch between audit evidence and real enforcement. The practical signal is to inspect where portability still exists in the device estate.
In practice, device identity should be governed with the same seriousness as service identity and privileged access. If the organisation cannot show a short lifecycle, non-exportable keys, and complete issuance-to-expiry traceability, then access decisions are still anchored in assumption rather than proof. That should trigger a programme review, not just a tooling refresh.
For practitioners
- Audit certificate portability Identify where device certificates live in exportable software keystores, shared volumes, or unmanaged renewal paths, then classify those cases as portable identity rather than trusted device identity.
- Bind keys to hardware Require TPM or secure enclave storage for private keys so credentials cannot be copied and replayed from another host.
- Shorten credential lifetimes Move device certificates from months or years to hours or days so compromise windows collapse quickly and expired credentials stop authorising access.
- Automate issuance and revocation Remove ticket-based renewal and manual offboarding from device identity workflows, because delayed lifecycle handling turns certificates into stale trust signals.
- Trace identity from issuance to expiry Maintain an audit trail that links issuance, use, and revocation events to each device credential so gaps in the trust chain are visible during investigations.
Key takeaways
- Device identity fails when certificates are portable, because a credential that can move away from the device can no longer prove the device is present.
- The article shows that manual renewal, exportable keys, and long-lived certificates create a silent gap between authentication logs and trustworthy access decisions.
- The limiting control is not more certificate inventory, but hardware binding, short-lived credentials, and automated lifecycle governance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Portable device credentials expand access beyond the intended device boundary. |
| NHI-07 — Long-Lived Secrets | The article centres on long-lived certificates that keep working after the trust state changes. | |
| Recommendation — Reduce excessive trust by binding each device credential to one device and one lifecycle. Shorten device credential lifetimes and automate renewal before credentials become stale trust artifacts. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | The article explicitly frames device identity as a Zero Trust prerequisite. |
| Recommendation — Require verifiable device identity before access decisions and do not rely on network location. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Device identity is part of the authorisation decision path described here. |
| Recommendation — Tie access permissions to bound device identity, not just certificate presence or posture signals. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issuance, rotation, and revocation are core authenticator management concerns. |
| Recommendation — Manage device authenticators with automated rotation, revocation, and lifecycle monitoring. | ||
Key terms
- Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.
- Persistent Credential: A persistent credential is a long-lived secret such as an API key, token, or service account that remains valid until it is rotated or revoked. In AI agent environments, persistent credentials create durable access paths that can survive task completion, hide in code or workflows, and widen blast radius when exposed.
- Hardware-Bound Key: A private key stored in hardware such as a TPM or secure enclave so it cannot be exported and reused on another host. In device identity programmes, hardware binding turns a certificate from a transferable secret into a stronger proof of possession.
- 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org