Manufacturers of connected products sold into the EU face their first hard deadline under the Cyber Resilience Act (CRA) today (11th September), as the regulation’s incident and vulnerability reporting obligations become enforceable.
More than a year before the CRA’s broader conformity requirements land in December 2027, manufacturers must now be ready to report actively exploited vulnerabilities and severe incidents affecting their products.
It’s a narrower obligation than the CRA’s headline ‘secure by design’ requirements, but industry voices are already warning it may be where the regulation bites hardest, and soonest.
What has to be reported, and how fast
Under Article 14 of the CRA, manufacturers of products with digital elements – a category that covers software as well as physical connected hardware – must notify the relevant authorities when they become aware of two specific triggers: a vulnerability in their product that is being actively exploited, or a severe incident affecting the product’s security. Routine bugs and disclosed-but-unexploited CVEs don’t count.
Once one of those triggers fires, the clock starts immediately, in three stages:
- Within 24 hours, manufacturers must file an early warning with ENISA and their national CSIRT
- Within 72 hours, a fuller notification is due, assessing the severity and impact of the issue and any mitigations available
- A final report follows – within 14 days of a fix becoming available for an actively exploited vulnerability, or within one month for a severe incident
Crucially, this obligation isn’t limited to new products. Even devices placed on the market years ago remain in scope for reporting, regardless of whether they’ll ever need to meet the CRA’s full conformity requirements. A product shipped in 2020 that’s no longer actively developed still needs a working 24-hour reporting capability if a vulnerability in it is exploited today.
A different kind of regulatory pressure
For companies used to compliance deadlines measured in months, the shift to an hours-based cascade is a significant operational change – and one several industry figures argue reflects a wider rethinking of how cybersecurity sits within the product lifecycle.
Maurice Kalinowski, Director of Product Management for Qt Framework at Qt Group, argues the CRA shouldn’t be read as simply adding friction to development. “By enshrining cybersecurity as a critical responsibility throughout a product’s entire lifecycle, it could save manufacturers countless hours down the line,” he says, pointing to the shift required once a product ships: rather than moving straight on to the next release, manufacturers now have to account for a product’s security years after launch. Done well, he argues, this can remove the “usual late-stage vulnerabilities of the last iteration” that tend to slow the next development cycle down.
Andrew Longhurst, Managing Director at Wittenstein High Integrity Systems, sees the burden shifting from simply building secure systems to proving it. “Developers must prove secure design, maintain active patching, and supply a clear Software Bill of Materials (SBOM),” he says. For sectors like automotive, aerospace, medical, and industrial automation, that’s already familiar territory. For everyone else – particularly teams building individual components without knowing their eventual end-use environment – it’s new. “This will impact developers both upstream and downstream and could prove a major hurdle for those wishing to continue selling into Europe,” Longhurst warns, adding that component and platform providers now have a responsibility to give developers secure by design architecture and compliance evidence “without forcing rigid architectures and closed ecosystems.”
The monitoring gap
Several experts point to a harder problem sitting underneath the reporting deadlines: knowing an exploited vulnerability exists at all.
Artem Serebrov, Director of Product at PCA Cyber Security, argues the new obligations are colliding with the practical limits of vulnerability monitoring. Manufacturers aren’t currently required to actively monitor how their products are being targeted by attackers, he notes, and most lack the capability to do so – dark web monitoring in particular, which is often the only way to track how a vulnerability is being discovered and exploited in criminal forums. Serebrov draws a pointed comparison to GDPR’s early years, when reporting obligations for data leakage arrived without any parallel obligation to actually measure data loss – an arrangement he says quietly encouraged some companies to limit how closely they monitored for breaches in the first place, simply to avoid triggering fines. Whether EU policymakers can avoid the same dynamic playing out under the CRA, he says, remains to be seen.
Iain Davidson, Head of Product Marketing at Wireless Logic, raises a related concern: the CRA’s reporting duty sits with the manufacturer, but in real-world IoT deployments, risk is often created somewhere else entirely. “Manufacturers can secure a device against its intended and reasonably foreseeable use but they cannot secure a deployment architecture they did not design or operate,” he says. In many IoT services, the organisation assembling devices, connectivity, Cloud platforms, and operational processes into a working system may have far more visibility of systemic risk than the equipment manufacturer itself. His conclusion: the CRA should be treated as a starting point, not a complete cybersecurity framework – one that needs to sit alongside NIS2 and IEC 62443 for organisations that want genuine long-term resilience. As reporting obligations bed in, he argues, companies need to be asking a harder question than “are we compliant” – namely, how they’d actually detect a breach across an entire connected system, not just a single product.
Heigor Freitas, Head of Region (UK and Europe) at CREST, frames the requirement as a necessary baseline rather than an end point. “Prioritising clear accountability, and setting a framework to prepare for it, can only be a good thing,” he says, adding that organisations already operating to high standards, with transparent reporting practices built into daily operations, are unlikely to be caught off guard. His broader point is that mature organisations don’t wait for regulation to catch up with them – they benchmark against recognised standards and seek independent assurance as a matter of course. He also flags a complication the CRA doesn’t yet fully address: AI. “Organisations deploying AI must evaluate additional risks and controls that go beyond current regulatory requirements,” he says. “They need to make certain that their AI deployments and security testing are backed by specialised standards which are independently verified.”
How prepared is industry, really?
Readiness data suggests the reporting deadline has caught a significant share of manufacturers with work still to do. ONEKEY’s IoT & OT Cybersecurity Report 2026, based on a survey of 200 German industrial companies, found that only one in five had set up a dedicated internal team to handle CRA requirements, with a further third assigning the work to some existing staff. Nearly one in five companies (19%) had assigned nobody to the task at all.
Responsibility for compliance is also spread thin across organisations. Half of companies surveyed have handed the task to IT security, while just over a quarter (26%) have placed it with product development, and 15% each with compliance and legal teams. At leadership level, product managers (31%) and cybersecurity analysts (26%) are most commonly holding the brief, ahead of compliance managers (23%), heads of software development (15%) and CISOs (13%). Only 27% of companies consider the CRA important enough to be handled directly by the board or executive management – a gap ONEKEY CEO Jan Wendenburg suggests is risky given the scale of potential penalties. Fines for breaching core CRA obligations can reach €15 million or 2.5% of global annual revenue, whichever is higher.
The same survey found more than 60% of companies expect development timelines for new or updated products to lengthen as a result of the CRA, with 28% expecting delays to be “significant.” Around a fifth remain unsure of the impact, and 17% don’t expect any change at all.
What comes next
Today’s deadline is a narrow but immediate one: it applies to reporting, not to the CRA’s full ‘secure by design’ conformity requirements, which follows on 11th December 2027. But with penalties attached and a live obligation that can be triggered by any exploited vulnerability in a product already on the market – however old – manufacturers without a working 24-hour reporting process now have a genuine compliance gap, not just a future one to plan for.
