How the screening works
CRA Readiness maps the answers you give against the text of Regulation (EU) 2024/2847 and the European Commission's non-binding draft scope guidance. It runs three determinations — scope, class and conformity route, and the reporting duty — and cites the article or guidance point behind each one.
1. Scope — is the product a "product with digital elements"?
The CRA applies to products with digital elements (PDEs) made available on the EU market — software or hardware whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Art. 2 and the definitions in Art. 3). We screen for that first: what you place on the market, and whether it can connect.
The SaaS / remote data processing (RDPS) boundary
Pure Software-as-a-Service is the most-contested edge, and the Commission's March 2026 draft guidance settled the working answer: standalone SaaS is out of scope of the CRA — a cloud service you access but install nothing for is not a "product with digital elements." The exception is a remote data processing solution (RDPS): cloud-side software that a separate product needs in order to perform its function is pulled into scope alongside that product (Art. 3 defines "remote data processing"). So the deciding question is not "is it in the cloud?" but "does a product on the market depend on this cloud component to work?" We ask exactly that and cite the guidance point behind the result.
The open-source commercial-activity test
Non-commercial open-source software is outside the CRA. The pivot is commercial activity (Art. 2 and recital wording on OSS): a project developed and supplied outside a commercial activity is out; monetise it, sell support or a paid tier, or integrate it into a commercial product and it — or the commercial product around it — comes into scope. The regulation also introduces a lighter-touch "open-source software steward" category for foundations and stewards that support OSS used in commercial products. We screen for whether any commercial activity attaches to the project, because that is what flips the result.
2. Class and conformity route
Once a product is in scope, its class sets how conformity is assessed. The CRA has three tiers:
- Default — the majority of products. Conformity by self-assessment (internal control), then a CE marking and an EU declaration of conformity.
- Important (Class I and Class II) — categories in Annex III (e.g. password managers, VPNs, network management, certain identity and security components). Class I can use harmonised standards to self-assess; Class II generally points toward third-party assessment.
- Critical — categories in Annex IV, which can be made subject to mandatory European cybersecurity certification.
We screen your product description against these categories to indicate the likely class and the conformity route it points to — self-assessment versus a notified body — flagging where the category boundary is fact-specific and warrants confirmation.
3. The reporting duty — the part that bites first
Full CRA compliance (the essential cybersecurity requirements, CE marking, technical documentation) applies from 11 December 2027. But the incident-reporting obligation applies earlier, from 11 September 2026 (Art. 14), and it is the duty most makers are unprepared for. It runs on a clock:
- 24 hours — an early-warning notification of an actively exploited vulnerability or a severe incident, from the moment you become aware.
- 72 hours — a fuller notification with the information known by then.
- 14 days — a final report after a corrective measure is available.
Notifications go to your designated CSIRT and to ENISA through the new Single Reporting Platform (SRP). Critically, under Art. 69(3) the reporting obligation reaches products already on the market — legacy software you shipped years before the CRA existed, if it is still made available or in use, carries the duty. That is why we treat reporting readiness as a September 2026 problem, not a 2027 one, and why the report ships with an adoptable 24/72/14 runbook.
What we cite
Two authorities sit behind every determination:
- Regulation (EU) 2024/2847 — the CRA itself, the binding legal text (articles, annexes, recitals).
- The European Commission's March 2026 draft guidance — non-binding, and explicitly capable of change, but the best available read on the contested edges (notably the SaaS/RDPS boundary and OSS). Where a position rests on the guidance rather than the article, the report says so, because a draft is a weaker footing than the regulation.
The full list, with links, is on the sources page.
Watch items — where this can move
Harmonised standards (expected Aug–Oct 2026). The technical standards that will define how to meet the essential requirements and self-assess are still being finalised. Until they publish, the "how" of default-class conformity is provisional. When they land, the conformity analysis firms up.
The Single Reporting Platform (SRP). The 24-hour clock depends on the reporting channel being live and usable by 11 September 2026. ENISA's SRP is the mechanism; its readiness and exact process are a live watch item, and the runbook is written to be updated when the platform's details are final.
Draft guidance is draft. The March 2026 scope guidance can be revised or superseded. A screening result that rests on it is only as current as the guidance; that is why every report is dated and the contested edges are flagged rather than stated as settled.
What this is not
This methodology produces a screening, not a conformity assessment and not legal advice. It does not evaluate your product's actual security, issue a CE marking, or replace a notified body or a lawyer. An out-of-scope result means out of scope of the CRA only — NIS2, GDPR, sector rules, and customer contracts may still apply, and no result should ever be read as "this product needs no security measures."