Teams often assume certificates solve trust on their own. PKI only provides durable identity if issuance, renewal, revocation, and inventory are governed continuously. Without those controls, certificates become long-lived credentials that are difficult to retire and easy to overlook in large device populations.
Why This Matters for Security Teams
Connected devices often outlive the assumptions made when their certificates were first issued. That creates a false sense of trust: security teams see a valid certificate and assume the device is still authorised, still managed, and still operating within policy. In practice, PKI is only one part of device trust. It has to be paired with inventory, lifecycle governance, and detection of unmanaged endpoints, which is why identity-focused guidance such as NIST SP 800-207 remains relevant even for device-heavy environments.
The risk is not just expiry. It is drift. Devices move between owners, environments, and use cases, while their credentials remain valid far beyond the point where the original trust decision made sense. That can undermine segmentation, access control, and incident response. For teams responsible for IoT, OT, medical, or embedded systems, PKI can become a hidden dependency that looks mature on paper but is weak in operation if certificate states are not continuously reconciled with asset state.
In practice, many security teams encounter certificate trust failures only after an old device has already retained access longer than intended, rather than through intentional lifecycle control.
How It Works in Practice
PKI for connected devices works best when identity is treated as a lifecycle process rather than a one-time enrollment event. A device should be issued a certificate only after it is identified, approved, and linked to an asset record. That certificate then needs monitoring for renewal, revocation, and rotation. Without that operational layer, certificate-based trust becomes static, even though device fleets are constantly changing.
The practical control set usually includes:
- strong issuance approval tied to device provenance and ownership
- short-lived certificates or frequent renewal where operationally feasible
- automated revocation when a device is retired, compromised, or reimaged
- certificate and key inventory that is reconciled against asset inventory
- logging that connects certificate use to device, application, and network events
Security teams also need to decide how much trust PKI should carry on its own. For some environments, mutual TLS and device certificates are enough for transport authentication, but not enough for authorization decisions. Policy still needs to account for posture, location, firmware state, and whether the device is still in an approved configuration. Current guidance suggests that this becomes much more robust when PKI is paired with zero trust principles and continuous device validation, as reflected in NIST SP 800-63 and the operational expectations of the EU Cyber Resilience Act.
Where teams often go wrong is assuming that certificate tooling is equivalent to trust governance. A certificate manager can renew secrets reliably, but it cannot on its own tell you whether the device should still exist, still be privileged, or still be allowed to communicate. These controls tend to break down when device ownership is decentralized and asset records are not updated after redeployment or retirement, because the PKI state and the real-world device state diverge.
Common Variations and Edge Cases
Tighter certificate governance often increases operational overhead, requiring organisations to balance stronger trust guarantees against device uptime and support constraints. That tradeoff is especially visible in constrained, offline, or safety-critical environments where frequent renewal is difficult and revocation checking may be unreliable. Best practice is evolving here, and there is no universal standard for how short device certificate lifetimes should be in every environment.
Edge cases matter. Offline industrial assets may need local trust anchors and delayed revocation propagation. Shared devices may need certificate re-issuance on every reassignment. In fleets that include legacy equipment, the best available control may be compensating monitoring rather than full certificate automation. For personal-data-heavy deployments, teams should also consider accountability and recovery obligations under the EU Cyber Resilience Act, especially where insecure update paths or weak lifecycle practices create downstream exposure.
The main exception is when certificate trust is intentionally narrow, such as for service-to-service authentication on a segmented network. Even then, revocation and inventory still matter, because a valid certificate on a retired device is still a valid credential. In connected-device environments, PKI is strongest when treated as evidence of identity that must be continuously checked, not as a permanent passport.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the technical controls, while NIS2 and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Connected-device PKI is part of identity-aware access control and asset trust. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification beyond initial certificate issuance. | |
| NIST SP 800-63 | IAL2 | Identity proofing principles help anchor device enrollment and lifecycle trust. |
| NIS2 | Lifecycle governance and security measures support resilience obligations for connected devices. | |
| EU Cyber Resilience Act | The Cyber Resilience Act raises expectations for secure lifecycle practices in connected products. |
Document device trust controls and ensure renewal, revocation, and inventory are operationally covered.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
