The Cyber Resilience Act (CRA) is one of the most significant cybersecurity regulations introduced in recent years. Its objective is clear: improve the cybersecurity of products with digital elements placed on the European market. For manufacturers, importers and other economic operators, the regulation introduces requirements intended to strengthen product security and improve the handling of vulnerabilities throughout a product’s lifecycle.
As organizations work to understand and implement these requirements, much of the discussion understandably focuses on compliance activities. Questions about technical documentation, vulnerability reporting, conformity assessments and regulatory obligations dominate conferences, webinars and boardroom discussions.
These topics are important.
Compliance matters.
However, I believe there is a risk that organizations become so focused on documentation and regulatory interpretation that they overlook the larger opportunity the CRA presents.
In my view, the organizations that will gain the greatest value from the CRA will not be those that produce the most documentation. They will be those that use the regulation as a catalyst for improving product security practices across their organization. The CRA may be a regulation, but its lasting impact could be its ability to encourage higher levels of product security maturity.
Security responsibilities do not end at product release
For many years, organizations have often treated product security as a development activity that culminates in a successful release. Once a product passes testing, receives approval and enters the market, attention naturally shifts to the next release cycle. The CRA challenges organizations to think more broadly about product security responsibilities.
Although product development remains critical, cybersecurity must also be considered after products are deployed and operating in the real world. Vulnerabilities may be discovered, threat actors may develop new attack methods, and software components may be affected by newly disclosed security issues. The practical implication is that cybersecurity cannot be viewed as a one-time project completed before launch. Security becomes part of an ongoing lifecycle.
This shift may appear subtle, but it has significant consequences for how organizations structure their security programs. Documentation remains important, but documents alone do not detect vulnerabilities, assess risks, communicate with customers or support remediation activities. Those outcomes depend on people, processes and operational capabilities.
Vulnerability management: Where theory meets reality
One area where this distinction becomes particularly visible is vulnerability management. Most organizations today recognize the importance of having documented procedures for managing vulnerabilities. Policies, workflows and disclosure channels have become increasingly common across many industries. Yet the true test of a vulnerability management process does not occur when the policy is written. It occurs when a vulnerability is discovered.
Consider a manufacturer that learns about a critical vulnerability affecting a product already deployed in customer environments. The organization must quickly assess the vulnerability, understand affected products, determine the potential impact, coordinate technical analysis, communicate with relevant stakeholders and develop corrective actions.
The challenge is no longer documentation.
The challenge becomes execution.
- Can the organization coordinate effectively across engineering, product management, customer support, communications and leadership teams?
- Can decisions be made quickly and consistently?
- Can evidence be maintained showing how the issue was handled?
In my experience, vulnerability management is one of the clearest indicators of cybersecurity maturity because it demonstrates whether documented processes can function in practice. Many organizations have robust policies. Fewer have repeatedly demonstrated their ability to execute those policies efficiently under pressure. This distinction matters because customers increasingly expect manufacturers not only to understand security risks but also to respond effectively when vulnerabilities emerge.
Secure development must be demonstrated, not declared
Like vulnerability management, where a policy is verified when a vulnerability is discovered, software security measures must be demonstrated before you know if they work in real situations.
Security-by-design and secure-by-default concepts are widely discussed throughout the cybersecurity community, and for good reasons. Strong security outcomes begin long before a product reaches customers.
Many organizations have established secure development frameworks intended to integrate cybersecurity considerations into product development activities. These frameworks often include elements such as security requirements, threat modeling, code review, security testing and release approval processes.
The question, however, is not whether such activities are defined.
The question is whether they are consistently performed.
Imagine an organization releasing a new industrial internet of things (IIoT) gateway. The organization may have a documented secure development process that specifies security reviews and testing before release. The real measure of maturity is whether those activities were actually completed.
- Was a threat model developed?
- Were security requirements identified and tracked?
- Was security testing performed?
- Were findings reviewed and addressed before release?
- Can evidence be produced showing that the process was followed?
Organizations often discover that maintaining consistency across multiple projects, product teams, suppliers and development cycles is significantly more difficult than defining the process itself. This is one reason I believe security maturity should be viewed as a capability rather than a compliance exercise. Compliance can often be achieved through documentation and evidence collection. Security maturity requires repeatable execution over time.
Why ISA/IEC 62443 remains relevant
For organizations operating in industrial and operational technology environments, one encouraging reality is that many companies are not starting from zero. Over the last decade, ISA/IEC 62443 has become an important framework for improving industrial cybersecurity practices. The standard promotes concepts such as risk-based decision-making, secure development, defense in depth, lifecycle thinking, governance and continuous improvement.
It is important to recognize that ISA/IEC 62443 and the CRA are not the same thing; implementation of one should not automatically be viewed as compliance with the other. However, organizations that have already invested in ISA/IEC 62443 initiatives may find that several practices encouraged by the standard support broader cybersecurity objectives that are also relevant when addressing CRA requirements. This is particularly true in areas such as secure development, risk management, vulnerability handling, security governance and lifecycle management.
Rather than starting with a blank sheet of paper, many organizations may already possess portions of the cybersecurity foundation required to support their broader regulatory objectives. The challenge often lies in demonstrating consistency, strengthening governance and ensuring that cybersecurity activities are embedded throughout the organization rather than concentrated within a single department.
Incident response reveals organizational readiness
If vulnerability management demonstrates how an organization handles product security issues, incident response demonstrates how the organization performs during periods of uncertainty and pressure. Nearly every organization has an incident response plan. Far fewer organizations have tested their plan repeatedly under realistic conditions.
Consider a situation where a customer or security researcher reports a vulnerability that has potential implications across multiple deployed products.
- Technical analysis must begin quickly.
- Engineering teams need information.
- Management requires updates.
- Customers want guidance.
- Communication decisions must be coordinated carefully.
- Responsibilities often span multiple business functions.
The effectiveness of an organization’s response is not determined solely by the quality of its documentation. It is determined by how effectively people collaborate when confronted with a real situation. Incident response exercises frequently expose hidden dependencies, communication challenges, governance gaps and resource constraints that may not be visible during routine operations.
For this reason, I often view incident response readiness as a practical indicator of organizational maturity. Organizations that regularly test, refine and improve their incident response capabilities tend to develop greater resilience over time. They become more familiar with decision-making under pressure and more confident in their ability to manage cybersecurity events when they occur.
From compliance projects to security programs
One of the most common mistakes organizations can make is treating the CRA as a stand-alone compliance project. The pattern is understandable. A regulation is introduced. A project team is established. Requirements are mapped. Policies are updated. Documentation is produced. Evidence is collected. These activities are necessary and often unavoidable.
However, organizations may achieve significantly greater long-term value by viewing the CRA as an opportunity to strengthen broader product security programs rather than to simply satisfy regulatory obligations. This perspective encourages investment in capabilities that provide benefits beyond compliance.
- Secure development practices improve product quality.
- Effective vulnerability management strengthens customer trust.
- Incident response readiness improves resilience.
- Governance processes help organizations make better risk-based decisions.
These outcomes remain valuable regardless of how regulations evolve in the future.
When organizations focus exclusively on compliance, they often ask, “What is the minimum we must do?” Organizations pursuing security maturity ask a different question: “How do we build capabilities that improve security outcomes while supporting regulatory objectives?” The second question typically produces stronger long-term results.
Looking beyond compliance
The Cyber Resilience Act will undoubtedly influence how organizations approach product security in the years ahead. Regulatory compliance will remain an important consideration, and manufacturers will need to understand their obligations. Yet I believe the most successful organizations will view the CRA as more than a compliance requirement. They will see it as an opportunity to strengthen the disciplines that ultimately determine security outcomes: secure development, vulnerability management, governance, lifecycle management and incident response.
Documentation plays an important role. Evidence matters. Regulatory obligations cannot be ignored. But cybersecurity is ultimately demonstrated through execution. The organizations that derive the greatest value from the CRA will likely be those that use the regulation to build stronger security capabilities, establish sustainable practices and improve resilience across the entire product lifecycle. In the long run, that may prove far more valuable than compliance alone.
