CRA compliance: What it means for a software product's life cycle

The clock is running toward December 2027, and a lot of companies still can't say whether the CRA's rules apply to them. The problem is not understanding the core requirement: the law makes whoever builds a product responsible for keeping it secure for years after it ships, but it never says what happens if that company disappears.

This guide walks through what the CRA covers, who it touches, what it costs to get wrong, and the part of it almost nobody is planning for.

What the Cyber Resilience Act is, and why it exists

The Cyber Resilience Act, or CRA, is the EU law (Regulation (EU) 2024/2847) that sets mandatory cybersecurity requirements for any product with digital elements sold in the EU. It covers hardware and software across the whole product life, from design through the years after release.

Before the CRA, no single party was clearly accountable for the security of a software product once it reached the market. A flaw could sit unpatched for years and no law said whose job it was to fix it. The CRA closes that gap by putting the responsibility on the people who make and sell the product.

It helps to place the CRA next to two laws you've probably already met. GDPR governs personal data. NIS2 governs the organizations that run essential services. The CRA is different from both: it regulates the products themselves, and it follows them across their entire life rather than stopping at the sale. 

Who has to comply

The CRA splits responsibility across three roles, and the weight is not shared evenly:

• Manufacturers carry the bulk of it. They design the product and own its security obligations for the whole supported life.

• Importers have to check that a product met the rules before they bring it into the EU.

• Distributors have to verify it carries the right marking and documentation before they pass it on.

Two points get missed in most write-ups. First, the CRA reaches beyond Europe: any company placing a product on the EU market has to comply, wherever it's based. Second, it applies to software even when the product never touches the internet.

There's a lighter touch for open-source software, where a new "open-source steward" role carries reduced duties. But if you only buy CRA-regulated products rather than build them, don't assume the law passes you by. The obligations your suppliers take on become part of the risk you depend on, which is a thread we'll pick up later.

Product tiers: Default, Important, and Critical

Knowing the CRA applies to you is only the start. Before you can meet its requirements, you have to work out which version of them you're held to, because the law sorts products into risk tiers and each tier carries a different path to approval.

Getting this classification right is the first real decision a compliance program makes, because it sets the testing, documentation, and certification work for years ahead. The technical descriptions that tell you where your product lands sit in a separate 2025 implementing regulation.

The core compliance requirements

Once you know your tier, the substance of cyber resilience act compliance comes down to a set of duties that run from the drawing board to the end of the support period. Here is what the law asks for:

1. Secure by design. Build security in from the start and ship with secure default settings, so a product isn't left exposed by how it arrives out of the box.

2. No known exploitable holes at launch. A product can't go on the market carrying vulnerabilities the maker already knows attackers can use.

3. Ongoing vulnerability handling. Once it's out there, the manufacturer has to find, fix, and disclose vulnerabilities for as long as the product is supported.

4. A software bill of materials (SBOM). Makers keep a machine-readable list of at least the top-level components inside a product, so they know what they're shipping. It doesn't have to be made public. See how SBOM duties line up across CRA, NIS2, and DORA.

5. Free security updates across the support period. Updates stay free for a defined support period, at least five years from launch unless the product's working life is plainly shorter (Article 13(8)).

6. Reporting to the authorities. Actively exploited vulnerabilities and severe incidents go to ENISA and national response teams through a single platform, on a tight clock.

7. Documentation, conformity assessment, and CE marking. Before a product goes on sale, its maker proves it meets the rules (the conformity assessment), records the evidence, and adds the CE mark, the badge that says it's cleared for the EU market.

None of these is a one-time task you clear and forget. They are commitments that have to hold for years, which is exactly where the timing starts to matter.

The deadlines that matter

The CRA's obligations deadlines are staggered to phase in across three years, and treating December 2027 as the only date to plan around is how teams end up scrambling.

1. December 10, 2024. The CRA enters into force. The clock starts, but nothing is enforced yet. 

2. September 11, 2026. Reporting obligations apply, so your processes for reporting exploited vulnerabilities and severe incidents to the authorities must be live and working.

3. December 11, 2027. Everything else applies, including conformity assessment and CE marking, before a product can be sold.

The date that catches people out is September 2026, not 2027. You don't get until the headline deadline to set up incident reporting, because that duty lands more than a year earlier, and it needs real processes behind it rather than a plan to build them later. (European Commission)

What non-compliance costs

With the dates set, the obvious question is what happens if you miss them. The CRA backs its requirements with fines on the GDPR scale, sorted into three bands.

The fines tend to grab the headlines, but for many companies the sharper consequence is the one underneath them. Regulators can restrict a product, order a recall, or pull it from the EU market altogether. A fine is painful, but losing the right to sell in the EU is what ends a product line.

Keeping products secure for their whole life

Read the requirements again, and you'll find one unstable assumption holds the whole thing together. Every duty we've covered, from the years of free updates to the ongoing vulnerability fixes to the support period that can stretch past five years, assumes the manufacturer is still around to honor it.

The CRA is precise about what a maker must do across a product's life. It is almost silent on what happens if that maker doesn't make it that far. Companies go insolvent. They get acquired, and the new owner quietly retires the product. Some simply decide a line isn't worth maintaining and walk away. In each case, the legal duty to keep patching survives, but the team and the source code needed to act on it may not.

If your business depends on a CRA-regulated product, that five-year security promise is only as durable as the company behind it. Their collapse becomes your exposure: an unpatched system you can't repair, in software you don't hold the code for, still expected to stay secure. The obligation was written for the builder, but the fallout reaches the buyer.

Where software escrow fits

This gap isn't new. A support duty can easily outlive the company responsible for it, and there's a long-standing way to handle that, even though the CRA never names it.

Software escrow places a product's source code, build instructions, and documentation with a neutral third party. If the maker can no longer maintain the product, through insolvency, acquisition, or exit, the materials needed to keep it patched and supported can be released to the people who depend on it. In plain terms, it keeps the code recoverable when the company isn't.

That maps cleanly onto the CRA's logic. Where the regulation assumes someone can keep updating a product for years, software escrow is a way to make sure the means to do so still exists if the original maker doesn't. 

»  Take a deeper look into how software escrow helps across all regulated industries.

How to start preparing

None of this requires solving everything at once. A sensible approach to cyber resilience act compliance tends to move through the same early steps, whether you build these products or rely on them:

1. Classify your products. Work out which tier each product falls into, because that decides every requirement and deadline that follows.

2. Map your dependencies and build an SBOM. You can't secure what you can't see, so list the components inside your products before you try to manage them.

3. Stand up reporting before September 2026. Build the vulnerability and incident reporting processes early, because that obligation arrives well ahead of the main deadline.

4. Document for conformity. Keep the records that prove how each product meets the rules, since that evidence is what the assessment and CE marking rest on.

5. Review the suppliers you depend on. For products you buy, ask what happens to their support and their code if the vendor fails, and put continuity arrangements in place where the answer worries you.

Step five is the one most compliance plans skip, and it's the one that protects you when a supplier you counted on is no longer there.

The real test the CRA sets

It's tempting to read the CRA as a launch-day test: build the product securely, document it, add the marking, and ship it. But the law's real demand is quieter and stricter. It asks that a product stay secure for years, through staff changes, ownership changes, and the plain possibility that the company that made it won't be there to finish the job.

Secure code on day one is the easy part. The real question the CRA puts to everyone in the chain, builders and buyers alike, is whether the means to keep a product safe will outlast the company that built it.

» If you're working out where escrow fits in that picture, see how it supports continuity under the CRA.