CRA readiness for IoT depends on device identity and lifecycle proof

At a glance

What this is: This is DigiCert's view of how the EU Cyber Resilience Act changes IoT readiness by making device identity, lifecycle security, and compliance evidence part of market access.

Why it matters: It matters because IAM, NHI, and lifecycle governance teams need to prove trusted device identity and auditability across the full product lifecycle, not just at provisioning.

By the numbers:

• The CRA introduces 22 Annex I obligations that cover the entire device lifecycle.
• Non-compliance risks market removal and fines up to €15 million or 2.5% of global revenue.

👉 Read DigiCert's analysis of CRA readiness for connected IoT devices

Context

The CRA turns connected-device security into a market access requirement, which means identity and lifecycle control now matter at manufacture, deployment, and long-term maintenance. For IoT and MedTech manufacturers, the question is no longer whether devices are secure in principle, but whether they can prove trusted identity, update integrity, and audit readiness throughout their service life.

That shift exposes a familiar governance gap. Many device programmes can show a secure start state, but they struggle to maintain evidence once devices are shipped, updated, integrated with cloud services, or supported by third parties. For teams responsible for machine identity and broader IAM governance, this is a lifecycle assurance problem as much as a compliance problem.

Key questions

Q: How should teams prove device identity across the full IoT lifecycle?

A: Teams should bind each device to a unique trusted identity at manufacture, then preserve that identity through enrollment, updates, support, and retirement. The key is continuity of evidence, not just initial issuance. If the organisation cannot trace certificate history, firmware lineage, and ownership changes for a specific device, it cannot reliably prove control across the lifecycle.

Q: Why do connected devices create harder compliance problems than standalone systems?

A: Connected devices create harder compliance problems because they persist, update, and interact with multiple services over long periods. That expands the number of control handoffs and makes proof harder to maintain. A device may pass initial checks but still fail governance if patching, support, or field validation are not tied back to the same identity record.

Q: What breaks when update trust is separated from device identity?

A: When update trust is separated from device identity, teams can no longer prove that a firmware package belongs to the exact product instance receiving it. That weakens vulnerability response, creates audit gaps, and increases the chance of unmanaged software drift. In practice, the organisation ends up trusting a device class rather than a governed device identity.

Q: Who should be accountable for CRA readiness in a connected device programme?

A: Accountability should sit with the team that can control the full lifecycle, but it must be shared across engineering, security, supply chain, and operations. CRA readiness fails when one group owns provisioning, another owns updates, and nobody owns evidence continuity. The governance model should make each handoff explicit and auditable.

Technical breakdown

Device identity at manufacture

CRA readiness begins before a device leaves the factory. Device identity means the product is provisioned with a trusted credential, certificate, or cryptographic anchor that can later authenticate updates, services, and compliance evidence. In IoT environments, this identity often has to survive manufacturing transfer, distribution, first boot, and field enrollment without becoming static or shared. If a device ships without a verifiable identity, downstream controls such as update validation and incident attribution become fragile because the organisation cannot reliably bind actions to a specific product instance.

Practical implication: establish manufacturing-time identity issuance and record linkage so each device can be traced from birth through retirement.

Lifecycle resilience and update trust

The CRA treats patching, vulnerability response, and long-term support as security obligations, not optional operations. That makes over-the-air update trust a core control surface, because the device must verify that firmware or software packages are authentic, untampered, and intended for that exact product line. SBOM validation adds another layer by tying updates to known component inventory, which helps teams understand exposure when dependencies change. Without this lifecycle linkage, security becomes episodic: the device may be trusted on day one but ungoverned during every later change.

Practical implication: bind update signing, SBOM validation, and vulnerability response into one governed release path instead of treating them as separate tasks.

Audit-ready compliance evidence

CRA is as much about proof as protection. Regulators can request compliance records at any stage, so manufacturers need evidence that spans design, provisioning, update history, and support decisions. This is where many IoT programmes break down, because telemetry, certificates, firmware lineage, and vendor responsibilities are often stored in different systems with no single lifecycle record. The result is an audit gap even when some controls exist. For identity governance teams, the challenge is not only whether the device is secure, but whether the organisation can demonstrate that security continuously and coherently.

Practical implication: build a lifecycle evidence chain that ties device identity, update events, and compliance records into one auditable history.

NHI Mgmt Group analysis

