Loading
Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
Vulnerability reporting obligations became mandatory September 11, 2026. What the CRA actually covers, its real timeline, and how it sits alongside NIS2 and GDPR.
As of September 11, 2026, manufacturers of software and connected hardware sold into the EU are now legally required to report actively exploited vulnerabilities and severe security incidents in their products — an early warning within 24 hours of becoming aware, a full notification within 72 hours. That obligation is part of the Cyber Resilience Act (CRA), the EU's first horizontal cybersecurity law covering products themselves rather than the organizations that operate them, and it's arriving in phases most companies selling into the EU haven't fully mapped yet.
The CRA applies to almost anything with digital elements sold in the EU — software, connected devices, firmware, and open-source projects distributed commercially — with a small number of exceptions (medical devices, cars, and a few other categories already covered by their own sector-specific rules). If your product has software in it and it's sold to an EU customer, it's very likely in scope, regardless of where your company is headquartered. That's the detail that catches organizations off guard: this isn't a rule about EU companies, it's a rule about products reaching EU users.
The CRA's obligations are phased, and two dates matter most right now:
The gap between those two dates is the part worth planning around now, not later: the reporting obligation requires you to already know when your own product has a vulnerability being actively exploited, which in practice means having a real vulnerability management and incident detection process in place well before you're forced to report through it for the first time.
The CRA's "secure-by-design" requirement isn't a new discipline to invent from scratch — it formalizes practices that mature security programs already treat as standard: dependency and component tracking (see our piece on container image scanning and supply chain security for the technical side of this), a documented vulnerability disclosure and patching process, and genuine security testing before release rather than only after. Our own Supply Chain Advisories archive — GitHub's own Security Advisories database, updated continuously — is exactly the kind of third-party component visibility the CRA expects manufacturers to actually have, not just claim to have.
For organizations already navigating NIS2 and GDPR, the CRA adds a third, product-focused layer rather than replacing either: NIS2 is about the security of the organizations operating critical infrastructure and essential services, GDPR is about personal data, and the CRA is about the security of the digital product itself, regardless of who's using it or what data it processes. A company can be fully NIS2-compliant as an operator and still have CRA exposure as a manufacturer if it sells software — these aren't mutually exclusive obligations, and for a lot of EMEA technology companies, all three now apply simultaneously.
If you haven't yet mapped which of your products fall in scope, the practical first step is a straightforward inventory: what you sell into the EU, what's in it (including third-party and open-source components), and whether you currently have a real process for the vulnerability reporting obligation that's already active. Our Security Consulting and Secure Code Review services cover exactly this — mapping actual regulatory exposure and testing whether the secure-by-design practices the CRA expects are genuinely in place, not just documented.
Tell us about your environment and goals — we'll help you scope the right engagement.