The CRA's implications extend across marketing & sales, product & service businesses, operations, cybersecurity, supply chain, governance, quality, legal and organisational capability. As a result, implementation requires coordination across multiple functions and business areas rather than responsibility being assigned solely to product development, compliance or cybersecurity teams.
Tolvanen describes a four-phase approach towards CRA readiness:
Phase 1: Identify products with digital elements
- Which products in our offering fall under CRA scope?
- How does CRA impact our business and risks?
- How can we turn CRA into competitive advantage?
- What investment(s) into CRA compliance is needed?
Phase 2: Create cybersecurity risk assessments
- To what extent are our products already conforming with the CRA?
- What product specific design changes are necessary?
- What future functionalities should we include in the risk assessment to avoid a substantial modification?
Phase 3: Develop products, processes and supply-chain practices
- How to design, implement and test product security functionalities?
- What architectural choices or changes will lower the engineering cost of security updates and enable sustainably fulfilling obligations throughout the support period?
- How should secure development lifecycle processes be improved?
- How can product security activities be accelerated and automated?
- What competence development is required?
- How should supply-chain security and business risks be managed?
Phase 4: Keep products and processes competitive and compliant
- Should I use a CRA Notified Body in conformity assessment?
- How much should I invest into post-market monitoring, vulnerability handling and incident handling?
Where organizations continue to face challenges
Although the Act is already partially in force and awareness is growing, many organisations are struggling to translate the obligations into practice within their organisation.
During a recent DNV Cyber webinar exploring European Commission guidance on the CRA, participants identified three recurring challenges:
- understanding how the CRA applies across different products
- coordinating change across functions and business areas
- adapting internal processes, management systems and cybersecurity risk assessment practices
These findings highlight a common theme. For many organizations, the challenge is no longer simply understanding the regulation itself. It is converting regulatory requirements into operational practices that can be embedded throughout the organization.
Building regulatory literacy
Tolvanen also emphasises the importance of regulatory literacy when preparing for CRA implementation. While many organisations are familiar with the Act itself, understanding how different sources of guidance and interpretation fit together can help support more informed implementation decisions.
For example, four in five webinar participants claimed familiarity with the CRA, but far fewer with the Guidance and FAQs. Only an eighth knew of the 2022 EU Blue Guide (C247) on implementing EU product rules. Tolvanen recommended having this to hand when reading the CRA, as the Blue Guide’s definitions of terminology and concepts help to understand CRA and CRA guidance.
| Regulatory literacy sources |
| Area |
Key points
|
| CRA |
- Legislative act with recitals, articles, and annexes
- References also other EU legislative acts
- Final binding interpretations decided by Court of Justice of the EU
|
| CRA Guidance |
- Non-binding guidance on interpreting the CRA
- Published due to CRA article 26, is not intended to be comprehensive (further interpretations are the responsibility of national market surveillance authorities)
|
| EU Blue Guide |
- Provides non-binding interpretations of terminology used in CRA and around 100 other product harmonization laws based on the same EU legal framework for product legislation
- Published in 2022, it does not cover newer developments (e.g. CRA specifics, AI Act, updated Product Liability Directive) but still helps in understanding and interpreting them
|
| CRA FAQ |
- Non-binding responses to most common questions about the CRA
|
Source: Antti Tolvanen, DNV Cyber; European Commission sources.
What the European Commission guidance clarifies
The Commission's guidance provides interpretation in several areas that have generated questions since the CRA proposal was initially published.
Scope and applicability
Understanding how products fall within the scope of the CRA is the first challenge for manufacturers. The guidance provides additional clarification regarding standalone software products, hardware products, complex systems, integrators, remote data processing and substantial modifications.
Standalone software products vs services
The CRA guidance defines what standalone software products are and distinguishes them from services which are outside scope of CRA unless they constitute remote data processing.
Complex systems and integrators
Products with digital elements within the scope of the CRA may also consist of complex systems, systems composed of multiple hardware and software elements that operate together to perform a certain function. Where such a system is placed on the market as a single product with digital elements, it constitutes a product with digital elements within the meaning of the CRA. An integrator is not substantially modifying other manufacturers’ products with digital elements but placing a new product with digital elements of its own on the market.
Manufacturer reporting obligations and vulnerability handling
The guidance offers further clarification around manufacturers' responsibilities concerning vulnerability handling, reporting obligations and related processes. These lifecycle obligations contribute to the CRA’s main objective to improve cyber resilience on Union level and reinforce the need for mature product security governance.
Secure development lifecycle
A recurring theme throughout the guidance is cybersecurity throughout the entire development lifecycle of a product, during the support period and even after it. Compliance is not a one-time activity but requires continuous efforts in product development, production, and vulnerability handling according to changes to functionalities and cybersecurity risks.
Supply-chain risk: an often-overlooked challenge
One of the most important themes highlighted by Tolvanen is the need to assess and manage third-party risk early in the compliance journey.
"Assessing and managing supply-chain risk early on is very important," he says. "In cybersecurity risk assessment, due diligence is needed for third-party components integrated into products."
This goes beyond technical vulnerabilities alone. Organisations must consider the long-term viability and security of suppliers whose components form part of their products. In the best case, suppliers are bringing CRA CE marked components to the market that have good compatibility with today's products.
"Companies need to evaluate if components used are credible and secure enough. Also, some of today's suppliers might not be in business later on or their products will become obsolete, and there's re-design risk."
As organisations build their approach to compliance, understanding internal and external dependencies may therefore prove just as important as understanding regulatory requirements.
Five questions organisations are still asking about the CRA
Even with this additional clarification, organisations continue to work through practical implementation questions as they assess applicability, build compliance programmes and prepare products for the full application of the regulation.
The audience questions discussed during the webinar illustrate where uncertainty remains and where organisations continue to seek clarity.
- How does the CRA apply to software distributed as source code?
CRA guidance section 2.3. Computer code and 3 Free and open-source software provide helpful interpretations. Standalone software products can be supplied either as source code or machine code, and CRA may apply if the code is supplied in the course of a commercial activity.
- What evidence will organisations need to demonstrate compliance?
Conformity assessment procedures are in CRA Annex VIII and needed technical documentation is listed in Annex VII. The evidence ranges from description of intended purpose, cybersecurity risk and applicable essential cybersecurity requirements in Annex I Part I(2) to description of the design, development, production and vulnerability handling processes. The different conformity assessment procedures are discussed in CRA FAQ and Commission is also preparing a guideline for Notified Bodies on conformity assessment procedures involving them.
- What obligations do end users have? Do obligations change if the end user is a manufacturer that incorporates an in-scope product with another product?
Under CRA end-users have no obligations. However, according to CRA 13(5) manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements.
- How does the CRA interact with other regulations and sector requirements?
In CRA article 2, certain products with digital elements falling under other product harmonisation laws or Union rules are excluded from the scope of the CRA. Several legislations can apply concurrently on a given product, and on top of that there can be sector specific requirements that also apply.
- What are the implications for communications equipment, human-machine interface (HMI) hardware devices and other specialist technologies?
CRA applicability and product conformity needs to be assessed case-by-case by their manufacturers.
Sector-specific considerations: Maritime
Ships, ship systems and components are already facing strict cybersecurity class rules under IACS UR E26 and E27. Therefore, it came as a surprise to the maritime industry that only equipment falling under the Marine Equipment Directive (MED) is excluded from the scope of the CRA.
Perhaps the maritime industry presumed that CRA would not affect them, as there was no maritime related feedback on CRA proposal, and CRA went under the radar. The reason for this presumption could have been that, for example, Machinery Regulation does not apply on seagoing vessels and mobile offshore units and machinery installed on board such vessels or units. Individual vessels of inland, sea and coastal passenger and freight water transport companies are also excluded from scope in NIS2 directive.
Organisations in the maritime industry initiated discussions with EU Commission to widen the maritime CRA exclusion from MED to a wider range of products, but scope exclusion amendments to CRA for maritime sector products are not to be expected before full applicability of CRA. How CRA will be enforced on maritime sector products could eventually be up to national supervisory authorities to decide.
Compliance as an opportunity
The CRA introduces new obligations for manufacturers and other economic operators making available products with digital elements on the European market. But viewed through a broader enterprise risk lens, it also presents opportunities. Some organisations may see CRA solely as a compliance cost. Others may see it as an investment opportunity to create a competitive advantage.
As Tolvanen concludes, organisations with products that are certain or likely to fall within CRA scope should already be taking actions towards CRA compliance.
For a deeper discussion of the topics covered in this article, including practical examples and audience questions, readers can access the full on-demand webinar recording here. Organisations looking to move from interpretation to implementation can also join DNV Cyber's upcoming webinar, "Preparing for CRA Compliance: From Guidance to Action", for further insights into practical compliance considerations.
