The product was secure at launch. What changed after?

For years, cybersecurity assurance followed a familiar logic: assess the product, test it, release it, support it.

That model still matters, but it is no longer enough.

A connected product can remain physically unchanged while its cybersecurity condition changes materially. A new vulnerability is discovered. A dependency falls out of support. An operating environment changes. A security update is released but not deployed across the full installed base. A third-party component becomes the weakest point in a system that was considered acceptable when it entered the market.

The commercial product name may remain unchanged. The product state does not.

That is the leadership problem.

Security is not a launch conclusion

Article 13(3) of the Cyber Resilience Act makes this explicit. The manufacturer's cybersecurity risk assessment must be documented and updated as appropriate during the support period. That assessment must consider intended purpose, reasonably foreseeable use, conditions of use and the period during which the product is expected to remain in use.

That changes the meaning of assurance. The organisation is not being asked only whether the original cybersecurity assessment was sound. It must be capable of revisiting that assessment as the product and its operating context change.

Consider two units sold under the same product name. One runs the latest software, receives current security updates, operates on a supported platform and uses maintained dependencies. The other runs an older configuration, has deferred a security update, depends on software approaching end of support and sits inside an operating environment that differs from the one originally assessed.

Commercially, they are the same product. From a cybersecurity-governance perspective, they may no longer be the same product state.

The installed base begins to diverge

After release, different units accumulate different histories.

Some update automatically. Some customers delay because production cannot stop. Some installations are air-gapped. Some are maintained locally or by integrators. Some remain attached to legacy infrastructure because replacing the product would mean replacing the system around it.

Anyone who has worked with long-lived technical products will recognise the pattern. The commercial lifecycle, the engineering lifecycle and the field lifecycle rarely end at the same time. A product may disappear from the roadmap while substantial installed populations remain in service for years.

The Readiness Directive describes this as Installed-Base Divergence: the growing distance between the configuration originally assessed and the multiple product states that actually exist in use.

That is not CRA terminology. It is a governance interpretation of a lifecycle problem the Regulation makes harder to ignore.

When leadership asks whether a product is secure, the first response should increasingly be another question:

Which population of the product are we talking about?

The answer may depend on software version, update status, operating environment, dependency condition, connectivity, support status and what the organisation now knows.

Support periods are a judgement, not just a date

Article 13(8) requires manufacturers to determine a support period reflecting how long the product is expected to be in use. The mandatory considerations include reasonable user expectations, the nature of the product including its intended purpose, and relevant Union law determining product lifetime. The period must generally be at least five years unless expected use is shorter.

The Regulation then allows manufacturers to take additional factors into account, including support periods for comparable products, availability of the operating environment, support periods of integrated third-party components providing core functions, and relevant Commission or ADCO guidance. These are permitted considerations rather than mandatory ones.

That distinction matters.

If an organisation chooses to shorten, extend or structure support around the life of critical dependencies, it is exercising a judgement that the Regulation leaves to it. The question is not merely whether a date was selected. It is whether that date still corresponds to the product condition customers actually depend on.

A released update does not create one new product state

A vulnerability is identified. Engineering develops a fix. The update passes testing and is released.

That sequence can look complete from inside change control.

But release establishes availability. It does not establish field condition.

After release, several populations may exist at once:

units that updated successfully;
units waiting for an approved maintenance window;
units that cannot accept the update;
deployments where the update created compatibility problems;
units that rolled back;
unsupported configurations still operating.

The intervention may reduce risk overall while increasing variation across the installed base.

That is the governance problem. The important question is not simply whether the update was approved.

It is:

What product population exists after the intervention?

The CRA gives limited flexibility on latest-version remediation

Article 13(10) deals with a narrow software case. Where a manufacturer has placed subsequent substantially modified versions of a software product on the market, it may comply with the essential vulnerability-remediation requirement in Annex I, Part II, point (2) only for the latest version, provided users of earlier versions can move to that version free of charge and without additional costs to adapt their hardware or software environment.

That is useful flexibility. It is also conditional.

The governance question is whether the installed base actually meets those conditions.

