Where Annex I lives — and the five responsibilities OEMs must actively own
Many IoT OEMs already ship products with secure boot, encrypted communication, OTA updates, and access control. The EU Cyber Resilience Act (CRA) changes what those capabilities mean operationally.
Under CRA, cybersecurity becomes a long-term manufacturer responsibility tied directly to the CE mark. The OEM — not the silicon vendor, cloud provider, or contract manufacturer — becomes legally responsible for maintaining the product’s cybersecurity throughout its lifecycle.
After 11 September 2026, Article 14’s 24-hour reporting window becomes a legal obligation rather than an internal SLA. After 11 December 2027, products that do not meet Annex I requirements may no longer conform to CRA requirements for EU market access.
The EU Cyber Resilience Act places legal liability for product cybersecurity squarely on the manufacturer holding the CE mark. Top-tier breaches carry administrative fines up to €15M or 2.5% of global annual turnover for the preceding financial year, whichever is higher.
This article focuses on the engineering and operational view:
Many organizations still operate security-critical processes through manual or weakly governed workflows.
Typical examples include:
Before CRA, many of these were treated as internal operational weaknesses. Under CRA, they become manufacturer liability.
Article 14’s reporting obligations and Annex VII documentation requirements make traceability, ownership, and repeatable operational controls increasingly necessary at production scale.
CRA requirements generally fall into two categories:
The sections below explain what these requirements mean operationally for IoT OEMs.
The tables above show where Annex I requirements live. The sections below explain what they mean operationally — one capability largely decided during platform selection, and four ongoing operational responsibilities carried across the product lifecycle.
Hardware security is the foundation; software cannot retrofit capabilities the silicon platform does not support.
Before committing to an SoC or MCU family, OEMs should verify the following capabilities.
An isolated secure execution environment anchored by immutable boot ROM and hardware-validated TRNG.
Without it, integrity claims rely heavily on software assumptions that become difficult to defend.
Private keys, device identities, and OTA decryption keys stored inside protected hardware boundaries such as secure elements, TrustZone, or PUF-derived storage.
Software-only key protection on a general-purpose MCU becomes increasingly difficult to defend as attack value rises.
Hardware acceleration for AES, ECC (P-256/P-384), and SHA-256/384.
Software-only cryptography introduces meaningful latency and power overhead once TLS or per-message signing becomes part of the production data path.
Challenge-response debug authorization tied to immutable secure storage, plus rollback prevention mechanisms enforced during boot.
This prevents known-vulnerable firmware from being reinstalled after remediation.
For OEMs operating HSM-backed signing infrastructure, vendor tooling should support workflows where private keys never leave protected hardware boundaries across:
Keys and device certificates secure the product throughout its lifecycle. If a key leaks, the security model collapses regardless of how secure the silicon or firmware may be. Most IoT OEMs manage several classes of cryptographic assets across the product lifecycle.
Used to authenticate firmware images and OTA updates before execution.
Used to issue and manage device certificates across internal and external trust chains.
Used to protect update payloads during distribution.
Used to authorize controlled debug reopening for manufacturing, field service, and failure analysis. These assets are typically managed through four connected infrastructure components:
CRA does not explicitly require HSMs or approval workflows. However, Article 14 reporting obligations and Annex VII documentation requirements make traceability, ownership, and operational governance increasingly difficult without them.
Each key class should have:
Device-level traceability — knowing which firmware, keys, and certificates exist on each shipped unit — is not explicitly prescribed by CRA, but becomes the practical foundation for executing Article 14 reporting and Annex VII documentation obligations at production scale.
Once an actively exploited vulnerability becomes known, Article 14 reporting timelines begin immediately. OEMs must be able to identify:
Core operational capabilities typically include the following.
Per-build SBOM generation using machine-readable formats such as SPDX or CycloneDX, aggregated across product modules and retained historically.
Monitoring:
Silicon-level vulnerabilities frequently appear first through vendor PSIRT channels.
A public vulnerability reporting channel supported by an internal triage and response process.
Defined operational ownership for:
Submitting the 24-hour notification is only the beginning. Delivering remediation reliably to deployed devices is the larger operational responsibility — and for most connected IoT products, that means OTA.
CRA does not explicitly require OTA capability. But for most connected IoT products, in-field manual remediation is impractical at production scale. In practice, OTA becomes the operational mechanism for executing CRA obligations across the product lifecycle.
OTA systems typically become responsible for:
Many OTA systems were originally designed for feature rollout rather than compliance-driven remediation. Security remediation introduces additional operational requirements:
CRA documentation obligations extend far beyond product launch. EU market surveillance authorities may request the full conformity package up to ten years after the product was last placed on the EU market.
Typical Annex VII documentation includes:
For many OEMs, documentation retention becomes a long-term operational system rather than a release-time deliverable.
Maintaining traceable historical records across multiple product generations often becomes an organizational and infrastructure challenge rather than a firmware challenge alone.
Silicon vendors increasingly provide strong hardware security foundations through modern SoCs and reference designs. Most IoT OEMs already operate OTA infrastructure and release documentation processes.
For many teams, the largest operational gaps are:
CRA ultimately shifts cybersecurity from isolated product features into continuous operational responsibility across the entire product lifecycle.
