The Cyber Resilience Act just made your software a liability the buyer inherits

From 11 September 2026, the state of your code stops being a private engineering matter and becomes a reported, penalised, transferable liability. In an acquisition, that liability walks into the data room with the asset. Here is what sell-side teams should establish before it does.

For years, the condition of a company's software was an internal concern. Messy dependencies, thin test coverage, undocumented modules: real problems, but private ones, visible only to the people who wrote the code. The Cyber Resilience Act ends that privacy. It reclassifies the security state of software into a regulated obligation with reporting duties, financial penalties, and, for anyone contemplating a sale, a liability that transfers with the asset.

If you are heading towards a fundraise or an acquisition, the consequence is narrow and expensive. The technical unknowns in your codebase are no longer only an engineering risk. They are now a priced, provable exposure that the other side of the table will quantify. The question is whether you quantify it first, on your terms, with certification that holds up, or whether the buyer finds it in due diligence and reprices around it.

What the Cyber Resilience Act actually changes

The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024 and applies in stages. The first hard deadline is close. From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT, on a 24-hour, 72-hour, 14-day cascade. That obligation reaches products already on the market, not only new releases. The full body of requirements, secure-by-design obligations, conformity assessment, CE marking and technical documentation, applies from 11 December 2027. Non-compliance carries penalties of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.

Two features matter for anyone who may sell the company. First, the obligations attach to almost any software made available on the EU market, regardless of where it was built. Second, they are not one-off. They run across the product's whole lifecycle, which means the exposure does not reset at a change of ownership.

Why this lands hardest in an acquisition

An acquirer is not asking whether your product is impressive. They are asking a colder question: if we buy this, what are we now exposed to? The CRA gives that question a sharper edge and a number attached to it.

A vulnerability class you never quantified, a dependency with an abandoned maintainer, a component with no clean bill of materials: before the CRA these were quality concerns. Now they are potential reporting failures and potential fines, and they follow the software into the buyer's hands. In deal terms, an unquantified compliance exposure is exactly the kind of finding that moves from the technical annex to the price. It becomes a warranty you are asked to give, an indemnity you are asked to underwrite, or a discount you are asked to accept. None of those are good places to be negotiating from.

What the buyer's technical team will now look for

The dimensions a serious technical review works through are already well established, and the CRA raises the stakes on most of them:

• >Security. Known and exploitable weaknesses, and whether you could even detect them across your own product.
• >Dependencies. What you rely on, whether any of it is a licensing problem or an abandonment risk, and whether you can produce a complete bill of materials.
• >Documentation. Whether a new team can understand the system, or whether the knowledge leaves with the founders.
• >Test coverage. Whether behaviour is verified or assumed.
• >Observability. Once it is running, whether you can tell what it is actually doing, which is the precondition for reporting anything inside 24 hours.
• >Error handling. Whether the system fails safely or silently.
• >Code quality. Whether the codebase is maintainable or a rewrite waiting to happen.

These are the seven technical dimensions that determine what your software is actually worth, and they are now also the dimensions that determine what it might cost. The economic value, the number a deal turns on, is derived from them. It is not a separate opinion. It is what these seven produce.

Why your own answer will not be enough

Here is the part most teams get wrong. They answer every one of these questions with confidence and no evidence, and they assume the confidence carries. It does not, and not because anyone doubts your honesty. It is structural. You are the interested party.

No buyer accepts the seller's valuation of the seller's own asset, in any asset class, and they are even less inclined to accept the seller's own assurance that the asset carries no regulatory exposure. A self-reported figure has no standing in the room, and none at all if the matter later reaches legal or financial proceedings. What changes the conversation is not a better internal number. It is an independent one, produced by someone other than you, on a method the other side can examine.

What to establish before the data room opens

The move is to arrive with the answer already established. Instead of being asked, mid-diligence, what your software contains and improvising a reply, you present an independent valuation that measures the seven technical dimensions, derives the economic value from them, and is sealed by a Trusted Third Party.

That is what a Certified Software Valuation is. It produces a Production Readiness Score across the technical dimensions, a Technical and Economic Valuation of the codebase, and an Evidence Certificate that the other side can rely on precisely because you did not produce it yourself.

To be clear about what it does and does not do: a Certified Software Valuation does not make you CRA-compliant. Compliance is a separate, ongoing programme. What it does is tell you, and the buyer, exactly where you stand on the dimensions the CRA cares about, with certification that holds up in a negotiation and in the proceedings that may follow. It turns the exposure from something the buyer discovers into something you have already measured, priced and can defend. That is the difference between setting the anchor and reacting to theirs.

Start valuation. If you are preparing a specific transaction, talk to the team about a deal-stage valuation.

Common questions

Does the Cyber Resilience Act apply to my company?

If your product contains software or firmware, connects to a network directly or indirectly, and is made available on the EU market in the course of a commercial activity, it is very likely in scope, regardless of where it was built. The main exceptions are sector-specific products already regulated elsewhere (medical devices, vehicles, aviation) and genuinely non-commercial open source.

When do the CRA deadlines take effect?

Reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026. The full set of requirements, including conformity assessment and CE marking, applies from 11 December 2027. Penalties reach €15 million or 2.5% of worldwide annual turnover, whichever is higher.

How does the CRA affect an M&A transaction?

It converts the security state of your software into a regulated liability that transfers with the asset. A buyer's technical due diligence will now price unquantified CRA exposure into the deal, as a warranty, an indemnity or a reduction in valuation. Establishing an independent valuation before diligence lets you measure and defend that exposure first.

How do you value a company's software before an acquisition?

Independently. The credible method measures the codebase across seven technical dimensions (security, code quality, dependencies, documentation, test coverage, observability, error handling), derives an economic valuation from them, and has the result certified by a Trusted Third Party, so the figure is one the buyer can rely on rather than one they discount for self-interest.

Does a Certified Software Valuation make me CRA-compliant?

No. Compliance is a separate, continuing obligation. A Certified Software Valuation tells you and the other side where you stand on the technical dimensions the CRA cares about, with independent certification, which is what makes the position defensible in a negotiation.

Sources: European Commission, Cyber Resilience Act (Regulation (EU) 2024/2847), digital-strategy.ec.europa.eu. Dates and penalty figures as published by the European Commission.