The CRA deadline is 2027. Your engineering deadline is probably earlier.
The main Cyber Resilience Act obligations will apply from 11 December 2027.
For many industrial manufacturers, that is not the most important planning date.
Products need to be designed, developed, tested, released, manufactured and integrated into customer solutions before they reach the market. A component intended for a customer programme in 2027 may therefore need to be ready considerably earlier.
The legal deadline may be December 2027.
The relevant engineering deadline may be the next platform release, customer integration milestone or design freeze.
Waiting for final standards is still a decision
Technical standards will play an important role in CRA implementation.
The European Commission has issued a standardisation request covering 41 horizontal and product-specific standards. Products that conform to harmonised standards referenced for CRA purposes can benefit from a presumption of conformity with the essential requirements covered by those standards. Development work is being led by the European standardisation organisations in cooperation with industry.
The Commission also published practical CRA guidance in July 2026 addressing issues such as scope, substantial modification, support periods, reporting and cybersecurity risk assessments. Further interpretation and standardisation work will nevertheless continue.
For engineering leaders, the question is therefore not whether every detail is final.
It is:
What can we responsibly begin before every detail is final?
Waiting may reduce the risk of making an incorrect assumption.
It also reduces the time available for implementation.
Not every decision is equally uncertain
A practical CRA programme should divide decisions into three categories.
Decisions to make now
These are activities where the direction is sufficiently clear and delay mainly consumes available time.
Examples include:
establishing executive and operational ownership;
identifying relevant product families;
assessing scope and product classification;
reviewing current secure-development practices;
examining vulnerability-handling capability;
improving visibility of software and component dependencies;
identifying affected suppliers and internal stakeholders.
These activities are useful even if detailed technical standards continue to develop.
Decisions to prepare now
Some decisions may depend on further clarification, but the analysis can begin.
The organisation can assess alternatives, identify dependencies, estimate engineering capacity and prepare implementation options.
This might include:
architecture changes;
supplier requirements;
conformity-assessment routes;
documentation structures;
tooling choices;
updates to development and quality processes.
Preparation allows the organisation to act quickly when the remaining uncertainty is resolved.
Decisions that genuinely need to wait
Some technical decisions may create substantial rework if taken too early.
Those decisions should wait deliberately.
But each delayed decision should have:
a clear owner;
a defined dependency;
an expected review point;
and visibility of the activities affected by the delay.
Waiting deliberately is programme management.
Leaving an issue unresolved because nobody owns it is not.
Make assumptions visible
A CRA roadmap developed while standards and guidance continue to evolve will contain assumptions.
That is not necessarily a weakness.
The weakness is allowing assumptions to become hidden facts.
For each significant assumption, the programme should record:
what is being assumed;
what evidence supports it;
which activities depend on it;
what would cause it to change;
who is responsible for reviewing it.
This allows the organisation to update the roadmap without repeatedly restarting the programme.
It also gives management a more honest view of risk and decision confidence.
Plan against product and customer milestones
CRA should not be planned as an isolated regulatory timeline.
For each affected product family, the organisation should work backwards from the milestones that determine when changes can realistically be introduced:
platform and product releases;
customer programme commitments;
verification and validation;
external assessment or certification;
manufacturing readiness;
supplier lead times;
service and support preparation.
Missing one of these windows may delay implementation by an entire development or product cycle.
The practical question is therefore:
What is the latest responsible point at which this change can enter the product roadmap?
That date may be much earlier than December 2027.
Integrate CRA into the engineering portfolio
A separate CRA roadmap can be internally consistent and still be undeliverable.
The same specialists are often already committed to NPD and NPI programmes, customer projects, platform development and product maintenance.
CRA activities must therefore be integrated with the wider engineering portfolio.
Management needs visibility of:
shared resources;
competing milestones;
architecture dependencies;
decisions requiring executive prioritisation;
work that must be stopped, delayed or resequenced.
Without that integration, CRA becomes another priority that every function agrees is important but no function has capacity to deliver.
Do not turn technical specialists into the programme office
CRA requires specialist knowledge.
Cybersecurity experts, architects and senior engineers will be essential when interpreting requirements, assessing risk and selecting technical solutions.
They should not automatically become responsible for every meeting, dependency, status report and escalation across the programme.
Someone still needs to manage:
the integrated roadmap;
cross-functional dependencies;
decisions and assumptions;
resource conflicts;
management reporting;
risks and escalation;
coordination with existing programmes.
Technical ownership and execution ownership are both necessary.
They do not always belong with the same person.
Keeping the roles distinct protects scarce specialist capacity and improves the quality of both technical and programme decisions.
Build the capability around the phase
The capability required will change as the CRA initiative develops.
An effective model may include:
Early assessment
CRA and standards expertise combined with product-development understanding to establish scope, product clusters, assumptions and priorities.
Specialist analysis
Focused work within areas such as OT and product cybersecurity, secure development, vulnerability handling, architecture or supplier dependencies.
Gap closure
Technical and process changes delivered through defined workstreams.
Programme execution
Project and programme leadership to coordinate dependencies, capacity, governance and management decisions.
Within the Escape network, experienced freelance professionals can support these different parts of the journey.
A client may initially need one experienced profile to complete an assessment and challenge the proposed approach. Later, the requirement may shift towards a technical specialist, a workstream lead or an experienced programme manager coordinating several functions.
This flexible model does not remove the need for strong internal ownership.
It allows the organisation to add the specific capability or capacity it does not currently have, without assuming that one consultant or one fixed team must cover everything.
Focus on the next sound decision
No organisation will remove all uncertainty before starting its CRA work.
The more useful management questions are:
1What can we start with the information available today?
Which decisions are genuinely dependent on further clarification?
Which product or customer milestones create an earlier internal deadline?
Where will CRA compete with existing engineering commitments?
Who is accountable for turning technical input into coordinated execution?
The objective is not to move quickly without sufficient evidence.
It is to avoid waiting for perfect certainty while the remaining implementation window continues to narrow.
