From best practice to legal requirement
The CRA is the EU’s first horizontal cybersecurity law — meaning it doesn’t target one industry, like medical devices or cars, but applies broadly to hardware and software "products with digital elements" placed on the EU market, regardless of where the manufacturer is based. Before it, a smart thermostat, a database engine, and a container runtime could each be subject to wildly different rules, or none at all. The CRA imposes one baseline: manufacturers must build products securely, know what’s inside them, watch for vulnerabilities, and tell someone when something goes seriously wrong.
The regulation entered into force on 10 December 2024. Its provisions phase in rather than landing all at once: bodies that will perform conformity assessments must be designated by 11 June 2026, mandatory vulnerability and incident reporting begins 11 September 2026, and the full set of obligations — including the essential security requirements and SBOM duties — applies from 11 December 2027. That reporting deadline is the one catching teams off guard, because it applies retroactively to products already on the market, not only to new releases.
What actually becomes mandatory
Two things used to be optional and now aren’t: knowing exactly what’s inside your product, and having a defined process for what happens when something breaks.
A software bill of materials (SBOM) — a structured list of a product’s components and dependencies — used to be a maturity signal, something advanced engineering teams did to manage supply-chain risk. Under the CRA, manufacturers must include a machine-readable SBOM covering at least the top-level dependencies in their technical documentation. It’s worth being precise about what this does not mean: the SBOM does not have to be published publicly. It has to exist, be kept current, and be handed to market surveillance authorities on request, retained for up to ten years.
Vulnerability handling follows the same pattern. A coordinated vulnerability disclosure policy — giving outside researchers a defined, safe channel to report flaws — moves from goodwill gesture to formal obligation. So does the practice of publicly disclosing fixed vulnerabilities with enough detail for users to judge their exposure, and of committing to a defined support period during which security updates arrive free of charge. A "support period" was once a marketing decision; now it’s a documented, legally meaningful date that has to be visible to buyers at the point of purchase.
None of these ideas are new inventions. What’s new is that they’re enforceable, and that failing to meet them can mean losing the right to sell into the EU market — through withdrawal, recall, or an outright ban — which for many businesses is a harder hit than any fine.
The compliance shape, at a glance
| Obligation area | What changes for teams | Key milestone |
|---|---|---|
| Secure-by-design defaults | Hardened, minimal configurations become a documented requirement, not a preference | Full application: 11 Dec 2027 |
| SBOM / component transparency | Machine-readable inventory required in technical file, given to authorities on request | Full application: 11 Dec 2027 |
| Vulnerability handling & disclosure | Formal CVD policy, timely patches, public advisories on fixed flaws | Full application: 11 Dec 2027 |
| Incident/vulnerability reporting | 24h early warning, 72h detailed notice, follow-up report to CSIRT/ENISA | Applies from 11 Sep 2026, retroactively |
| Conformity assessment & CE marking | Self-assessment or third-party review depending on product risk class | Assessment bodies designated by 11 Jun 2026 |
Reading this table left to right roughly tracks the order most teams will feel the pressure: reporting deadlines arrive first, in 2026, well before the documentation and design requirements become fully binding in 2027. That gap matters practically — you cannot realistically meet a 24-hour vulnerability reporting clock if you don’t already know which components are in your product, even though the SBOM requirement itself isn’t legally due until later.
Not the same rulebook as NIS2 — or GDPR
It’s easy to lump the CRA in with the EU’s other recent cybersecurity legislation, especially NIS2, but they answer different questions. NIS2 is about the security of organizations — hospitals, energy operators, digital infrastructure providers — and how well they manage risk to their own operations. The CRA is about the security of the product itself, wherever it ends up. A hospital’s IT department falls under NIS2; the medical device or software it buys falls under the CRA.
The line gets genuinely blurry for cloud-connected products, and this is one of the more contested areas of the regulation. Software-as-a-service is, in principle, meant to sit under NIS2 rather than the CRA. But when a product depends on a remote component the manufacturer controls — say, a backend service without which the local app loses core functionality — regulators have floated a three-part test to decide whether that remote piece counts as part of the "product" for CRA purposes. Where personal data is involved anywhere in that chain, GDPR applies on top, not instead — someone still has to work out who’s the data controller and on what legal basis. The overlap looks something like this:
flowchart LR A[Product with digital elements] -->|security of the product| B[CRA] C[Organization operating it] -->|security of operations| D[NIS2] E[Personal data processed] -->|lawful handling| F[GDPR] B -.overlaps with cloud-linked products.-> D
The upshot: a company can be in scope of all three at once, none of them, or some blurred combination — there’s no single test that resolves every SaaS or hybrid product cleanly, and guidance on this is still evolving.
Who’s actually caught, and who isn’t
The CRA’s scope is broad but not infinite. It targets manufacturers, importers, and distributors placing products on the EU market commercially. Individual volunteer open-source maintainers working outside a commercial context are not "manufacturers" under the law. But organizations that systematically fund or support open-source projects intended for commercial use take on a lighter-touch "steward" role — mainly a cybersecurity policy, vulnerability reporting, and cooperation with authorities, without exposure to fines. Once an organization distributes open-source components through a paid or commercial channel — a managed service, a commercial registry — it typically becomes a full manufacturer with full obligations.
Fines exist, and they’re not trivial — up to €15 million or 2.5% of global turnover for the most serious failures — but they are not the central lever. The real consequence is market access: a non-compliant product can be pulled from EU shelves or registries regardless of whether a fine was ever issued.
The bottom line for product teams
The CRA doesn’t ask engineering teams to learn new security concepts. It asks them to prove, on demand, that they already know their components, harden their defaults, handle disclosures responsibly, and stand behind a defined support window. For teams that treated these as optional maturity markers, the deadline pressure is real — 2026 for reporting, 2027 for the rest — but the underlying work is familiar. What’s changed is who’s asking, and what happens if the answer is "we don’t know."
