Topic starter
24/06/2026 8:55 pm
TL;DR: The EU Cyber Resilience Act will require connected products to prove security across design, provisioning, updates, and vulnerability response, with non-compliance risking fines up to €15 million or 2.5% of global revenue, according to DigiCert. For identity teams, the real issue is whether device trust, lifecycle evidence, and audit records can survive production scale and long-lived deployments.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “The Partnerships Powering CRA Readiness Across IoT”.
By the numbers:
- Non-compliance risks fines up to €15 million or 2.5% of global revenue under the Cyber Resilience Act.
Key questions
Q: What breaks when connected devices are shipped without provable identity records?
A: When devices leave manufacture without a durable identity record, teams lose the ability to prove which unit received which firmware, credential, or support decision.
Q: When should organisations prioritise lifecycle evidence over one-time certification for IoT?
A: They should prioritise lifecycle evidence whenever devices will receive patches, remain in service for years, or rely on third-party components.
Q: How do security teams know if machine identity governance is actually working?
A: It is working when the team can identify every machine identity, name the owner, map the dependency, and show recent rotation or retirement actions.
Practitioner guidance
- Define device identity at manufacture Issue each connected product a verifiable identity before shipment so provisioning records, update history, and compliance evidence can be tied to a specific device instance.
- Bind update events to audit evidence Log firmware signing, distribution, installation, and rollback outcomes together so update assurance can be demonstrated later without reconstructing the chain from separate systems.
- Track support state as a lifecycle control Maintain a current record of patch support, vulnerability handling, and end-of-support dates for every device family so compliance status does not drift after launch.
Bottom line: CRA readiness is fundamentally about proving identity and security state across the full device lifecycle, not just at launch.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 5:48 am
CRA readiness is an identity governance problem before it is a product security problem. The regulation forces manufacturers to prove that a device can be trusted at manufacture, during updates, and at the end of support. That is lifecycle governance applied to connected products, with identity records as the evidence layer. Practitioners should treat device identity as a governance control, not a peripheral technical detail.
A question worth separating out:
Q: What is the difference between secure provisioning and lifecycle proof for connected devices?
A: Secure provisioning establishes trust at birth by issuing credentials and identity. Lifecycle proof shows that trust remained defensible through updates, support, vulnerability handling, and retirement. CRA requires both: a device that was securely enrolled but cannot prove its later state still fails the compliance test.
👉 Read our full editorial: CRA readiness for IoT depends on device identity and lifecycle proof