TL;DR: The Cyber Resilience Act makes cybersecurity mandatory across the full product lifecycle for connected devices sold in the EU, with vulnerability reporting starting in 2026 and full enforcement in 2027, according to Keyfactor. For manufacturers, this turns device identity, cryptographic trust, and update governance into board-level compliance work, not post-release hardening.
NHIMG editorial — based on content published by Keyfactor: Not Business as Usual: What IoT Manufacturers Need to Know About the Cyber Resilience Act
Questions worth separating out
Q: What breaks when connected products rely on standing access instead of time-bound access?
A: Standing access creates a governance gap because administrators and service processes can keep reaching devices long after the original need has passed.
Q: Why do IoT products need cryptographic trust to satisfy EU cybersecurity rules?
A: EU cybersecurity rules increasingly expect manufacturers to prove device integrity, not merely claim it.
Q: What do security teams get wrong about device identity in regulated environments?
A: They often treat device identity as a one-time provisioning step rather than a lifecycle control.
Practitioner guidance
- Map CRA applicability across product lines Classify each SKU by whether it falls into General, Important, or Critical categories, then align security evidence to the highest applicable obligation set.
- Trace device identity from provisioning to retirement Document how identities are created, signed, renewed, revoked, and retired across manufacturing, deployment, support, and decommissioning.
- Replace persistent administrative access with time-bound controls Use expiring SSH access and similar temporary access patterns so service operations do not leave standing privilege in deployed products.
What's in the full article
Keyfactor's full blog covers the operational detail this post intentionally leaves for the source:
- A practical CRA compliance roadmap for IoT and embedded device manufacturers moving from policy to implementation
- Specific guidance on secure boot, certificate-based firmware signing, and supply chain-integrated identity
- The article’s walkthrough of post-quantum cryptography planning for long-lived connected devices
- Product-level considerations for time-bound SSH access and automated certificate renewal in regulated environments
👉 Read Keyfactor's guide to Cyber Resilience Act readiness for connected devices →
Cyber resilience act readiness: what IoT teams need to change?
Explore further
CRA readiness is a lifecycle identity problem, not just a product security checklist. The act of selling a connected device now depends on proving that identity, cryptography, and update trust are governed from manufacture to decommissioning. That makes lifecycle governance the operating model, not a supporting process. Practitioners should stop treating compliance as an add-on to engineering and start treating it as the condition for market access.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- That same study found 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.
A question worth separating out:
Q: Who is accountable when a connected product cannot be patched or retired securely?
A: Accountability sits with the manufacturer and the operating teams that own the product lifecycle, not only with the engineering group that built the first release. If patching, revocation, or retirement cannot be demonstrated, the organisation has a governance failure. Under the CRA, that failure can affect compliance status, market access, and liability.
👉 Read our full editorial: Cyber resilience act readiness is now a lifecycle identity problem