What the CRA is and who it covers
The Cyber Resilience Act is an EU regulation on the security of products with digital elements. The key word is product. The CRA doesn’t only apply to companies that sell “software” in the classic sense — it covers almost anything that has code and connects to a network or another device: apps, libraries, components, IoT devices, embedded software.
If you place a product with a digital element on the EU market — as a manufacturer, but in many cases also as an importer or distributor — the CRA applies to you. It also applies where your component ends up in someone else’s product: the final manufacturer is responsible for the whole thing, so they will require proof from you that your part meets the requirements.
It’s the same supply chain mechanics already visible with NIS2 and DORA. The regulation places the obligation on a large entity, which then pushes the requirements down onto its suppliers.
Two dates you need to know
The CRA comes into force in stages. Two dates matter operationally:
- 11 September 2026 — the obligation to report actively exploited vulnerabilities and serious incidents to CSIRTs and ENISA begins.
- 11 December 2027 — full application of the regulation: CE marking, technical documentation, meeting the essential cybersecurity requirements.
The first date is closer and easier to miss, because it isn’t tied to a visible product marking — it’s tied to a process. You need a working way to detect, assess and report vulnerabilities before this obligation starts.
Reporting a vulnerability within 24 hours
The most demanding element is the clock. After detecting an actively exploited vulnerability in a product, you have 24 hours for an early warning to the relevant CSIRT and ENISA, followed by further deadlines for a fuller notification and a final report.
24 hours is not time to call a meeting, work out who’s responsible and gather information by hand. It means the organization has to know in advance:
- who makes the decision to report,
- where it gets data on what’s in the product (which component versions, deployed where),
- how quickly it confirms whether a vulnerability is actually being exploited.
Companies that don’t have this sorted discover the gap only at the first serious event — that is, at the worst possible moment.
A deadline counted in hours changes the nature of the requirement. Compliance stops being a document you prepare once and becomes an operational capability you have to have wired into the process.
What the CRA requires of the product itself
Beyond reporting, the CRA imposes requirements on how a product is built and maintained. In short:
- the product should be designed and delivered without known, exploitable vulnerabilities,
- the manufacturer maintains vulnerability handling throughout the support period — accepting reports, releasing fixes,
- technical documentation and security information for the user are available,
- the manufacturer provides a mechanism for secure updates.
In practice, much of this is delivered not at the “compliance” stage just before placing the product on the market, but earlier — in the way the team writes, builds and ships code.
What it means for the delivery process
The CRA is a product regulation, but its requirements come straight down into the delivery pipeline. Three elements are worth having sorted regardless of the deadlines:
Knowledge of components. Without a current bill of materials (SBOM), you can’t answer within 24 hours the question “does our product contain the vulnerable component, and in which versions”. The SBOM stops being a good practice and becomes a condition for meeting the deadline.
Continuous vulnerability detection. Scanning dependencies and images on every code change, rather than once a quarter, shortens the time from a vulnerability appearing to it being detected.
A trail you can show. When the question “what was released, when and by whom” arises, the answer should follow from pipeline records, not the team’s memory.
These three things aren’t a separate “CRA project”. They’re elements of a mature delivery process that happen to answer the regulation’s requirements.
How to prepare before it becomes urgent
A sensible order:
- Determine whether you’re a manufacturer under the CRA — and for which products. That defines the scope.
- Build component visibility — an automatic SBOM for products placed on the market.
- Wire vulnerability detection into the build process — so response time doesn’t depend on who happens to notice an alert.
- Define the reporting path — who decides, where they report, within what time. Rehearse it before it’s needed for real.
The date 11 September 2026 concerns a process, not a marking — which is why it’s easy to miss and hard to make up at the last minute. Operational capability can’t be prepared in a day.
This article covers the technical layer of preparing for the CRA. Full compliance also requires organizational and legal work, and this text does not replace legal advice or a formal conformity assessment.