Why do IoT devices with certificates still face supply chain and network access risk?

Why certificates reduce identity risk but do not remove it

Certificates prove a device can present trusted credentials, but that only answers one part of the problem. If the certificate is issued to the wrong unit, injected insecurely, copied from a factory image, or never revoked after compromise, the device can still become a trusted entry point. Certificate trust is only as strong as the provisioning and lifecycle controls behind it.

That is why certificate-based device trust must be treated as a lifecycle control, not a one-time authentication event. Production compromise, cloning, spare-part reuse, and field replacement can all leave a valid certificate attached to hardware the organisation no longer controls. For the control to work, the issuing process, device ownership, and revocation process have to stay aligned from manufacture through retirement.

Where supply chain risk enters the device lifecycle

The supply chain risk is usually about injection, custody, and provenance. If a certificate, private key, bootstrap token, or provisioning artifact is created or handled in an untrusted part of the chain, the device may ship with a credential that an attacker already knows, can copy, or can reuse. That turns a trust mechanism into a pre-positioned access path.

Supply chain weaknesses also appear when suppliers, assemblers, or contract manufacturers can provision devices without strong separation of duties. A valid certificate can be technically sound and still be operationally dangerous if the credential material is exposed before the device ever reaches the customer. Standards and controls that emphasise build integrity and certificate issuance discipline are useful here, including SLSA for provenance and CA/Browser Forum for certificate issuance and revocation discipline.

In practice, the failure is not “the certificate was weak”, it is “the certificate was trusted outside the intended provenance boundary”. That distinction matters because a device can pass a basic identity check while still being a supply chain liability.

Why network access risk persists even when authentication succeeds

A certificate only authenticates the device or service, it does not decide where that device should be allowed to connect, what it should reach, or how much it should be able to do after admission. If network segmentation, device policy, and authorization are loose, a valid certificate can still open an overly broad path into production systems, update services, or sensitive management interfaces.

This is especially important for IoT fleets because the authenticating party is often an embedded device with limited user visibility and long service life. A stale trust relationship, such as an expired ownership record or an unrotated certificate still accepted by a backend, can let an attacker use a physically recovered device, a cloned image, or a stolen key to gain network access that should have been withdrawn. RFC 8705 shows how certificate-bound access can strengthen client authentication, but it still depends on backend policy, token binding, and revocation handling.

For broader identity and access governance, the same pattern appears in NIST SP 800-53 Rev. 5 control families for access control, identification and authentication, and system integrity, where admission is only one part of the control objective.

What actually has to be controlled for certificates to be effective

The practical answer is to control the whole chain: initial identity binding, secure key injection, fleet inventory, rotation, revocation, and decommissioning. If any one of those steps is missing, certificate trust becomes fragile because the device can remain technically authentic while being operationally unsafe.

That means the organisation should be able to answer three questions for every device: who provisioned it, which private key material it holds, and how quickly that trust can be withdrawn. When those answers are unclear, the network should treat the device as potentially trusted only in name. The operational benchmark is not whether the device has a certificate, but whether the certificate is tied to a known asset, a known owner, and a known revocation path.

For practitioners using a control catalogue, NIST SP 800-57 Key Management is a useful reference for certificate-adjacent key lifecycle discipline, especially where long-lived device credentials can outlast the business intent behind them.

Risk and Threat Considerations

Certificates can create a false sense of closure because they make devices look strongly authenticated even when the surrounding lifecycle is weak. The main risk is not failed authentication, but trusted access that should already have been withdrawn, narrowed, or never issued in the first place.

Failure mechanism: An attacker abuses weak provisioning, stolen hardware, copied private keys, or stale trust relationships to present a still-valid certificate and gain network access that the backend continues to accept.

Impact: The result can be unauthorized access to internal services, lateral movement from a device foothold, and persistent exposure that remains invisible until the certificate is revoked or the device is physically recovered.

Practitioner Guidance

What to verify: Confirm that each device certificate is bound to a unique asset record, a specific owner or manufacturer workflow, and a documented revocation path. If you cannot rapidly answer where the key was created, where it is stored, and how it is disabled, the trust model is incomplete.

Decision rule: If the device can authenticate but cannot be confidently inventoried, rotated, or revoked, treat it as a lifecycle control problem rather than a pure authentication success. In that case, prioritize revocation readiness and network containment before expanding deployment.

Practitioner takeaway: Certificates reduce impersonation risk only when the organisation controls identity binding, key custody, and withdrawal with the same rigor as issuance; otherwise the certificate becomes a durable access token for whatever hardware currently holds it.

Related resources from NHI Mgmt Group

• How should security teams reduce the risk of weak RSA certificates in IoT and network devices?
• Why do VPN and VDI still leave supply chain access risk in place?
• How should organisations implement supply chain cyber risk management across acquisition, assessment, and ongoing monitoring?
• What happens when federal agencies try to manage supply chain risk without a real-time monitoring capability?