The short version

The CRA (EU 2024/2847) regulates products with digital elements placed on the EU market, whether hardware, software, or a combination. It makes cybersecurity a CE-marking matter, the same way machine safety or EMC is. When it becomes fully applicable in 2027 you cannot legally sell a vulnerable product into the EU.

Two dates to memorize:

11 September 2026 — vulnerability reporting under Article 14 starts. Actively exploited vulnerabilities and severe incidents must be reported to ENISA and the national CSIRT within 24 hours.
11 December 2027 — full applicability. All essential cybersecurity requirements, CE marking, documentation, SBOM, support period, the lot.

Penalties are not symbolic. Breaches of the essential cybersecurity requirements can attract up to EUR 15 million or 2.5 % of global annual turnover, whichever is higher.

Which products are in scope?

Anything with digital elements intended to connect to another system or network. In practice:

Consumer IoT (smart lamps, cameras, watches, toys)
Industrial IoT, sensors, PLCs, edge devices
Routers, switches, storage
Operating systems and firmware
Libraries, frameworks and developer tools distributed commercially
Software installed on-premise (office applications, ERP clients, vertical apps)

And several that often get missed:

Mobile apps distributed by a commercial developer
Security products (AV, EDR, firewalls — yes, ironically)
Cryptographic products

What is not in scope?

Pure SaaS services — covered by other regimes (NIS2, DORA, GDPR). But if the SaaS ships with a client or agent that's installed locally, the client is in scope.
Open source that isn't commercially distributed — if the project doesn't generate economic gain for the developer, it sits outside. "Open source stewards" get lighter obligations.
Products already regulated specifically by, say, medical device, automotive, or aviation rules.
Second-hand sales between individuals.

The timeline in detail

10 December 2024 — entry into force

The regulation became EU law. No obligations yet, but the clock started.

11 June 2026 — notified bodies start being designated

Notified Bodies that will perform third-party assessments for Class II and critical products must be in place before any meaningful certification can happen. Expect queues.

11 September 2026 — vulnerability reporting

This is the first date that affects daily operations:

24 hours after discovery: early warning to ENISA and the national CSIRT about an actively exploited vulnerability or a severe incident with security impact
72 hours: updated report with whatever detail is available
14 days (vulnerability) / 1 month (incident): final report with remediation, root cause, lessons learned

24 hours is a new reality. If your PSIRT isn't staffed out-of-hours, that's the first thing to fix.

11 December 2027 — full applicability

Everything else kicks in. Products placed on the market after this date must meet all essential requirements. Products already on the market must keep receiving security updates throughout their expected lifecycle, with at least five years as a floor.

Essential cybersecurity requirements (Annex I)

The CRA lists requirements on two levels.

Product properties:

Delivered with no known exploitable vulnerabilities
Secure-by-default configuration on deployment
Protection against unauthorized access (authentication, session management, access control)
Protection of data at rest and in transit (encryption where relevant)
Protection of integrity of code, configuration and data
Minimal attack surface (no unnecessary services, ports, interfaces)
Protection against DoS, or at least resilience
Logging of security-relevant events
Capability for secure updates, ideally automatic
Ability to delete personal data and configuration at end-of-life

Vulnerability handling:

Identify and document components via SBOM
Address vulnerabilities through security updates without delay
Recurring tests and reviews
Publish information about remediated vulnerabilities
Provide a coordinated vulnerability disclosure policy
Facilitate third-party reporting via, for example, security.txt

This is where penetration testing and continuous scanning enter the picture. The CRA does not say "run a pentest", but "recurring tests and reviews" is how you show you actually verify security rather than just claim it.

Which class is my product?

Three levels drive how strict the assessment is:

Default products — self-assessment is enough. Most software ends up here.
Important products, class I (Annex III) — self-assessment or a harmonized standard. Examples: password managers, antivirus, browsers, PKI components, identity management.
Important products, class II — third-party assessment required. Examples: firewalls, IDS/IPS, secure microprocessors, smart cards, HSMs.
Critical products (Annex IV) — full third-party assessment, possibly mandatory EU certification. Hardware Security Modules, smart-card devices, secure elements.

As a software vendor you will likely be Default or Class I. If you build network or security hardware, plan for Class II from day one.

SBOM, the first thing to fix

Software Bill of Materials is the topic at every CRA conference for a reason: without an SBOM you cannot meet several requirements at once.

In concrete terms you need:

An SBOM per released product version, ideally SPDX or CycloneDX
A pipeline that generates it at build time, not after the fact
A process to match components against CVE feeds (NVD, GHSA, OSV)
SBOM history preserved for as many years as your support period

Tools like syft, cyclonedx-cli and dependency-track cover the technical side. The hard part isn't generating the file — it's keeping the process alive over a decade.

What to do, month by month

We've seen enough NIS2 and DORA implementations to know how this plays out: half wait until six months before deadline and then ask for a panic budget. What we recommend is a calmer timeline.

Q2 2026 (where we are now — 3.5 months until vulnerability reporting)

Inventory the products you sell that might be in scope
Establish SBOM generation in CI/CD
Write a vulnerability disclosure policy and publish security.txt
Staff a PSIRT out-of-hours or buy it as a service
Map existing security work against the Annex I requirements, find the gaps

Q3 2026 (heading into the 11 September deadline)

Pilot the incident reporting flow — do a dry run against the ENISA template
Threat model per product line
Set up a field-update process (signing, validation, rollback)
Document the support period in customer contracts

Q4 2026 — H1 2027

Recurring external pentest, at least yearly
Continuous vulnerability scanning on network-exposed parts of the product
Run conformity assessment, internally or with a Notified Body depending on class
Technical documentation pack (Annex V): risk assessment, tests, design documents
CE-marking process including declaration of conformity

H2 2027

Final review, gap analysis
Move the entire product backlog onto CRA-compliance-as-hygiene

The vulnerability report ENISA wants

When an actively exploited vulnerability is found in your product, ENISA wants:

Early warning within 24 hours — product, version, indicators of exploitation, geographic spread, any action you've already taken
Follow-up report within 72 hours — technical nature, root-cause status, ETA on the security update, mitigations
Final report within 14 days — patch published, customer communications plan, lessons learned

The 24 / 72 / 14 triangle is something the team has to learn instinctively. Put templates in the runbooks before the first incident, not during.

How it relates to NIS2 and DORA

NIS2 regulates operators of essential and important services. The CRA regulates products. If you're a SaaS provider, you're primarily NIS2; if you ship IoT firmware, you're primarily CRA; if you sell financial IT, you're DORA. Plenty of organizations land under two or three.

The good news: the controls overlap heavily. SBOM, vulnerability disclosure, incident response, secure updates, continuous monitoring — all three regimes need them. Build once, map against three frameworks.

Where to go from here

If you ship software or hardware into the EU, the CRA isn't a wait-and-see risk. The timeline is fixed, the penalties are real, and Notified Body capacity will only get tighter as we approach 2027.

If you'd like help mapping your product portfolio against the CRA requirements, standing up an SBOM pipeline, or running the first pentest that lands in the technical documentation, get in touch. We do this for a handful of Swedish manufacturers already and can share what's worked.

And if your product is already on the market, start with the vulnerability disclosure policy. It's the cheapest thing you can do with the biggest risk reduction before September 2026.

See also in the glossary: CRA, NIS2, DORA, SBOM, PSIRT, VDP, security.txt, Coordinated disclosure, CVE, ENISA, CSIRT, Threat modeling.