They inventory all device certificates, define ownership for issuance and revocation, and review whether renewal and decommissioning are actually enforced. The same lifecycle discipline used for service accounts applies here, but device ecosystems add manufacturing, firmware, and operator handoff points that must be explicitly governed.
Why This Matters for Security Teams
Connected devices are often treated like inventory, but their certificates are living identities that can outlast the hardware, the operator, or the business purpose they were created for. That makes certificate lifecycle discipline a core identity control, not a niche PKI task. If issuance, renewal, replacement, and revocation are not owned and enforced, device certificates become durable access paths that bypass normal access review. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s NHI Lifecycle Management Guide is clear: lifecycle, not issuance alone, is where most NHI risk accumulates.
This matters because devices introduce extra handoff points that human identity programs often do not model well. Certificates may be embedded at manufacturing, loaded by a field technician, renewed by an agent, or left active after decommissioning. Those transitions create blind spots unless ownership and enforcement are defined end to end. In practice, many security teams discover certificate sprawl only after a device fleet is retired, repurposed, or compromised, rather than through intentional lifecycle governance.
How It Works in Practice
Identity teams usually apply the same discipline used for service accounts, then adapt it to device realities. The first step is an authoritative inventory of all device certificates, including device class, issuing CA, purpose, expiration, and owner. From there, each certificate needs a named business or technical owner who is responsible for renewal approvals, revocation requests, and decommissioning. Without that accountability, certificate management becomes a shared assumption that no one actually executes.
Operationally, the control set usually includes:
- Short certificate TTLs where the device can support automated renewal.
- Automated renewal workflows that fail closed when attestation or health checks do not pass.
- Revocation processes tied to asset retirement, device loss, ownership transfer, or firmware replacement.
- Evidence that certificates are removed or replaced during decommissioning, not merely marked inactive in an asset system.
For connected devices, the lifecycle also needs to account for manufacturing and operator handoff. Some environments issue certificates before first boot, while others load them during onboarding or provisioning. Best practice is evolving toward stronger linkage between device identity, hardware trust, and certificate issuance so that a certificate is not just valid, but valid for that specific device state. NHIMG’s Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs both reinforce that visibility and rotation are inseparable from governance.
The practical test is simple: can the organisation prove who can issue, who can renew, who can revoke, and what event closes the certificate’s life. These controls tend to break down when devices are deployed through third-party channels because ownership, telemetry, and revocation authority are split across vendors and internal teams.
Common Variations and Edge Cases
Tighter certificate control often increases operational overhead, requiring organisations to balance stronger assurance against device uptime, field support, and manufacturing constraints. That tradeoff is especially visible in long-lived industrial, medical, or IoT environments where devices may remain active for years and cannot tolerate frequent credential churn.
One common edge case is embedded or offline devices that cannot call home for frequent renewal. In those environments, current guidance suggests using longer-lived certificates only when compensating controls exist, such as segmented networks, constrained trust stores, and strict replacement schedules. Another exception appears during factory provisioning, where a certificate may be loaded before the device ever reaches the organisation. That handoff should still be governed as issuance, not as an informal shipping step.
There is also no universal standard for how much certificate automation is enough. Some fleets can support fully automated rotation, while others need staged renewal windows, maintenance checkpoints, or operator validation. The key is that the control remains enforceable, observable, and tied to the device lifecycle rather than to a calendar alone. NHIMG’s Top 10 NHI Issues highlights why lifecycle failures, not just weak crypto, are often the real risk. For regulated device classes, the EU Cyber Resilience Act also signals that product security and lifecycle accountability are moving closer together.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Certificate renewal and revocation failures are classic NHI lifecycle issues. |
| NIST CSF 2.0 | PR.AC-1 | Device certificates are authenticators that must be managed across their lifecycle. |
| NIST AI RMF | Lifecycle accountability and governance support trustworthy system operation across assets. |
Track every device certificate to expiration and revoke or rotate it through a defined owner workflow.
