September 11 is coming up fast, and I've had the same conversation with four different founders this month: "does the Cyber Resilience Act apply to us?" Every one of them assumed yes. Two of them were wrong.
I run penetration testing and AI red teaming for SaaS companies at Faultline Security, so this is squarely in my lane, and I wanted to write the honest version of this instead of the vendor version, because the vendor version says "everyone is in scope" and that's just not accurate.
The CRA's reporting obligations become enforceable. If you're a manufacturer of a "product with digital elements," you now have to report actively exploited vulnerabilities and severe security incidents through a single platform, on a real clock: 24 hours for the early warning, 72 hours for a fuller notification, then a final report within 14 days (vulnerabilities) or a month (severe incidents). Fines for getting reporting wrong run up to €15M or 2.5% of global turnover.
This is not the CRA's full deadline. That's December 11, 2027, when CE marking and the rest of the essential requirements land. September 11 is narrower: it's specifically about reporting.
For SaaS specifically, the split is clean. Pure browser-delivered SaaS, no install, nothing running on a customer's machine or infrastructure, generally falls under NIS2, not the CRA. If your product only ever runs in a tab, you're probably fine for now. But the moment you ship anything installable, a desktop app, a mobile app, a browser extension, an SDK someone embeds in their own code, a CLI tool, an on-prem agent or connector, that component is a "product with digital elements" and you're in CRA territory. And if a cloud back end is essential to how that installed piece works, the remote processing counts too.
A lot of B2B SaaS companies live in the gray zone without realizing it: web app is the core product, but there's also a lightweight desktop client, or a monitoring agent customers install, or an SDK for their own integrations. That's exactly the setup that pulls you in.
The procedural part of this is honestly manageable: report within 24 hours, more detail at 72, final report on schedule. Any team can build a checklist for that.
The part that actually determines whether you survive it is whether you already know what "actively exploited" looks like in your own system before it happens. Most teams don't find vulnerabilities through their own monitoring first. They find out from a customer, a researcher, or an attacker who already got in. At that point you're triaging an incident in an unfamiliar part of your codebase and drafting a legally consequential report simultaneously, for the first time, under a deadline.
That's the whole argument for testing before you need to, not after. Not because a pentest report satisfies a regulator, but because knowing your gaps on your own timeline is a completely different experience than finding out live.
I've written up the full in-scope/out-of-scope breakdown here if you want the detail. But I'm more interested in what this community is actually doing about it. So:
Drop your answers below. I read everything, and I'll reply with what I'm seeing across the SaaS companies we work with if it's useful.