What is the EU Cyber Resilience Act?#
The EU Cyber Resilience Act is Regulation (EU) 2024/2847 , the first horizontal EU law setting mandatory cybersecurity requirements for products with digital elements made available on the EU market.
A “product with digital elements” is almost any hardware or software that connects to a device or network.
I spent eight years selling enterprise application-security scanners. Now “CRA-ready” is appearing on those same datasheets.
So I read the regulation text and mapped each obligation to the AppSec tool category that produces evidence for it, plus the obligations no tool touches at all. No regulator, law firm, or single vendor publishes that map neutrally.
The goal is practical: you should leave knowing which CRA requirements are documentation you produce, which genuinely need tooling, and that no single product makes you compliant.
When does the CRA take effect? The three deadlines#
The EU Cyber Resilience Act has three compliance dates: it entered into force on 10 December 2024, reporting obligations apply from 11 September 2026, and full obligations apply from 11 December 2027.
The CRA is often described as a single 2027 deadline, but it is phased across these three dates, and the first one is the one most teams miss.
The regulation entered into force on 10 December 2024. That started the clock but imposed no immediate obligations on manufacturers.
Reporting obligations apply from 11 September 2026 (Article 14). From that date, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and national CSIRTs.
This reporting deadline reaches products already on the market, not just new ones. A team focused only on December 2027 is overlooking the obligation that lands first.
Full applicability follows on 11 December 2027, the end of a 36-month transition. From then, all essential requirements, conformity assessment, and CE marking apply to products placed on the EU market.
Two finer points sit around these dates. From 11 June 2026 the rules on notifying conformity assessment bodies apply, and products already on the market before 11 December 2027 are caught by the full requirements only if they are substantially modified after that date (Article 69).
Who does the CRA apply to, and is my SaaS in scope?#
The CRA binds three roles: manufacturers, importers, and distributors (Articles 13, 19, and 20). The manufacturer is the primary duty-bearer; importers and distributors verify that upstream duties were met.
Some products are carved out entirely. Article 2 excludes medical devices, in-vitro diagnostics, motor vehicles, certified civil-aviation equipment, and marine equipment, each of which carries its own cybersecurity regime.
Scope follows a risk basis. Most products self-assess, while “important” (Annex III) and “critical” (Annex IV) categories face stricter conformity assessment through a notified body or an EU certification scheme.
Here is the test most buyers actually need. If your product is not in the Annex III “important” or Annex IV “critical” lists, you are default-class and self-assess, which is the majority case. Password managers are an important Class I example; firewalls are Class II.
The question I hear most from SaaS teams is whether they are in scope at all. The CRA targets products, not services, so a pure cloud service is generally out of scope.
A pure SaaS offering is not unregulated, though. It falls under NIS2 , which governs the security of essential and important services rather than products placed on the market.
The edge is genuinely fuzzy. A downloadable agent, an installable client, or “remote data processing” integral to a product (Article 3(2)) can pull the offering back into scope.
A vendor will often tell you that you are out of scope. The integral-remote-processing edge is exactly where that answer is most often wrong, so confirm it against the regulation text rather than a vendor summary.
What the CRA requires: the essential obligations#
The essential requirements sit in Annex I. They split into how a product is built and how vulnerabilities are handled across its life.
On the build side, products must be secure by design and delivered with no known exploitable vulnerabilities and a secure-by-default configuration.
On the handling side, manufacturers must identify and document vulnerabilities and components, remediate them through free security updates, and run coordinated vulnerability disclosure.
Several obligations are concrete and ongoing:
- A machine-readable software bill of materials (SBOM) covering at least top-level dependencies (Annex I, Part II).
- A defined support period during which vulnerabilities are handled, set at a minimum of five years unless the product is expected to be in use for less time (Article 13(8)).
- Incident and vulnerability reporting through the ENISA single reporting platform (Articles 14 and 16): a 24-hour early warning, a 72-hour notification, and a final report (within 14 days of a fix for an exploited vulnerability, or a month for a severe incident).
- An EU declaration of conformity, technical documentation, and CE marking before the product is placed on the market (Articles 28, 31, and 30).
None of these is satisfied by buying a single product. Each is a requirement you meet and then have to evidence.
What does non-compliance cost?#
The CRA sets three penalty tiers, and Member States set the regime that applies them (Article 64).
- Up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, for breaching the essential requirements (Annex I) or the core manufacturer and reporting obligations (Articles 13 and 14).
- Up to EUR 10 million or 2% for breaching most other operator obligations.
- Up to EUR 5 million or 1% for supplying incorrect, incomplete, or misleading information to authorities.
Fines are not the only lever. A market surveillance authority can order a non-compliant product withdrawn or recalled (Article 54), and that reaches a product already on the market. This is the part of the CRA that belongs in a budget conversation, not a legal footnote.
Which AppSec tool category produces evidence for which CRA obligation?#
This is the neutral map I promised in the introduction. Each AppSec tool category produces evidence for specific CRA obligations, and none covers all of them.
The table below cross-walks each essential requirement to the tool category that produces the relevant evidence:
| CRA obligation | AppSec tool category | What it produces as evidence |
|---|---|---|
| Secure-by-design (no insecure patterns in first-party code) | SAST | Findings that flag vulnerable code before release |
| Components free of known exploitable vulnerabilities | SCA | A dependency inventory matched against known CVEs |
| No known exploitable vulnerabilities at runtime | DAST | Evidence the running product was tested for exploitable issues |
| Secure-by-default configuration (no hardcoded credentials) | Secret scanning | Detection of secrets committed to code or config |
| Machine-readable software bill of materials | SBOM tools | A CycloneDX or SPDX inventory of components |
| Vulnerability handling across the support period | SCA plus a disclosure process | Continuous monitoring of the components you ship |
| Aggregated evidence of vulnerability handling | ASPM | Findings and remediation timelines across the SDLC |
On the build side, the map points to code and dependency scanners: SAST for secure-by-design code, SCA for components free of known CVEs, DAST for a tested running product, and secret scanning for a secure-by-default configuration.
On the handling side, SBOM tooling produces the bill of materials, SCA plus a disclosure process covers vulnerability handling across the support period, and ASPM aggregates the evidence for the technical file.
One obligation has no tool-category home. Incident and vulnerability reporting to ENISA is a process, supported by ticketing and aggregation rather than satisfied by a scanner.
The map shows where a tool produces evidence. It does not show a product you buy to “become compliant.” Every cell is one input to a conformity assessment you run and document yourself.
What about tools built specifically for the CRA?#
The map above lists single-purpose scanners, each producing one slice of evidence. A separate category is now emerging: platforms built specifically around the CRA.
Instead of one obligation, these platforms try to orchestrate several. That typically means SBOM generation and retention, vulnerability tracking, and the ENISA reporting workflow that no scanner owns, with some also managing the technical documentation and the declaration of conformity.
The earlier caveat still holds. A platform does not make a product compliant; the conformity assessment and the self-declaration remain the manufacturer’s responsibility. What it changes is the process and documentation burden, by keeping the evidence in one place.
So I would evaluate a CRA platform on coverage, not on the label. Ask which obligations it actually evidences, whether it files the ENISA report or only prepares it, and how long it retains the SBOM.
What does a “CRA-ready” claim on a datasheet actually mean?#
“CRA compliant” and “CRA-ready” are already appearing on SAST, SCA, ASPM, and SBOM datasheets. The phrase is worth reading precisely rather than at face value.
From the vendor side, “CRA-ready” on a scanner datasheet describes what that scanner helps you evidence. It says nothing about whether your product clears conformity assessment. The two get conflated because the badge is doing marketing work, not legal work.
Most products with digital elements are self-assessed under the CRA. So a compliance claim on a datasheet is usually a self-declaration of conformity, not a certificate issued by an independent body.
That is not a red flag in itself. Self-assessment is exactly what the regulation allows for default-class products, and most vendors are using the term accurately.
The distinction matters for the higher-risk classes. “Important” products may need a notified body unless harmonised standards are applied, while “critical” products require third-party assessment or a recognised EU certification scheme. A self-declaration alone is not enough there.
The useful question is therefore narrow. Ask which conformity route a claim refers to, and whether it covers the specific product you are buying.
What standards does the CRA use, and is EN 18031 one of them?#
Applying a harmonised standard whose reference is published in the Official Journal gives a “presumption of conformity” with the matching essential requirements (Article 27). That is the cheapest route to demonstrate conformity, so standards matter to a buyer, not only to a lab.
Here is the part vendors gloss over: the CRA’s own harmonised standards do not exist yet. They are being written under standardisation request M/606 , accepted by CEN, CENELEC, and ETSI in April 2025, with delivery deadlines running into 2026 and 2027.
So a “tested to EN 18031” claim deserves a closer look. EN 18031 and EN 303 645 are cybersecurity standards under the Radio Equipment Directive (Delegated Regulation (EU) 2022/30 ), not the CRA, and EN 18031 was listed in the Official Journal with restrictions.
That does not make them irrelevant. A radio product already tested to EN 18031 has a head start, and CEN-CENELEC treats the series as a foundation for the coming CRA standards. The honest reading is that this is preparation, not CRA conformity, until the CRA’s own standards land.
Which CRA obligations are process and documentation, not tooling?#
Several CRA obligations need no purchase at all. Separating that work from the tool-assisted work keeps a budget honest.
Threat-model evidence for secure-by-design is documentation you produce, not a scanner output. The same is true of the disclosure policy, the technical file, and the EU declaration of conformity.
Where tooling genuinely helps is the recurring, machine-scale work: finding known vulnerabilities, inventorying components, and monitoring them over the support period. That maps to shift-left practices and your DevSecOps pipeline .
What kind of SBOM does the CRA actually require?#
The CRA requires a software bill of materials in a commonly used, machine-readable format, covering at least the top-level dependencies (Annex I, Part II). See what an SBOM is for the underlying concept.
Two details get overstated. The depth requirement is top-level dependencies, not a full transitive tree, and the SBOM does not have to be published publicly.
It belongs in the technical documentation and is provided to authorities on request. That is a narrower obligation than “publish your full dependency graph,” which some summaries imply.
Security and procurement teams often disagree on whether a source-generated SBOM or a binary-analyzed SBOM is the stronger evidence. Each is sufficient in different cases: source SBOMs capture declared dependencies, while binary SBOMs capture what actually shipped.
The gap is not hypothetical. A 2025 audit of 25,882 Java SBOMs found that roughly a third failed to disclose even their direct dependencies, and about 5% of those omitted components carried known vulnerabilities (JBomAudit, NDSS 2025 ).
For how specific SBOM tools compare on format, depth, and retention, I keep that ranking in the SBOM tools comparison , including options like Anchore and FOSSA . This page stays on what the regulation needs, not which tool to pick.
Does the CRA apply to open source?#
The CRA draws a deliberate line around open source. Software developed or supplied outside a commercial activity is not covered.
Individual contributors and hobbyists generally fall outside the manufacturer obligations. Foundations and others that support a project on a sustained basis can fall under a lighter “open-source software steward” regime (Article 24), which carries no administrative fines (Article 64(10)).
The OpenSSF Cyber Resilience Act resources are where the open-source community works through what the steward role requires in practice.
The obligations attach when a company carries the software into a commercial activity, including integrating it into a product it places on the market. At that point the commercial actor, not the upstream volunteers, is the manufacturer.
So a commercial product built on open-source components carries CRA obligations for the whole stack it ships. The license and component dimension of that stack is worth tracking alongside vulnerabilities.
Where to start: sequencing the two deadlines#
The regulation’s phasing implies its own order of work. Two blocks, keyed to the dates already on this page.
By 11 September 2026, stand up the reporting path: decide who watches for actively exploited vulnerabilities, and who files the 24-hour and 72-hour reports to ENISA and your national CSIRT. This obligation reaches products you have already shipped.
By 11 December 2027, complete the build-side and documentation work: the SBOM, the secure-by-design evidence, the support-period commitment, the EU declaration of conformity, and CE marking.
Questions to confirm CRA readiness with a vendor#
If you are buying a product into the EU market, a short set of questions confirms where a vendor actually stands. None of these is a gotcha; they are the same documents an assessment relies on.
- Which conformity route does your CRA claim use, self-assessment, notified body, or an EU certification scheme? A credible answer names the route; a claim that just repeats “CRA-compliant” without naming one is not yet evidence.
- Can you share the EU declaration of conformity for the specific product version we are buying? If they produce it for the exact version, the claim is documented; if not, it is aspirational.
- What does your SBOM cover, in which format, and how long do you retain it? A precise answer names a format and a retention figure; a vague one usually means the SBOM is generated on demand, not maintained.
- What is the support-period end date, and the update cadence within it? A firm end date signals a real commitment; “for the foreseeable future” does not.
- Where do we report a vulnerability, and what is your disclosure process? A published policy and channel signal maturity; improvisation here is a flag for the whole program.
The answers tell you whether CRA readiness is documented or aspirational.
The bottom line#
No single tool makes a product CRA compliant. The map tells you which category produces evidence for each requirement; the rest, from the threat model to the technical file to the declaration of conformity, is documentation you own.
That is the read I could not get from a datasheet when I sat on the vendor side. When the next “CRA-ready” deck lands, the vendor questions above turn the claim into something you can check.
The CRA exists because shipped software carries inherited risk that buyers rarely see; the supply chain attack data is the backdrop it responds to. For how these requirements sit alongside SOC 2, PCI DSS, and ISO 27001, see the AppSec compliance map .