CRA readiness is a lifecycle identity problem, not a point-in-time compliance exercise. The article is right to frame security as part of market access, because the regulation assumes a device can carry a trustworthy identity and a durable evidence trail from manufacture through support. That assumption forces IAM and NHI teams to treat connected products as governed identities with lifecycle obligations, not as one-time deployments. The practitioner conclusion is that lifecycle proof becomes as important as secure configuration.

Device trust must be verifiable after shipment, not just at provisioning. A device identity that looks sound in manufacturing can still fail governance once it enters cloud-connected, partner-managed, or field-serviced environments. CRA exposes the gap between initial issuance and operational assurance, which is where many machine identity programmes lose control. The practitioner conclusion is that operational evidence has to follow the device wherever it moves.

Auditability is now a control objective, not a reporting by-product. CRA gives regulators the right to ask for records at any point, which means evidence collection must be designed into the lifecycle rather than reconstructed after the fact. That is a different governance standard from traditional compliance reporting, where documentation often trails operations. The practitioner conclusion is that teams need records that are born with the device and persist with it.

Partnership models will increasingly define whether CRA programmes scale. The article reflects a broader reality in IoT governance: no single team usually owns manufacture, update trust, field validation, and compliance evidence end to end. That creates a governance seam across engineering, supply chain, and security operations. The practitioner conclusion is that accountable handoffs matter as much as technical controls.

From our research:

• From our research: Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• The same research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a useful proxy for how quickly delegated access can outrun governance.
• For the next step, see NHI Lifecycle Management Guide for the governance model behind provisioning, rotation, offboarding, and evidence continuity.

What this signals

Device trust will be judged on evidence continuity, not only on secure design. CRA-style obligations push identity teams toward lifecycle records that survive manufacturing, field service, and long-term updates. With 1.5 out of 10 organisations highly confident in securing NHIs, according to The State of Non-Human Identity Security, the operating model gap is already visible in adjacent machine identity programmes.

The practical signal for security leaders is that connected-device governance will increasingly sit at the intersection of IAM, supply chain assurance, and product compliance. Teams that can join identity issuance, update integrity, and audit evidence into one trail will be better placed to absorb CRA pressure without turning every device review into a manual investigation.

Lifecycle assurance is becoming the decisive concept. It describes the ability to prove that a device remains the same governed identity from birth to retirement, even as firmware, ownership, and support responsibilities change. That concept will matter across IoT, MedTech, and industrial environments because regulators and customers will expect evidence, not assumptions.

For practitioners

• Map device identity from manufacture to retirement Create a lifecycle register that binds each connected product to its initial credential, certificate, firmware lineage, ownership, and retirement state so compliance evidence is continuous rather than recreated.
• Tie update trust to product identity Require signed update validation, SBOM checks, and vulnerability response records to resolve against the exact device model and instance before deployment approvals are granted.
• Unify compliance evidence across operational systems Link certificate records, provisioning logs, patch history, and support attestations into one audit trail so regulators can follow the full device lifecycle without manual reconciliation.
• Clarify ownership across manufacturer and partner boundaries Assign explicit responsibility for provisioning, field validation, update approval, and incident response so no lifecycle stage depends on an implied handoff between teams.

Key takeaways

• CRA turns connected-device security into a lifecycle governance requirement, which means identity, updates, and evidence must stay linked after deployment.
• The main risk is not only insecure devices but broken proof, where teams cannot demonstrate who provisioned, patched, supported, or retired a product instance.
• Practitioners should build an auditable chain that ties device identity, update trust, and compliance records together before CRA enforcement becomes the forcing function.

Key terms

• Device Identity: Device identity is the unique, verifiable cryptographic identity assigned to a connected product so it can authenticate itself to services, update channels, and auditors. In practice, it links a physical or logical device to a trusted record that survives manufacturing, deployment, and support changes.
• Lifecycle Evidence: Lifecycle evidence is the set of records that proves how a device was provisioned, updated, monitored, and retired. It combines technical telemetry with governance artefacts so a team can demonstrate control continuously instead of reconstructing compliance after an incident or regulatory request.
• Update Trust: Update trust is the assurance that a firmware or software update is authentic, intended for the right device, and safe to apply. It depends on signing, validation, and inventory linkage so patching does not become a blind spot in the device lifecycle.

Deepen your knowledge

NHI governance, machine identity security, and 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 governance maturity, it is worth exploring.

This post draws on content published by DigiCert: The Partnerships Powering CRA Readiness Across IoT Device Trust. Read the original.