Can every relevant customer migrate without hardware change? Does migration require operational downtime that makes "free of charge" only part of the real burden? Are there configurations in the field that cannot move to the latest version?

The Regulation defines when the latest-version approach may be used. Product governance still has to establish whether those conditions exist in practice.

Unsupported populations do not disappear

Article 13(11) acknowledges something many lifecycle systems struggle with: unsupported software remains in use.

Manufacturers may maintain public archives of historical versions, but where they do, users must be clearly informed about the risks associated with using unsupported software.

That is important because end of support is not the same as end of use.

A product can continue performing its physical function after the software environment around it has degraded. An operating system may no longer be maintained. A dependency may stop receiving fixes. A customer may continue using a historical version because changing it would disrupt a wider installation.

The product can still "work" while the assumptions supporting its cybersecurity condition have changed.

Support can end before product exposure ends.

The governance issue is whether the organisation understands which unsupported populations remain in use and what condition they are actually in.

The CRA keeps the risk assessment alive

Article 13(3) is not the only continuing obligation.

Article 13(7) requires manufacturers to systematically document relevant cybersecurity aspects, including vulnerabilities of which they become aware, and where appropriate to update the cybersecurity risk assessment.

Article 13(21) then goes further. From placing on the market and throughout the support period, manufacturers who know or have reason to believe that the product or their processes are not in conformity with the essential cybersecurity requirements must immediately take the necessary corrective measures, or withdraw or recall the product as appropriate.

That provision deserves more attention than it usually receives.

It means the CRA does not treat conformity as a declaration frozen at release. It creates a continuing obligation linked to what the manufacturer knows or has reason to believe about the current condition of the product and its processes.

That is the regulatory anchor for the article's central proposition.

The relevant question is no longer:

Was the product secure when it launched?

It is:

Does the organisation still have a defensible basis for saying the product remains in the condition its earlier assessment assumed?

Security interventions have a long tail

Article 13(9) requires security updates made available during the support period to remain available for at least ten years after issue, or for the remainder of the support period if that is longer.

That reflects an important operating reality. A security intervention is not a momentary technical event. Its consequences persist across the installed base.

A mature organisation therefore needs to distinguish at least four things:

Availability
Was the update released?

Deployment
Which units actually received it?

Effectiveness
Did it materially address the vulnerability in the relevant configurations?

Residual state
Which units remain exposed, unsupported or outside the intended post-update condition?

A dashboard that says "patch released" answers only the first question.

The governance object has to change

Most product-governance systems still organise decisions around a stable product identity: model number, release version, approval record, commercial name.

That is increasingly inadequate for products with digital elements.

The more useful governance object is the Dynamic Product State.

It asks what exists now across several dimensions:

physical configuration;
digital configuration;
connectivity;
support condition;
operating environment;
current organisational knowledge.

The concept is not statutory terminology. It is The Readiness Directive's interpretation of the operational problem created when product condition continues to change after release.

Two units can share a commercial identity while requiring different risk decisions.

One may still sit comfortably inside the assumptions supporting the original assessment. Another may not.

A practical product-state test

Take one connected product family still in active use.

Do not begin with the latest released version. Begin with what is actually in the field.

Can the organisation identify:

The digital populations
Which software, firmware and configuration states are actually operating?

The support populations
Which units remain inside the intended support environment, and which do not?

The intervention populations
Which units received the latest relevant security action, and which remain outside it?

The dependency populations
Which products rely on components, platforms or services whose support condition has changed?

The knowledge state
What does the organisation know today that it did not know when the product was originally assessed?

If the answer is still expressed only as a product name and the latest released version, the organisation does not yet have a current product-state view.

That is the finding.

The Cyber Resilience Act gives this argument a firm legal foundation. The cybersecurity risk assessment must be updated during the support period. Vulnerabilities must be handled throughout that period. Unsupported software remains a recognised condition. Manufacturers who know or have reason to believe that conformity has been lost must act.

The broader governance conclusion is simpler.

A product does not remain secure because it was secure once.

It remains defensible only while the organisation can establish which product state exists, what has changed and whether the assumptions supporting the earlier assessment still hold.

The product was secure at launch.

That is no longer the question.