The Cyber Resilience Act Explained: The Next Compliance Wave for Manufacturers
A practical Elyrion briefing explaining the EU Cyber Resilience Act, what it means for manufacturers and why product cybersecurity must become a lifecycle governance discipline.
Executive answer
The EU Cyber Resilience Act (CRA) changes the cybersecurity question for manufacturers from “Is our organisation secure?” to “Can we demonstrate that our products are designed, maintained and supported securely throughout their lifecycle?”
That distinction matters.
Traditional information security programmes tend to focus on protecting the organisation: its networks, identities, data and internal systems. The CRA extends the governance problem into the products themselves.
For manufacturers of products with digital elements, cybersecurity is no longer simply an IT responsibility. It becomes part of product engineering, risk management, quality assurance, vulnerability management, documentation and executive oversight.
The practical challenge is therefore not producing another cybersecurity policy.
It is building a product lifecycle in which security decisions are made deliberately, vulnerabilities are handled systematically and evidence exists to demonstrate that the process actually works.
The regulatory shift
The Cyber Resilience Act is part of the EU’s broader attempt to raise the baseline level of cybersecurity for products entering the European market.
Its scope is deliberately broad. Products with digital elements can include hardware, software and connected products that contain digital functionality or depend on digital components.
That creates a very different compliance problem from a conventional corporate ISMS.
An organisation can have excellent internal access controls, security awareness training and incident response procedures while still shipping a product containing an exploitable vulnerability.
The CRA is concerned with that product-level risk.
Manufacturers therefore need to understand cybersecurity as part of the product lifecycle:
Design → Development → Assessment → Release → Monitoring → Vulnerability Handling → Updates → End of Support
The important word is lifecycle.
A secure product at launch is not necessarily a secure product three years later.
New vulnerabilities emerge. Dependencies change. Attack techniques evolve. Customers deploy products in environments the manufacturer did not anticipate. Previously trusted components become unsupported.
The governance system has to account for that reality.
The operational problem
The most common mistake will be treating CRA compliance as a documentation exercise.
A manufacturer discovers that it needs technical documentation, vulnerability processes, security information and conformity evidence. A project begins. Teams produce documents. Legal reviews the wording. Engineering supplies technical information. Someone creates a vulnerability management procedure.
The organisation now has a CRA folder.
That does not necessarily mean it has a CRA capability.
Consider a relatively ordinary scenario.
A software product contains 140 third-party dependencies.
One of those dependencies receives a critical vulnerability disclosure.
Who discovers it?
Who determines whether the affected product is actually vulnerable?
Who determines the severity?
Who decides whether customers need to be notified?
Who develops and tests the remediation?
Who approves the release?
Who determines which product versions require the update?
Who records the decision?
And, perhaps most importantly, can the manufacturer demonstrate what happened six months later?
If the answers depend on someone remembering to send an email to the right engineer, the organisation does not have a mature vulnerability management process.
It has an informal dependency on individual knowledge.
That distinction becomes increasingly important as regulatory expectations increase.
Security has to move upstream
The CRA’s significance is not simply that manufacturers have more compliance obligations.
It changes where cybersecurity decisions need to happen.
Security cannot be bolted onto the end of product development.
If security requirements are considered only immediately before release, the organisation has already lost many of its cheapest opportunities to reduce risk.
A mature product security model starts much earlier.
Security requirements should influence architecture.
Threat modelling should influence design decisions.
Secure development practices should influence engineering workflows.
Dependency management should operate throughout development.
Testing should provide evidence before release rather than discovering fundamental design problems after deployment.
Vulnerability handling should continue after the product reaches customers.
This creates an important governance principle:
The earlier a security decision enters the product lifecycle, the cheaper it generally is to change the underlying design.
That is not unique to the CRA. It is simply good engineering.
The regulation makes the consequences of ignoring it considerably harder to dismiss.
What good looks like
A defensible CRA operating model does not require a separate bureaucracy surrounding every engineering team.
In fact, creating one can make the problem worse.
The objective should be to integrate security governance into processes that already exist.
A mature manufacturer should be able to connect several layers of evidence.
Product governance
Every relevant product should have a clearly defined security owner and an understood lifecycle.
The organisation should know:
- Which products fall within CRA scope
- Who owns security decisions for each product
- Which components and dependencies the product relies upon
- What security requirements apply
- How long the product will be supported
- What happens when vulnerabilities are discovered
- What happens when support eventually ends
This sounds straightforward.
In practice, product portfolios often make it surprisingly difficult.
Acquisitions, legacy products, embedded software, outsourced development and independently managed business units can create a fragmented ownership model.
Before controls can be improved, the organisation needs to know what it actually owns.
Secure development
Security requirements should be incorporated into the software and product development lifecycle rather than maintained as a parallel compliance process.
That can include:
- Threat modelling
- Secure coding requirements
- Code review
- Dependency management
- Software composition analysis
- Vulnerability scanning
- Security testing
- Release gates
- Security acceptance criteria
The exact control set should depend on the product and its risk profile.
The point is not to turn every release into a six-week security review.
The point is to make security a normal engineering constraint.
Vulnerability management
This is where many organisations will discover that their existing processes are weaker than they assumed.
A vulnerability management capability needs to answer the entire chain:
Detect → Assess → Prioritise → Remediate → Verify → Communicate → Record
A vulnerability ticket being closed is not the same thing as a vulnerability being managed.
A defensible process should establish how severity is determined, who owns remediation, how exceptions are approved and how the organisation verifies that the fix actually resolved the underlying exposure.
For products with long support lifecycles, this becomes a continuous operational capability rather than a pre-release activity.
Product security evidence
One of the most useful ways to think about CRA readiness is to ask a simple question:
If a regulator, customer or conformity assessment body challenged this decision tomorrow, what evidence would we produce?
The answer should not be a collection of screenshots assembled retrospectively.
Evidence should emerge naturally from operational systems.
For example:
A security requirement can be linked to a development ticket.
A development ticket can be linked to a release.
A release can be linked to testing results.
A vulnerability can be linked to a remediation.
A remediation can be linked to a new release.
The resulting chain creates something much more valuable than documentation.
It creates traceability.
The SBOM problem is bigger than a document
Software Bills of Materials are frequently discussed as if producing an SBOM is the primary objective.
It is not.
Knowing what components exist inside a product is useful only if the organisation can do something with that information.
An SBOM can tell you that a product contains a particular library.
A functioning product security capability should be able to use that information when a vulnerability is disclosed.
The operational question becomes:
“Which of our products are affected, and what do we need to do about them?”
That requires more than generating an inventory once per release.
It requires maintaining component visibility as products evolve and connecting that information to vulnerability intelligence, product ownership and remediation workflows.
This is a recurring pattern in cybersecurity governance:
Visibility without ownership creates information. Visibility with ownership creates control.
Where the ISMS still matters
The CRA does not make ISO 27001 irrelevant.
The two address different parts of the problem.
An ISO 27001 ISMS can provide the organisational governance foundation around information security: risk management, leadership responsibilities, policies, internal audit, corrective action and continual improvement.
The CRA introduces product-specific cybersecurity obligations that need to connect into that broader governance environment.
For manufacturers operating an existing ISMS, this can be an advantage.
The organisation may already have mechanisms for:
- Risk assessment
- Control ownership
- Documented procedures
- Internal audits
- Corrective actions
- Management review
- Supplier governance
- Incident management
The question is whether those mechanisms extend effectively into product security.
If they do not, the manufacturer can end up with two disconnected systems:
Corporate security on one side. Product security on the other.
That creates duplicated effort and, more importantly, gaps between organisational governance and engineering reality.
The better model is an integrated one.
Product security risks should feed into enterprise risk governance.
Product vulnerabilities should have defined escalation paths.
Security performance should reach appropriate management forums.
Corrective actions should be tracked to completion.
And the evidence generated by engineering should support the organisation’s wider assurance model.
A practical CRA readiness sequence
Manufacturers do not need to begin by rewriting every policy they have.
A more useful starting point is establishing the operational baseline.
01 — Determine product scope
Identify which products with digital elements are potentially within scope.
Do not begin with documentation.
Begin with the product portfolio.
02 — Establish ownership
For every relevant product, identify who owns cybersecurity decisions.
If ownership is ambiguous, remediation will eventually become ambiguous too.
03 — Map the product lifecycle
Document how products move from concept to development, release, maintenance and eventual end-of-support.
Then identify where security decisions currently occur.
The gaps often become obvious.
04 — Map vulnerability handling
Follow a real vulnerability from discovery through remediation.
Do not review the procedure in isolation.
Take an actual example and ask what happened at every stage.
This exposes informal workarounds, unclear responsibilities and evidence gaps much faster than reviewing policy documents.
05 — Establish component visibility
Determine how the organisation maintains visibility over software components and dependencies.
Then test what happens when a significant vulnerability is announced.
Can the organisation identify affected products quickly?
If not, that is an operational risk.
06 — Build the evidence chain
Connect requirements, risks, engineering activities, testing, releases and remediation records wherever practical.
The objective is not maximum documentation.
The objective is defensible traceability.
07 — Test the system
Finally, simulate the situation the governance model is supposed to handle.
Take a serious vulnerability.
Introduce it into the scenario.
Then ask the organisation to demonstrate what happens.
A process that works on paper but collapses during a realistic scenario is not ready.
The executive question
Leadership should not ask:
“Are we CRA compliant?”
That question encourages a binary answer to a continuous operational problem.
A better question is:
“Can we demonstrate that cybersecurity is governed throughout the lifecycle of every product for which we are responsible?”
That question changes the conversation.
It forces clarity around ownership.
It exposes weaknesses in product inventories.
It reveals whether vulnerability management is genuinely operational.
It tests whether engineering and governance actually communicate.
And it turns compliance from a deadline into a management capability.
Executive takeaway
The Cyber Resilience Act represents another step in the European shift from cybersecurity as an internal IT concern towards cybersecurity as a governed business responsibility.
For manufacturers, that responsibility follows the product.
The challenge is therefore not to create a larger compliance department.
It is to build a product security operating model that engineering teams can actually execute.
Know what you build.
Know what is inside it.
Know who owns its security.
Know how vulnerabilities are handled.
Know what evidence demonstrates that the process works.
And make those mechanisms part of normal product operations rather than a temporary response to regulation.