CRA is a product portfolio decision before it is a compliance programme.

For an industrial manufacturer, the Cyber Resilience Act will rarely arrive as one clearly defined cybersecurity project.

It cuts across product families, embedded software, connected services, customer-specific variants, third-party components and products expected to remain in the field for many years.

The main CRA obligations will apply from 11 December 2027. Reporting obligations concerning actively exploited vulnerabilities and severe incidents start earlier, on 11 September 2026. The dates are clear. The practical response is not.

For engineering leaders, the first challenge is therefore not to launch the largest possible compliance programme.

It is to decide what the organisation is actually trying to make compliant.

Start with the future product portfolio

The first management question should not be:

How do we make every existing product CRA-compliant?

A more useful question is:

Which products do we intend to continue placing on the European market after December 2027?

For some products, the business case for further investment will be clear. They are strategically important, commercially viable and expected to remain in the portfolio.

Other products may be approaching end-of-life. They may depend on ageing software, unsupported components or architectures that would require disproportionate investment.

In those cases, CRA may accelerate a decision that was already approaching:

• upgrade the product;

• replace it with a newer platform;

• reduce the number of variants;

• or phase it out.

This is not primarily a cybersecurity decision. It is a product portfolio decision involving commercial priorities, engineering capacity and expected product lifetime.

Assess product families, not hundreds of isolated variants

Industrial portfolios often contain many configurations of what is fundamentally the same product.

A pump, drive, control system or meter may exist in different sizes, markets and customer variants while sharing much of the same architecture, software and component base.

Analysing every variant independently can create a great deal of work without providing management with a better decision basis.

A more practical starting point is to group products into clusters based on factors such as:

• common architecture and software;

• communication technologies;

• third-party components;

• intended use and operational environment;

• support model and expected lifetime;

• shared development and maintenance processes.

Product clustering does not remove the need to demonstrate conformity for the relevant products. It makes the portfolio sufficiently manageable to assess, prioritise and plan.

The gap is wider than the product

CRA is not limited to adding security features to a product.

Manufacturers must document cybersecurity risk assessments, address cybersecurity throughout the product lifecycle, handle vulnerabilities, maintain information about software components and exercise due diligence when integrating third-party components. The regulation also requires support periods that reflect expected product use and are generally at least five years. It specifically recognises that products used in industrial settings may remain in service for considerably longer.

For most industrial organisations, this creates several connected workstreams.

Secure development

Are cybersecurity requirements integrated into product planning, architecture, development, testing and release processes?

Vulnerability handling

Can the organisation receive, assess, prioritise, correct, communicate and report vulnerabilities throughout the relevant support period?

Products and architecture

Which technical gaps exist in each product family, and which changes belong at product, platform or component level?

Suppliers and components

Does the organisation have sufficient visibility of third-party software, firmware and hardware dependencies?

These workstreams interact, but they do not necessarily require the same specialists or the same timing.

Engineering capacity will become the constraint

The people required to close CRA gaps are usually the same people already delivering:

• customer commitments;

• new product development;

• platform roadmaps;

• product maintenance;

• quality improvements;

• cost-down initiatives;

• supply-chain changes.

CRA does not create additional architects, software engineers or product specialists simply because it creates additional obligations.

The director-level question is therefore not only:

What will CRA cost?

It is also:

What will we need to delay, stop or reprioritise to create the required capacity?

A CRA roadmap that does not connect to the wider engineering portfolio may look credible in isolation while remaining impossible to execute.

The first deliverable should be a management decision basis

A company does not necessarily need a large CRA programme as its first step.

It needs a sufficiently robust assessment to answer:

1.    Which products and product families are within scope?

2.    Which products should remain in the portfolio beyond 2027?

3.    What compliance approach will the organisation follow?

4.    Where are the most significant product, process and organisational gaps?

5.    What decisions, capabilities and engineering capacity will be required?

The output should not be an exhaustive catalogue of every possible activity.

It should give management enough evidence to define the scope, prioritise the work and decide how the next phase should be organised.

For some organisations, a focused early assessment may prevent months of activity on products or gaps that should never have been prioritised.

Different stages require different professionals

CRA is not one discipline, and it is unlikely that one person will cover the full journey.

The early phase may require someone who combines CRA and standards knowledge with an understanding of industrial product development and can establish the initial scope, compliance approach and management decision basis.

Later phases may require capabilities within:

• CRA and relevant standards;

• OT and product cybersecurity;

• secure development;

• vulnerability handling;

• software and product architecture;

• supplier and component management;

• programme and project leadership.

Within the Escape network, experienced freelance professionals can support different parts of this journey.

The engagement may begin with a focused assessment. It may then move into specialist gap analysis, defined gap-closure activities or coordination of several workstreams across the organisation.

The objective is not to deploy a fixed consulting team from the outset.

It is to bring in the relevant capability when the organisation needs it, while retaining clear internal ownership.

Start with the right problem

For industrial manufacturers, CRA is unlikely to be solved through a compliance checklist alone.

The first leadership task is to establish:

• which products matter;

• which gaps matter;

• what needs to happen first;

• and who has the capability and capacity to make it happen.

That is how CRA becomes a manageable product and execution programme rather than an additional list of obligations competing for attention.