Does the EU Cyber Resilience Act Apply to SaaS?
Pure SaaS is generally out of the EU Cyber Resilience Act - but remote data processing and buyer questionnaires can still pull you in. Scope test and Article 14 timeline.
An EU buyer drops Cyber Resilience Act or products with digital elements into a security questionnaire. You ship a browser SaaS. No desktop agent. No on-prem appliance. The instinctive reply - we are SaaS; CRA does not apply - is often directionally right. It is also incomplete, and incomplete answers stall deals the same way we are US-based stalls NIS2 reviews.
This post is for US (and other non-EU) SaaS founders, Heads of Product or Engineering, and lone compliance owners selling software into the EU who already know DORA and NIS2 from questionnaires and now see CRA language. The goal is a plain-English scope answer, the timeline that started on 11 September 2026, and a questionnaire reply that unblocks reviews without inventing fines for pure SaaS.
The direct answer
The CRA targets products with digital elements - hardware and software placed on the EU market - not software delivered purely as a service. Kirkland and Ellis (22 September 2026) summarizes the point clearly: pure SaaS offerings are generally excluded because those offerings are already covered under cyber reporting regimes such as NIS2 and DORA. The official CRA FAQ from the Open Regulatory Compliance Working Group restates the same boundary: standalone SaaS or other cloud solutions designed and developed outside the responsibility of a manufacturer of a product with digital elements are not themselves products with digital elements.
That is the comforting half. Do not stop there.
SaaS that qualifies as remote data processing essential to a covered product function can still be in scope. If you ship an on-prem agent, desktop app, embedded device, or hybrid stack whose cloud features are required for a product function - not just a nice-to-have add-on - the manufacturer-owned cloud piece can be pulled into the CRA product boundary. Hybrid, agent, and on-prem offerings need a product-specific legal review. Pure multi-tenant browser SaaS with no companion product is usually out; usually is not a free pass.
Even when you are out of manufacturer scope, EU buyers may still put CRA language on questionnaires. Answer the scope question; do not invent a CE-mark walkthrough you do not need.
The timeline that matters now
Two dates dominate CRA conversations in late 2026:
| Milestone | Date | What applies |
|---|---|---|
| Article 14 reporting | 11 September 2026 | Actively exploited vulnerabilities and severe incidents for in-scope products - including products already on the market |
| Remaining essential cybersecurity / conformity obligations | 11 December 2027 | Security-by-design requirements, vulnerability handling, technical documentation, conformity assessment, CE marking (for in-scope manufacturers) |
Kirkland (22 September 2026) frames Part I of CRA compliance around the September 2026 reporting deadline. Schutzwerk (9 September 2026), covering Commission guidance C(2026) 5252 published 27 July 2026, confirms the same split: reporting from 11 September 2026; remaining main obligations from 11 December 2027.
If you are a pure SaaS vendor with no covered product, these manufacturer deadlines are context for buyer conversations - not a personal CE-mark countdown. If you are a manufacturer of a product with digital elements (or own remote data processing that is part of one), Article 14 is already live.
The three-condition remote-data-processing test
Commission guidance, as summarized by Schutzwerk (paras. 178-202 of the guidance annex), treats a remote data processing solution as part of the product when all three conditions are met:
1. Data is processed at a distance.
2. Without that processing, the product could not perform one of its functions - not only its core function.
3. The software was designed and developed by the manufacturer, or under the manufacturer responsibility.
Practical examples from that same guidance pattern:
- Likely in the product boundary: manufacturer-owned onboarding/config cloud; manufacturer-operated OTA update service; manufacturer application running on third-party IaaS/PaaS if the software is theirs.
- Usually not remote data processing under this test: generic third-party storage the manufacturer did not design; a communication channel alone (cellular/Wi-Fi); a website that does not support product functionality (CRA FAQ Recital 12 framing).
Who operates the infrastructure is not the deciding factor. Who designed and owns the software, and whether the product can perform a function without it, is. A one-page remote-function map - per function: behavior without it, software ownership, data flow, third-party dependencies - is the practical decision record product teams should keep.
What reporting means if you are in scope
For in-scope manufacturers, Article 14 establishes a staged process via ENISA Single Reporting Platform (SRP), coordinated with the relevant national CSIRT:
| Stage | Actively exploited vulnerabilities | Severe incidents |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Within 24 hours of becoming aware |
| Notification | Within 72 hours | Within 72 hours |
| Final report | Within 14 days after a corrective or mitigating measure is available | Within one month after the incident notification |
Kirkland details the content expected at each stage. Schutzwerk and ENISA materials stress that becoming aware follows an initial assessment with a reasonable degree of certainty - a published CVE in a component SBOM does not automatically start the 24-hour clock until product-specific exploitation or a severe product-security incident is established.
Coordinate CRA filings with GDPR and NIS2 so one incident does not produce inconsistent narratives across regimes. A CRA notification does not automatically satisfy separate obligations under other laws.
CRA vs DORA vs NIS2 (same family, different object)
| CRA | NIS2 | DORA | |
|---|---|---|---|
| Object | Product cybersecurity for products with digital elements | Essential/important entities + supply-chain cybersecurity | EU financial ICT third-party resilience |
| Typical trigger for US SaaS | Shipping hardware/software products (or remote data processing tied to them) into the EU | EU buyer Article 21 supplier questionnaires | Financial-entity ICT questionnaires and contract clauses |
| Pure SaaS default | Generally out (unless remote data processing pulls cloud into a covered product) | Usually not directly regulated; felt via procurement | Usually not a financial entity; felt via ICT TPRM |
| Sibling reading | This post | NIS2 for US SaaS | DORA compliance |
Same extraterritorial-confusion family as Workstreet DORA and NIS2 posts, different regulatory object. Do not answer a CRA product-scope question with a NIS2 entity narrative, or the reverse. For another EU product/compliance pattern in AI, see EU AI Act compliance.
Questionnaire / GTM angle when you are not a CRA manufacturer
EU buyers may still ask CRA-related questions because their own product programs, legal templates, or GRC tools include the language. A clear scope memo unblocks reviews faster than a one-line not applicable:
1. Scope statement: We deliver software purely as a service. We are not placing a product with digital elements on the EU market as a CRA manufacturer. Our cloud offering is not remote data processing for a covered hardware/software product we manufacture.
2. What you do cover: Incident detection, disclosure, and customer notification under your existing security program (SOC 2 / ISO controls, status page, contractual notice language).
3. Evidence pack: current attestation, subprocessor list, vulnerability-management and incident-response excerpts - the same materials that clear security questionnaires generally.
4. Trust packaging: publish the scope memo and evidence where buyers already look; see building trust with a company trust page.
Do not invent fines for pure-SaaS readers. Kirkland reports CRA administrative fine tiers for in-scope manufacturers (for example, up to EUR 15 million or 2.5% of worldwide annual turnover for noncompliance with essential cybersecurity requirements and core manufacturer obligations including Articles 13 and 14). Those figures attach to manufacturers of products with digital elements - not to a pure SaaS vendor that is out of CRA manufacturer scope. Attribute penalty language only when discussing in-scope manufacturers, and treat classification as product-specific.
Flag for hybrid / agent / on-prem offerings
If any of the following are true, stop assuming SaaS = out and get a product-specific legal review:
- You ship a desktop app, browser extension, or local agent alongside the cloud console
- An on-prem or customer-hosted component is required for a product function
- Your cloud service exists primarily to make a hardware or installed-software product work (onboarding, config, OTA, licensing enforcement tied to function)
- You rebrand or substantially modify a third-party product placed on the EU market under your name
CRA classification is factual and product-specific. Commission guidance is a practical interpretation aid, not a substitute for legal advice.
Soft next step
If CRA, NIS2, or DORA language is showing up in late-stage EU deals and your team is rewriting scope answers from scratch each time, Workstreet can help package questionnaire responses, keep a Trust Center-ready evidence set current, and support managed compliance or vCISO ownership as EU deals scale - including security questionnaire automation. That is packaging and program help, not a claim that Workstreet issues a CRA conformity assessment or that every SaaS vendor is a regulated manufacturer.
