Today marks an important milestone in the Cyber Resilience Act (CRA).

From 11th September 2026, manufacturers of products with digital elements are subject to the CRA’s mandatory reporting obligations for actively exploited vulnerabilities and severe security incidents.

This is more than another compliance date in an increasingly crowded European cybersecurity calendar. It represents a significant shift in how manufacturers are expected to respond when vulnerabilities move from being a technical concern to an active security threat.

For manufacturers of connected and IoT products, that shift deserves particular attention.

From vulnerability management to vulnerability reporting

Under Article 14 of the CRA, a manufacturer that becomes aware of an actively exploited vulnerability in one of its products must notify both the relevant CSIRT designated as coordinator and ENISA through the CRA Single Reporting Platform (SRP).

The first notification must be made without undue delay and, in any event, within 24 hours of the manufacturer becoming aware of the actively exploited vulnerability.

That is followed by a more detailed vulnerability notification within 72 hours, covering information including the affected product, the general nature of the exploit and vulnerability, and corrective or mitigating measures.

A final report is then required no later than 14 days after a corrective or mitigating measure becomes available, including details such as the vulnerability’s severity and impact, information about malicious actors where available, and the security update or other corrective measures made available.

The important point is that these are not simply deadlines for a security team.

They create an organisational requirement to recognise, assess, escalate and communicate information quickly enough for a manufacturer to meet a statutory reporting clock.

The supply chain matters

For IoT manufacturers, this is particularly significant because the vulnerability may not originate in the manufacturer’s own code.

Modern connected products are assembled from hardware, firmware, operating systems, libraries, open-source components, third-party software and other dependencies. Understanding whether a newly disclosed vulnerability is actually exploitable in a particular product can therefore require information from across the product’s supply chain.

The CRA already places considerable emphasis on understanding those dependencies. Manufacturers are required to identify and document components contained in products with digital elements, including through Software Bills of Materials (SBoMs), while vulnerabilities in components must be addressed as part of the manufacturer’s vulnerability-handling processes.

That makes today’s reporting obligation an important test of something broader than regulatory readiness.

It’s a test of product visibility.

If a manufacturer learns that a vulnerability in a widely used component is being actively exploited, can it quickly establish:

– Which products contain the affected component?
– Which versions are affected?
– Where those products have been placed on the EU market?
– Whether the vulnerable component is actually exposed or exploitable in the manufacturer’s implementation?
– What mitigations or updates are available?
– Which customers or users may need to be informed?
– Who internally has the authority and information required to make the notification?

For many organisations, the difficult part will not be submitting the notification.

It will be assembling the information required to make a meaningful notification within 24 hours.

The Single Reporting Platform changes the process

The introduction of ENISA’s Single Reporting Platform is intended to simplify reporting by providing a common mechanism through which manufacturers can notify the relevant CSIRT and ENISA. The platform is operational from today, coinciding with the application of the CRA reporting requirements.

ENISA has now published detailed guidance on the information required at each stage of the reporting process. The SRP glossary sets out the individual fields, their meaning, expected format and whether they are required at the 24-hour, 72-hour or final-report stage.

This is an important development because it makes the reporting requirement much more tangible.

Organisations can no longer treat reporting as something that will be worked out when an incident occurs. The process, information flows and responsibilities need to exist beforehand.

What happens when the clock starts?

Perhaps the most important phrase in Article 14 is not “24 hours”.

It is “becomes aware”.

The reporting clock begins when the manufacturer becomes aware of the actively exploited vulnerability.

That means manufacturers should be thinking carefully about how intelligence enters the organisation and how it moves through the vulnerability-management process.

A report from a researcher, a supplier notification, intelligence from a national CSIRT, a vulnerability disclosed in a commonly used software component, or evidence of exploitation observed in the wild could all potentially become the trigger for a process that ultimately results in a regulatory notification.

The distinction between vulnerability disclosure and vulnerability exploitation therefore becomes increasingly important.

Not every vulnerability is an Article 14 notification.

But when a manufacturer becomes aware that a vulnerability contained in its product is being actively exploited, the response needs to move rapidly from assessment to action.

IoT makes this particularly challenging

This matters enormously for IoT.

IoT products often have long operational lifetimes, complex dependency chains and highly distributed deployments. A vulnerability affecting a component may have implications across multiple product generations, firmware versions and customer environments.

There may also be a substantial gap between the organisation that develops a component and the organisation responsible for the finished product.

This is where good product security foundations become critical.

Asset and component inventories, SBOMs, vulnerability disclosure processes, product security teams, established escalation paths and clear ownership of security decisions are no longer simply indicators of good practice.

They increasingly determine whether an organisation can respond effectively when the regulatory clock starts.

The CRA does not remove the technical complexity of vulnerability management.

It makes the consequences of that complexity more immediate.

Today is a starting point, not the finish line

It would be easy to view 11th September 2026 simply as another compliance deadline.

It’s more useful to see it as the beginning of a new phase in product cybersecurity.

The reporting requirement creates a direct connection between vulnerability intelligence, product engineering, incident response, regulatory compliance and supply-chain visibility.

And for manufacturers, that connection needs to work at speed.

The wider CRA requirements will not apply in full until December 2027. But today’s reporting obligations provide an early and very practical indication of the direction of travel – cybersecurity is increasingly becoming a lifecycle responsibility for manufacturers, rather than something addressed only at product launch or when a vulnerability becomes public.

For the IoT sector, that should be welcomed.

The objective should not be to create another administrative reporting exercise.

It should be to make sure that when a vulnerability is actively being exploited, manufacturers have the visibility, processes and technical capability to understand what is affected, act quickly and communicate effectively.

11th September 2026 is therefore more than a date in the CRA implementation timeline. It’s the day that the ability to respond to actively exploited vulnerabilities became a demonstrable operational requirement for manufacturers of products with digital elements.

The organisations that are best prepared will not simply be those that know how to complete the new reporting form.

They will be those that already have the underlying product, vulnerability and supply-chain information needed to complete it accurately – when the clock is running.

‘You’re not ready for the CRA’

Following the success of our ‘You’re not ready for the CRA’ event in July, the IoT Security Foundation is bringing the conversation back to London on Thursday 8th October for ‘You’re STILL not ready for the CRA’.

This follow-up event, hosted at the premises of Which?, will bring together experts and industry practitioners to look at what has changed, what organisations should be doing now, and where the biggest challenges still lie.

Expect practical insight, candid discussion and real-world perspectives on navigating the CRA – from understanding your obligations and preparing for compliance, to tackling cybersecurity requirements across product development, supply chains and the product lifecycle.

Whether you attended the July event or you’re coming to the conversation for the first time, this is an opportunity to get up to speed, ask the difficult questions, roll some grenades and find out what you should be doing NOW to prepare.

If you’re an OEM exporting to Europe, you’ll be subject to wide-ranging legislation as of Friday 11th September 2026.

The message from July hasn’t changed, the CRA is coming. You’re STILL not ready!

Click HERE to register (move fast, the last one sold out!).

Presentation slides from the first CRA event are available via our members’ platfom, go to Plenary> Docs & Files, watch 5 of the expert sessions on our YouTube channel.