What the EU Cyber Resilience Act requires | Konvu

The EU Cyber Resilience Act has two enforcement dates: Article 14 reporting from September 11, 2026, and full applicability from December 11, 2027. Most CRA programs plan only for the later one.

The two CRA deadlines that matter

The EU Cyber Resilience Act entered into force on December 10, 2024. Its essential cybersecurity requirements, conformity assessment, and CE marking apply from December 11, 2027. That is the date most CRA programs are planning around.

The reporting obligations under Article 14 apply earlier. They kick in on September 11, 2026, and they cover every product with digital elements already on the EU market, regardless of when it was placed there. There is no "we will get to it during the 2027 readiness program" grace period.

Date	What kicks in
Dec 10, 2024	CRA entered into force
Jun 11, 2026	Notification of conformity assessment bodies (Chapter IV)
Sep 11, 2026	Article 14: vulnerability and incident reporting
Dec 11, 2027	Full applicability (essential requirements, CE marking)

From September 11, 2026, a manufacturer that becomes aware of an actively exploited vulnerability has 24 hours to file an early warning, 72 hours for the full notification, and 14 days for the final report once a corrective measure is available. Reports go through the CRA Single Reporting Platform that ENISA is building, into the CSIRT of the manufacturer's main establishment, then to ENISA and other affected national CSIRTs. Miss the clock and the regulation allows fines up to €15 million or 2.5% of worldwide annual turnover.

If you own product security or compliance for a company shipping into the EU, this is the checklist that matters.

Are you in scope?

The CRA applies to "products with digital elements" placed on the EU market. The definition is broad: hardware, software, firmware, anything that connects to a network or processes digital data. SaaS-only offerings are largely covered separately under NIS2 and sit outside CRA, but anything you ship as a product, embed in a device, or distribute commercially is in.

A few specifics worth knowing before you scope:

Importers and distributors carry obligations too. If you sell EU-bound products built by a US parent, you inherit a slice of the manufacturer's duties.
Open source treatment is split. Maintainers of unpaid projects are largely out of scope. "Open-source software stewards" (legal entities providing sustained support) carry lighter obligations and no penalties. Commercial distributors of OSS are treated as manufacturers.
Microenterprises and small enterprises get partial relief. They can avoid fines for missing the 24-hour reporting clock, but the obligation itself still applies.
"Important products" in Class I and Class II face stricter conformity assessment paths. Operating systems, network management software, password managers, EDR tools, industrial controls.

Use the interactive CRA checklist

Track your readiness against 20 items across five governance themes: scoping, vulnerability handling, Article 14 reporting, SBOM, and conformity. Filter by deadline phase. Check items off and share progress with your team.

Open the CRA checklist →

Where the work usually breaks down

Most teams will fail their first Article 14 event. The process exists on paper. Nobody has stress-tested it against a 24-hour external deadline. Article 14 is an evidence problem dressed as a process problem, and three failure modes show up whenever a European security team walks through what it would actually take to file a report on the clock.

No single owner for the reporting clock. Intake works fine until the 24-hour clock starts, and compliance, security, and product each assume someone else has the pager. The first day burns before anyone files. One EU industrial we spoke to has the runbook drafted in three different documents owned by three different teams, with no agreement on which one is canonical.

Exploitability assessment is improvised. Article 14 asks whether a vulnerability is actively exploited in your product, in your customers' environments. Teams that triage by CVSS score or by scanner severity cannot answer that question in 24 hours. They need code-level evidence, configuration conditions, and observable signals. Most are guessing under deadline pressure with whatever the scanner gave them. That is exactly the gap we wrote about in the audit-readiness piece.

SBOM exists but is not reconciled. Plenty of teams generate an SBOM at build time and call the box ticked. Then a critical CVE drops on a transitive dependency, and nobody can quickly answer whether the affected version is in the shipped product and under what configuration. The SBOM is a document, not a control.

Where Konvu fits, and where it does not

CRA codifies what AppSec teams already know. Detection is solved. The gap is what you do with what you find.

Article 14 is about handling vulnerabilities once you have them: fast, with evidence, on a 24-hour clock.

That's where Konvu fits. We sit on top of your existing scanners (Snyk, Black Duck, Checkmarx, whichever stack you run) and reason about whether each finding is actually exploitable in your environment.

The "is this actively exploited" question becomes a defensible answer attached to the finding, with a code-level evidence trail, ready to drop into a CSIRT notification.

What Konvu doesn't do: generate SBOMs, run your conformity assessment, replace your scanners, or write your CVD policy. Those are different problems with their own tools and processes. If you're scoping CRA tooling end-to-end, our compliance solution page lays out where Konvu plugs into the rest of the stack.

If your team is starting to plan for September 2026 and the reporting workflow feels under-specified, happy to walk through how it works in a 30-minute session.

Penalties, scope edges, and notified bodies

Three CRA questions show up in almost every European buyer conversation.

Penalties. CRA non-compliance can trigger administrative fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of essential cybersecurity requirements or Article 14 reporting obligations. Lesser breaches (other obligations, supplying false information) cap at €10 million or 2% of turnover. Microenterprises and small enterprises get partial relief: they cannot be fined for missing the 24-hour reporting clock, although the obligation itself still applies. Open-source software stewards face no penalties at all.

CRA vs NIS2. The two regulations overlap and confuse buyers. CRA covers products placed on the EU market. NIS2 covers the operators running essential and important services. A software vendor selling into the EU likely falls under CRA. The bank running that software likely falls under NIS2. Some organizations sit under both, with different reporting paths. CRA reports go through ENISA's Single Reporting Platform to the manufacturer's national CSIRT. NIS2 incident reports go to the competent authority of the affected service.

When you need a notified body. Most products with digital elements default to self-assessment: the manufacturer issues a Declaration of Conformity, affixes CE marking, and maintains technical documentation. Important Class I products (operating systems, network management software, password managers) can self-assess if a harmonized standard is followed; otherwise a notified body is required. Important Class II products (firewalls, EDR, ICS) and Critical products generally require a notified body. Booking notified-body capacity for 2027 audits is already a real planning constraint. Treat it as a long-lead item.

FAQ

When does the CRA come into effect? The CRA entered into force on December 10, 2024. Article 14 reporting obligations apply from September 11, 2026. Essential cybersecurity requirements, conformity assessment, and CE marking obligations apply from December 11, 2027.

Who does the CRA apply to? Manufacturers, importers, and distributors of products with digital elements placed on the EU market. This covers hardware, software, firmware, and anything that connects to a network or processes digital data. SaaS-only services are generally covered separately under NIS2.

What are the penalties for CRA non-compliance? Up to €15 million or 2.5% of worldwide annual turnover for breaches of essential requirements and Article 14 reporting. Lesser breaches cap at €10 million or 2% of turnover. Microenterprises and small enterprises cannot be fined for missing the 24-hour reporting deadline, though the obligation still applies.

Is open source software covered by the CRA? Maintainers of unpaid open-source projects are largely out of scope. "Open-source software stewards" (legal entities providing sustained support) carry lighter obligations and no penalties. Commercial distributors of open-source components are treated as manufacturers.

What is the difference between CRA and NIS2? CRA regulates products (hardware and software placed on the EU market). NIS2 regulates operators of essential and important services. A software vendor likely falls under CRA. The organization running that software likely falls under NIS2. Some organizations sit under both, with separate reporting paths.