CRA rules for existing software and updates

What happens to products already on the market?

Article 69(2) of the CRA provides that products placed on the market before 11 December 2027 are subject to the regulation's requirements only if they undergo a substantial modification from that date. Article 69(3) expressly makes an exception for Article 14. Read both paragraphs together; quoting only the first produces an incomplete answer.

The relevant facts concern placing the product on the market, not merely starting a company, opening a repository or creating a release tag. Article 3 distinguishes first making available on the Union market from subsequent availability. For software with continuing distribution and multiple versions, document what was supplied and when. An old product name alone cannot establish the position for every later supply.

Does reporting apply before the main deadline?

Yes. Article 71 makes Article 14 applicable from 11 September 2026, and Article 69(3) extends that reporting duty to existing products within CRA scope. A team should therefore prepare reporting decisions and escalation for its supported estate instead of waiting for its first post-2027 release.

Keep the triggers precise: actively exploited vulnerabilities contained in the product and severe incidents affecting its security have distinct reporting tracks. A high-severity advisory is not automatically a reportable event, while an urgent review must not wait for a completed patch. The Article 14 timeline covers awareness, early warning, notification and the different final reports. Existing-product status is not itself a reason to skip that review.

What counts as a substantial modification?

The Article 3(30) definition concerns a change after placing on the market that affects compliance with the essential cybersecurity requirements in Annex I, Part I, or changes the intended purpose for which the product was assessed. Apply that test to the change and its effects. Major, minor and patch are release-management labels, not legal outcomes.

Recitals 39 and 41 explain the treatment of changes and software updates. Maintenance and security updates do not automatically become substantial modifications merely because code changed. Conversely, presenting a release as maintenance does not settle the question if it changes intended purpose or affects conformity. Record a reasoned analysis of the actual behaviour and security properties.

Compare three release scenarios

These examples illustrate the questions to investigate. They do not predetermine the legal answer for an actual product, and the reviewer should consider combined changes across the release rather than assessing each commit in isolation.

A parser security patch removes a memory-safety defect while retaining the same supported formats, privileges and intended purpose. Capture the advisory, source change, regression tests and build. Explain why the patch restores the assessed security properties and whether anything else changed. Do not classify it as substantial merely because the dependency version increased.

A local document tool adds remote administration with privileged command execution. That change introduces new functions, trust boundaries and possible classification questions. Update the threat model and examine the effect on intended purpose and essential requirements. Calling it version 2.1 does not make the analysis optional.

An enterprise customer modifies a supplied product and redistributes it under its own name. Review the economic-operator role as well as the modification. Articles 21 and 22 address cases where importer, distributor or other modifying actors take on manufacturer obligations. A vendor's earlier file does not automatically cover the altered product.

Keep a modification decision record

Use this suggested record in the release review. The CRA does not prescribe these exact fields; they organise the facts a reviewer needs to apply the legal test and explain the conclusion later.

• Baseline: product, version, placement evidence, intended purpose and previous assessment references.
• Change: new or removed functions, interfaces, privileges, dependencies and deployment assumptions.
• Security effect: affected Annex I requirements, changed threats, controls, tests and open uncertainty.
• Role and route: responsible manufacturer, classification implications and required external review.
• Conclusion: substantial or not, rationale, supporting evidence, reviewer, date and unresolved conditions.
• Follow-through: technical-file updates, customer instructions, support effects and any new assessment work.

Preserve the baseline while assessing the change

Retain the evidence for the previous released state while gathering evidence for the new one. A queued or failed assessment should not replace the last usable record, and a changed dependency list must not rewrite what earlier customers received. Use the release-evidence checklist to keep both versions reconstructable.

ConformOps maintains release and assessment history, but the modification conclusion remains an accountable manufacturer decision. Where the legal effect is uncertain, give a specialist the concrete before-and-after record. That is more useful than asking whether a version number sounds like a substantial change.