ISJ hears exclusively from Sylvain Cortes, VP of Strategy, Hackuity about what the EU CRA means for manufacturers and why it represents a major shift in software liability.
September’s EU CRA vulnerability reporting deadline
From September 2026, manufacturers selling products with digital elements in the EU face new reporting obligations under the Cyber Resilience Act (CRA).
Actively exploited vulnerabilities must be reported to authorities within 24 hours, but most organisations struggle to confirm exposure across their systems and supply chains in days, let alone hours.
The CRA reporting deadline is six months away. What changes on September 11th?
The upcoming regulation is introducing several changes to how organisations manage vulnerabilities in their products.
Some companies will have this well in hand, but many will need to work fast to ensure they’re ready for the deadline.
Manufacturers placing products with digital elements on the EU market will need to notify Computer Security Incident Response Teams within 24 hours once they know a vulnerability in their product is being actively exploited.
This applies to anything with a direct or indirect network connection – routers, smart meters, industrial sensors and embedded software components.
There are three notification stages; early warning within 24 hours, detailed report within 72 hours and a final report within 14 days, including patches and remediation.
The 24-hour clock starts when you become aware someone has exploited a vulnerability without the system owner’s permission.
This comes into force before the broader CRA obligations in December 2027. It addresses vulnerabilities already being exploited, which is why it applies first.
Why is this such a significant shift?
This changes the accountability model for software security. Manufacturers are now liable for security through the entire product lifecycle, and the timelines demand continuous visibility rather than periodic assessments.
When a new CVE is reported, you need answers quickly.
Do we use this component?
Which versions are deployed where?
Can it be exploited in our configuration?
Are there mitigating controls?
Only after answering those questions can you determine whether it’s being actively exploited and whether it falls within scope of the reporting requirements.
If that investigation takes several days, you’ve already missed the deadline.
Our research found the average mean time to remediate critical vulnerabilities is 4.5 weeks – even organisations with full automation average 3.5 weeks.
And remediation comes after detection and triage. The CRA compresses this timeline dramatically for the subset of vulnerabilities being actively exploited.
Which manufacturers and products does this cover?
Any manufacturer placing products with digital elements on the EU market, regardless of where they’re based.
That includes hardware with embedded software, standalone software, and remote data processing components that support product functionality.
If your product connects to a device or network, even indirectly, it’s covered.
So it could be a hardware component that integrates into a larger system or a software library that gets compiled into other products.
There are exceptions for products already under sector-specific regulation like medical devices or aviation equipment.
Otherwise, the reporting obligation applies.
Where do traditional vulnerability management approaches struggle?
Visibility is the first problem. Vulnerability data lives in scattered systems. Scanners identify affected software versions, but organisations often lack accurate asset inventories or software bill of materials (SBOMs) to confirm where those components are deployed.
You might have threat intelligence feeds showing active exploits, patch management tracking remediation, and asset management platforms tracking infrastructure – but they don’t talk to each other in any meaningful way.
Then there’s scale. We’re dealing with hundreds of thousands of known vulnerabilities, with tens of thousands more disclosed every year.
Modern software exacerbates this because applications are built from complex ecosystems of components – open-source libraries and third-party packages sitting several layers deep in the stack.
Each element brings potential weaknesses.
This creates a huge amount of noise for security teams.
A team might patch dozens of vulnerabilities in a week, but miss the one being actively exploited.
The organisation remains at risk.
Supply chains complicate this further.
Digital products often depend on third-party libraries, embedded software and external vendors.
When you don’t control the entire stack, knowing where vulnerabilities surface gets harder.
Why can’t manual triage meet the 24-hour requirement?
Manual triage means someone has to do the detective work. They correlate vulnerability disclosures with asset inventories, check configuration details, assess whether mitigations are in place and determine whether the vulnerability is being exploited.
Each step introduces delay.
When you’re working across multiple scanning tools, spreadsheets tracking remediation status and fragmented visibility between cloud and on-premises environments, that detective work takes time.
You might need to contact different teams to confirm deployment details.
You might wait for scheduled scans to complete before you know whether a vulnerability is present.
The CRA doesn’t accommodate internal coordination challenges.
If you become aware of active exploitation, the 24-hour clock is running.
Our research found 46% of organisations already report strain on security team resources from rising vulnerability volumes.
Adding a hard reporting deadline on top of that creates genuine compliance risk.
What does continuous monitoring require?
You need visibility into your attack surface at all times.
When a new vulnerability is disclosed, you should be able to immediately query your environment and determine exposure.
That means integrating vulnerability data with asset management, configuration management and runtime information.
You also need mechanisms to detect exploitation. Intrusion detection, endpoint detection and response, application security monitoring – something that provides the evidence the CRA requires.
The regulation defines actively exploited vulnerabilities as those where you have reliable evidence of malicious exploitation. You need telemetry that can prove it.
For many organisations, this is a big change. It requires tooling that provides real-time visibility rather than periodic snapshots, automation to correlate vulnerability intelligence with asset data and integration across security tools to give you the complete picture needed for notification decisions under time pressure.
What should manufacturers do now?
Start with inventory.
You need complete visibility into what products you’re placing on the EU market and what components they contain – third-party libraries, open-source dependencies and remote data processing elements as a starting point.
If you can’t enumerate your products and components, you can’t determine whether a vulnerability applies.
Then look at your current timelines.
When a new vulnerability is disclosed, how long does it take to confirm whether you’re affected? To assess exploitability? To gather evidence of active exploitation? If those timelines exceed 24 hours, you have a process problem to fix before September.
Think about how you can centralise vulnerability intelligence, asset data and threat intelligence for rapid decisions.
Fragmented tools and manual correlation won’t work. You need platforms that can answer exposure questions in real time.
And work out escalation paths and decision-making authority for notifications now.
With 24 hours to report, you can’t afford organisational friction or unclear ownership.
Someone needs authority to make the notification decision based on available evidence, even when assessment is incomplete.
