The EU Cyber Resilience Act: What IoT Device Makers Need to Do Before September 2026
Mandatory vulnerability reporting kicks in on 11 September 2026. That is four months away. Here is what the CRA actually requires from IoT manufacturers and what needs to be in place before the deadline.
Most manufacturers selling connected products into the EU know the Cyber Resilience Act exists. Fewer have grasped that it has two separate enforcement phases, and the first one is four months away. The December 2027 date – when full product compliance becomes mandatory – gets most of the attention. The September 2026 date gets considerably less, and it is the one that requires operational readiness right now.
If you make IoT devices, industrial sensors, cellular gateways, connected meters, or any other hardware with digital elements that connects to a device or network and is sold into the EU market, this is what you need to understand.
The two deadlines, plainly stated
Vulnerability reporting obligations begin. Manufacturers must report actively exploited vulnerabilities and severe security incidents to ENISA via the Single Reporting Platform. Applies to products already on the market.
Full CRA compliance required. All new products placed on the EU market must meet essential cybersecurity requirements, carry CE marking, and have completed conformity assessment.
The September 2026 deadline is the one most IoT manufacturers are underprepared for, because it applies retroactively. Products you shipped in 2022 are in scope for reporting obligations from September 2026. You do not get a pass because the product predates the regulation.
What the September 2026 reporting obligation actually means
From 11 September 2026, if you become aware of an actively exploited vulnerability in any of your products with digital elements sold into the EU, you are legally required to notify ENISA and your national CSIRT. The timeline is tight:
- Within 24 hours of becoming aware: submit an early warning to ENISA via the Single Reporting Platform (SRP)
- Within 72 hours of becoming aware: submit a full vulnerability notification
- Within 14 days of a corrective measure being available: submit a final report for actively exploited vulnerabilities
- Within one month of the incident: final report for severe security incidents
The catch: to report a vulnerability within 24 hours, you need to know whether your product is affected. To know that, you need a complete software bill of materials (SBOM) for every product in scope, plus a live vulnerability monitoring process that flags relevant CVEs against your component inventory. Without that infrastructure in place before September, you cannot comply with the reporting timeline even if you wanted to.
What is in scope
The CRA defines a “product with digital elements” as any hardware or software product that has data processing capability and can connect to a device or network directly or indirectly. For the IoT industry this is effectively everything: cellular routers, NB-IoT sensors, industrial gateways, smart meters, asset trackers, building management controllers, EV charging points, CCTV cameras, fleet telematics units. If it connects and it ships into the EU, it is in scope.
The regulation covers manufacturers, importers, and distributors – so UK manufacturers selling into the EU post-Brexit are fully subject to CRA requirements for the EU portion of their market.
Up to €15 million or 2.5% of global annual turnover for the most serious violations – whichever is higher. For failure to meet reporting obligations specifically, penalties of up to €10 million or 2% of global annual turnover apply. These are not per-incident caps; they reflect the scale of enforcement the regulation is designed to enable.
What needs to be in place before September
There are five operational requirements that need to exist before 11 September 2026 if you are to have any realistic chance of meeting the reporting obligations:
- SBOM for every in-scope product. A software bill of materials listing every component, library, framework, and dependency with version numbers. This is the foundation everything else depends on. Without it, you cannot determine whether a published CVE affects your product.
- Vulnerability monitoring process. A live process that tracks published CVEs against your SBOM inventory and flags relevant vulnerabilities without manual searching. At scale, this cannot be done manually within a 24-hour notification window.
- Vulnerability disclosure programme. A defined, accessible process for security researchers and users to report vulnerabilities to you. The CRA requires this. It also needs to be documented and operable before September.
- Incident classification procedure. An internal process for determining whether a vulnerability or incident meets the reporting threshold – “actively exploited” or “severe incident” – and routing it to whoever is responsible for filing the SRP notification. Timestamp the moment of awareness.
- ENISA SRP registration. The Single Reporting Platform will be operational from September 2026. Familiarise your team with the submission process before the deadline, not on the day a vulnerability is discovered.
The December 2027 obligations: what to design for now
Full CRA compliance from December 2027 adds product-level requirements that need to be designed in, not retrofitted. For new hardware entering development today, these are the commitments to build around:
Security by design. Cybersecurity must be integrated from initial product conception, not added at the end of a development cycle. This includes secure boot, encrypted communications, principle of least privilege, and minimal attack surface by default.
Security update obligations. Manufacturers must provide security updates throughout the product support period, which is generally expected to be at least five years unless the product’s intended use justifies less. For IoT devices with 10 to 15 year field lifecycles, this is a significant support commitment.
CE marking and conformity assessment. Around 90% of products can self-declare conformity. Products classified as “important” or “critical” – which includes critical infrastructure components and high-risk IoT devices – require third-party assessment by a notified body.
No default passwords. Products must ship without generic default credentials. Each device must have unique credentials or require the user to set them before first use. This alone will require firmware changes for a significant proportion of legacy product lines.
The eSIM angle
For IoT deployments using cellular connectivity, the CRA intersects directly with eSIM lifecycle management. Remote profile switching, over-the-air firmware updates, and the ability to change connectivity providers across a fleet are all relevant to both CRA compliance and long-term device security. The ability to push security-critical updates to a device remotely – without physical access – is one of the practical advantages that SGP.32 brings to long-lifecycle IoT deployments. The SGP.32 security model and the eSIM lifecycle from factory to field are worth reading alongside any CRA compliance planning for cellular IoT hardware. The current SGP.32 v1.2 specification is the standard underpinning commercial deployments in 2026.
The practical summary
September 2026 is not a product compliance deadline. It is an operational readiness deadline. You do not need CE marking by September. You do need an SBOM, a monitoring process, a vulnerability disclosure programme, and an incident reporting procedure. Those take months to build and validate, not days.
If none of that is in place yet, the window for comfortable preparation is closing. The SRP opens in September. ENISA’s 24-hour clock starts the moment you become aware of an actively exploited vulnerability – not the moment you finish investigating it.
SGP.32 eSIM Security – how the SGP.32 specification handles cryptographic authentication, profile integrity, and the trust chain from manufacturer to field deployment.
eSIM Lifecycle: Factory to Field – the full lifecycle of an eSIM-enabled IoT device, from eUICC manufacture through to end-of-life deprovisioning.
SGP.32 v1.2: The Current Specification Explained – where the IoT eSIM standard stands commercially in mid-2026 and what it means for new device designs.