The Cyber Resilience Act (CRA) readiness reality: why doing security isn’t the same as being compliant

Despite running penetration tests, assessing vulnerabilities, and fixing security issues, many industrial manufacturers still fall short on CRA readiness. CRA readiness isn't just about doing security work; it is about showing how decisions are made, who approves them, how risks are assessed, and what evidence supports those decisions.

We saw this in a CRA readiness assessment with a leading industrial device manufacturer. The organization was already testing products, identifying vulnerabilities, and fixing issues. What it could not yet provide was the documentation, traceability, and proof behind those actions.

We see this pattern repeatedly across industrial manufacturers. The challenge is not usually adding new security controls. It is establishing the ownership, documentation, and traceability needed to demonstrate that security has been considered and managed throughout a product’s lifecycle.

As the CRA moves closer to practical implementation, these gaps are becoming harder for organizations to ignore. 

Five questions industrial manufacturers keep asking about CRA readiness

The questions below reflect the issues that most often come up during CRA readiness discussions, and the approaches organizations are taking to address them.

We have ISO 27001. Isn’t that enough?

This is one of the most common assumptions we encounter. Organizations invest heavily in corporate security functions, establish governance structures, and maintain vulnerability management, incident response, and risk management processes.
But CRA does not assess those capabilities in isolation. It looks at how security is applied to each product across its lifecycle, from design and development to deployment, maintenance, and eventual decommissioning.
In one recent assessment, a manufacturer could not produce a security requirement for one of its flagship products. The corporate security framework existed, but it had never been translated into product-specific security requirements.

Can’t we document everything closer to the deadline?

CRA expects organizations not only to perform security activities, but also to maintain a clear record of them. Regulators, auditors, and market surveillance authorities assess the evidence organizations can produce, not the intentions behind the work.

Many organizations assume they can secure now and document later. In practice, that rarely works.
One client spent nearly three months reconstructing two years of security decisions from Teams conversations, email threads, and institutional memory. The result was substantial documentation, but it quickly fell apart when auditors asked basic follow-up questions.

The challenge is that security work happens every day, while evidence of that work becomes fragmented over time.

• Vulnerabilities are identified during development and integration.

• Patches are applied when issues emerge.

• Security risks are discussed during design reviews.

• Engineers make security decisions based on experience and technical judgment.

That shifts the focus from performing security activities to documenting them throughout the product lifecycle.

Even organizations with strong security practices can struggle if they cannot produce clear, auditable evidence of those activities.

Who actually owns CRA readiness?

The simplest questions often expose the biggest gaps.

• Who owns product cybersecurity risk?

• Who approves vulnerability disclosure decisions?

• Who maintains product security documentation over time?

• Who ensures regulatory reporting obligations are met?

In one client workshop, four different stakeholders gave four different answers about ownership of product security documentation.

That revealed a problem we see regularly: engineering teams, quality functions, and centralized security teams may each own part of the process, but no one owns the outcome.

CRA pushes accountability deeper into the product lifecycle than many organizations have historically implemented. That means manufacturers often need to rethink how they assign, document, and enforce security responsibilities.

What about legacy products?

CRA readiness rarely progresses in a straight line. Products within the same organization often sit at different levels of maturity depending on age, architecture, regulatory exposure, and development history.

Newer products may already incorporate modern secure development practices. Legacy products often require more work to strengthen governance and documentation before they can demonstrate the same level of readiness.

One manufacturer had a product in production and maintenance for more than five years. The engineering team understood its security posture well, but the documentation was fragmented across multiple systems, key records were outdated, and several of the engineers who made the original security decisions had left the organization.

That product became the starting point for the company’s readiness effort not because it was the least secure product in the portfolio, but because it exposed structural gaps across multiple products.

For many organizations, legacy products are the real test of readiness. They show whether security decisions can still be traced, explained, and evidenced years after they were made.

Does CRA readiness ever end?

Many organizations initially approach CRA readiness as a compliance project. They build checklists, assign ownership, and work toward a target state.

A readiness assessment often reveals a different reality. Compliance may exist on paper, but it does not always reflect how engineering teams work.

The organizations making the most progress treat CRA readiness as an engineering capability rather than a one-time compliance exercise. They tend to focus on three areas:

• Start with what already exists: Most organizations already conduct security reviews, remediate vulnerabilities, discuss risks during design reviews, and make important security decisions. The challenge is that evidence often sits across multiple tools, documents, and conversations. The fastest teams do not start by asking, “What do we need to create?” They start by asking, “What already exists, and how do we connect it?

• Clarify ownership before introducing new controls: Many organizations expect CRA readiness discussions to focus on technology. In practice, they often focus on ownership, accountability, and decision-making. Technical controls matter, but governance is usually the harder challenge. Organizations need clear accountability for product cyber risk, security documentation, vulnerability disclosure decisions, and regulatory obligations.

• Adapt the approach to different product types: The most effective organizations avoid a one-size-fits-all approach. They align readiness efforts to each product’s age, architecture, and regulatory exposure.

  For example:

  New products: modern architectures with strong documentation.

   Mid-life products: reasonable documentation with targeted gaps.

  Legacy products: fragmented documentation and heavy reliance on institutional knowledge.

Technical challenges are usually manageable. The bigger challenge is aligning governance, documentation, and product ownership around a consistent way of working.

How CRA helps beyond compliance? 

As organizations advance through this journey, many discover that the capabilities required for compliance create benefits well beyond regulatory readiness.

• Clear ownership improves decision-making.

• Traceability strengthens engineering discipline and helps teams identify issues earlier.

• Structured vulnerability management improves responsiveness to customer concerns.

• Lifecycle accountability strengthens trust in product security.

• Many organizations also report shorter incident response times, fewer security regressions in new releases, and stronger collaboration between engineering, security, and product teams.

The CRA is not simply introducing another regulatory obligation. It is accelerating a broader shift toward treating cybersecurity as a fundamental characteristic of product quality.

For industrial manufacturers, the most significant outcome may not be compliance itself. It may be the opportunity to build stronger accountability, better traceability, and more resilient product development practices across the entire lifecycle.