Most software sold in Europe will soon have to be secure, supported and documented by law. The EU Cyber Resilience Act (Regulation 2024/2847) entered into force on 10 December 2024, but the dates that change how vendors actually work arrive in stages through 2026 and 2027. If you sell software, firmware or connected hardware into the EU — or buy it from someone who does — the real deadline is closer than the calm reaction in your supply chain suggests.

What the Act actually covers

The CRA applies to "products with digital elements": software, firmware, connected hardware, and remote data processing solutions. That is broader than most people assume. It covers consumer apps and industrial firmware, but also libraries, container images, application servers and the components baked into other products.

Some categories are carved out because other EU rules already govern them, including medical devices, motor vehicles, aviation and certain defence uses. If your product falls into almost any other European market, assume you are in scope.

The obligations sit mainly on the manufacturer — the entity that places the product on the EU market under its own name — but they ripple down the supply chain. A small component supplier can find itself pulled into a customer's compliance file with contract terms, patch commitments and a bill of materials it never had to produce before.

The timeline that matters

• 10 December 2024: the Regulation entered into force. Planning and budgeting should already be underway.
• 11 June 2026: provisions on notified bodies and the conformity assessment infrastructure start to apply. The checking machinery comes alive.
• 11 September 2026: reporting duties begin. Manufacturers must report actively exploited vulnerabilities and severe security incidents.
• 11 December 2027: the bulk of the obligations apply to products placed on the EU market from that date.

Those reporting duties deserve a second look. A manufacturer that learns of an actively exploited vulnerability must send an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days. That is not a process you invent on the day it happens; it is a rotation, a template and a rehearsed escalation path.

One nuance trips up vendors: existing products already on the market are not automatically dragged into the new regime, but a substantial modification or a new version placed on the market can be. Ask a qualified lawyer where that line sits for your release cadence before you assume your upgrade cycle is exempt.

What vendors owe their customers

The core duties read like a sane secure development checklist that someone finally gave legal teeth. Products must be designed, developed and produced with adequate cybersecurity, shipped with a secure default configuration, and placed on the market without known exploitable vulnerabilities. Manufacturers must limit attack surfaces, protect confidentiality and integrity, and handle vulnerabilities properly once the product is out in the world.

In practice that means:

• A vulnerability handling process: intake, triage, remediation, coordinated disclosure, and advisories customers can actually find.
• A software bill of materials covering at least your top-level dependencies, maintained per release.
• Security updates for a support period you define, document and communicate to users.
• Technical documentation, an EU declaration of conformity, and CE marking where the rules require it. Download-only software has its own conventions for where that marking and declaration live.

Most products can be assessed by the manufacturer itself. "Important" products listed in the regulation, split into two classes, need more scrutiny, and critical products go further still, potentially requiring European cybersecurity certification. Non-EU manufacturers generally need an authorised representative established in the Union.

Breaches are not cheap. The highest tier of administrative fines is set at €15 million or 2.5% of total worldwide annual turnover, whichever is higher, with lower tiers for lesser failures.

What this means for small vendors and open source

There is no blanket exemption for startups, micro-enterprises or open-source projects, but the Act is not blind to them either. Smaller companies get some accommodations around documentation and record-keeping. Free and open-source software developed outside a commercial activity is largely outside the manufacturer duties. If you monetise it, you may be treated as an open-source steward with a lighter set of duties: a cybersecurity policy, vulnerability handling, and cooperation with market surveillance.

The practical risk for a small vendor is rarely the regulator. It is a larger customer that needs your SBOM and patch commitments to complete its own compliance file, and moves to a competitor that can supply them.

What buyers should demand now

Procurement is where the CRA becomes real. Get answers in writing before renewal, not after an incident:

1. Who is the manufacturer, and do they have an EU authorised representative?
2. Where is the EU declaration of conformity and CE marking for the exact version we run?
3. How long is the support period, and what ends it? Does it cover the lifetime of the asset it sits inside?
4. Will you provide an SBOM or component inventory for our version, and refresh it on updates?
5. What is your vulnerability disclosure policy, and what response times do you commit to?
6. Can you show the patch history for the last twelve months?

Then translate the answers into contract terms: security requirements, patch service levels, notification duties, end-of-support notice and a right to audit. A vendor that cannot answer these questions today has roughly until December 2027 to learn.

A workable plan before December 2027

Start with an inventory of everything you place on the EU market, then classify each product against the regulation's lists. Map who is responsible for what across your supply chain, including third-party components and any upstream open-source projects you depend on.

Next, fix the engineering basics so compliance falls out of your release process instead of a binder: SBOM generation in continuous integration, a monitored vulnerability intake address with an on-call rotation, machine-readable advisories, and a signed update path. Write the technical documentation as you go, not in a panic sprint in late 2027. Run a 24-hour reporting drill with your incident response team, and keep a log of your decisions.

This is general guidance, not legal advice. The classification of a specific product, the reach of the conformity assessment rules and the treatment of a major version release are questions worth putting to a qualified lawyer or compliance specialist.

The vendors that treat the CRA as an engineering deadline rather than a paperwork exercise will end up with something genuinely useful: customers who can see how the product is built and how it gets fixed.

Photo: Christian Wasserfallen / Pexels