2026-08-24 · Compliance
The EU Cyber Resilience Act Starts Mattering on September 11. Here's What Actually Changes.
On September 11, 2026, the EU Cyber Resilience Act's reporting obligations become enforceable. Manufacturers of products with digital elements will have to report actively exploited vulnerabilities and severe security incidents to ENISA and their national CSIRT, on a clock that starts at 24 hours.
If you run a SaaS company, the question that actually matters is whether this applies to you at all. The honest answer: it depends on what you ship. Here's everything you need to know.
What September 11 actually is
The CRA entered into force in December 2024. It has two major dates that get conflated constantly.
September 11, 2026: mandatory vulnerability and incident reporting begins. This is the date everyone means when they say the CRA deadline is coming.
December 11, 2027: full application of the CRA, including CE marking and the complete set of essential cybersecurity requirements for products with digital elements.
September 11 is narrower than people think. It's specifically about reporting: if you're in scope and something goes wrong, you now have a legal clock, not a courtesy timeline.
The two things you'll have to report
Actively exploited vulnerabilities in your product: someone is using a flaw against you or your users right now, not a theoretical CVE.
Severe incidents that impact the security of your product.
The timeline for both, per the European Commission's reporting obligations:
- Early warning within 24 hours of becoming aware
- Fuller notification within 72 hours
- Final report within 14 days of a fix being available (vulnerabilities) or within a month (severe incidents)
Reporting goes through a single channel: the CRA Single Reporting Platform, routed to your national CSIRT and shared with ENISA. Miss it or get it wrong, and fines for reporting-obligation violations run up to €15 million or 2.5% of global annual turnover, whichever is higher. Authorities can also restrict sales or force a recall.
Does this actually apply to your SaaS company?
Most vendors skip this because the nuance doesn't sell urgency. It's the single most useful thing we can tell you.
You're generally out of scope if: your product is pure, browser-delivered SaaS. No install, no download, nothing that runs on a customer's device or infrastructure. That kind of service sits under NIS2, not the CRA. Notion in a browser tab, a CRM your team only ever opens in Chrome. This is the "out" case.
You're in scope if you ship any of the following, even alongside a browser-based core product:
- A desktop or mobile app
- A browser extension
- An SDK or library customers embed in their own code
- A CLI tool or downloadable utility
- An on-prem agent, connector, or gateway that talks to your cloud back end
- Firmware or anything running on a physical device
The gray zone, and where most of our audience lives: hybrid products where a local component only works because of your cloud back end, or where advanced features are gated behind something installed locally. If remote data processing is core to how the installed piece functions, that data processing is treated as part of the product. If you have any component like this, assume you're in scope until you've actually mapped it, not the other way around.
If you're not sure which bucket you're in, that's worth 30 minutes with someone who can look at your actual architecture, not a checkbox questionnaire. We're happy to be that resource even if the answer turns out to be "you're fine, this doesn't apply to you yet." That answer matters too.
Why the reporting clock is the real problem, not the paperwork
Say you are in scope. The obligation is procedural on paper: report within 24 hours, fuller detail at 72, final report on a fixed schedule. But a 24-hour clock is only survivable if you already know what "actively exploited" looks like in your own system.
Most teams don't find out about a vulnerability from their own monitoring. They find out from a customer, a security researcher, or an attacker who's already inside. At that point you're not just racing a 24-hour reporting window. You're doing incident triage, root-causing an unfamiliar part of your own codebase, and drafting a legally consequential report, all at once, for the first time, under pressure.
The teams that handle this well aren't the ones with the best incident response template. They're the ones who already know where their authorization gaps, tenant isolation issues, and exposed components are, because someone looked before an attacker did. That's the actual value of a pentest in a CRA world: not a compliance artifact to file away, but the difference between reporting something you found on your terms and reporting something you're finding out about in real time.
What to do before September 11
If you determined you're out of scope: good, but revisit this if you ever ship an installable component, an SDK, or an agent. Scope can change with a single product decision.
If you're in scope, or in the gray zone, get an assessment that actually covers the components that put you there. A pentest focused only on your web app won't tell you anything about the exposure created by your SDK or your on-prem connector. Scope the test to match what actually created the CRA obligation in the first place.
If you're not sure: that's a 20-minute conversation, not a project. We'll tell you plainly which side of the line you're on.
At Faultline Security, we run manual pentesting and AI red teaming for European B2B SaaS companies and startups: fixed price, scoped within 24 hours, most engagements complete in under two weeks. If you want a straight answer on where you stand before September 11, scope an assessment.