Cyber Resilience Act: with ETSI, Europe enters the operational phase

The 17 draft European standards published by ETSI mark a new stage in the implementation of the Cyber Resilience Act. For manufacturers, as well as for organisations that purchase, integrate or operate digital products, the CRA is becoming a much more concrete topic.

The Cyber Resilience Act (CRA) is one of the most significant developments in the European cybersecurity framework in recent years.

Adopted as Regulation (EU) 2024/2847, it introduces horizontal cybersecurity requirements for products with digital elements made available on the European market.

Until now, much of the discussion around the CRA has naturally focused on its scope, the organisations concerned and the regulatory deadlines.

A new phase is now beginning: the translation of the regulation into technical and operational requirements.

On 13 August 2026, ETSI announced the availability of 17 final draft vertical European standards, currently undergoing public enquiry. Belonging to the ETSI EN 304 xxx series, they are intended to become harmonised standards supporting the CRA.

They form part of a broader programme: the European Commission’s standardisation request M/606 covers 41 horizontal and vertical standards designed to support the implementation of the regulation.

This development is gradually changing the nature of the discussion.

The question is no longer only:

“What does the CRA require?”

It is increasingly becoming:

“How can an organisation demonstrate, in practice, that a product meets those requirements?”

From regulation to technical evidence

The CRA defines essential cybersecurity requirements.

It requires manufacturers, among other things, to assess the cyber risks associated with their products and to take those risks into account throughout design, development, production, delivery and maintenance.

But a regulation cannot define every technical mechanism applicable to every browser, operating system, industrial device, network component or connected solution.

That is precisely the role of standardisation.

Horizontal standards are intended to provide common approaches for cross-cutting topics such as vulnerability management. Vertical standards, by contrast, are tailored to specific categories of products.

The 17 texts currently published by ETSI belong to this second category and are still at the public enquiry stage. They should therefore not yet be presented as final harmonised standards.

This distinction matters.

Once a standard is formally harmonised and its reference is published in the Official Journal of the European Union, its application may provide a presumption of conformity for the CRA requirements it covers.

In practice, the regulation and the standards therefore play complementary roles:

the CRA defines the expected security outcome; the standards progressively translate that outcome into technical specifications that can be used to demonstrate conformity.

Security must be built into the product

One of the most important consequences of the CRA is that cybersecurity can no longer be treated as a layer added at the end of development.

It must become part of the product and its lifecycle.

The regulation requires manufacturers, among other things, to identify and document vulnerabilities and components contained in their products.

Annex I, for example, requires the creation of a Software Bill of Materials (SBOM) in a commonly used and machine-readable format, covering at least top-level dependencies.

The CRA also introduces requirements relating to regular security testing and reviews, vulnerability handling, coordinated vulnerability disclosure, security updates and the secure distribution of those updates.

This fundamentally changes the way conformity must be approached.

It becomes difficult to develop a product for several years and then, as a regulatory deadline approaches, attempt to build the documentation required to demonstrate that the product is secure.

To understand dependencies, identify vulnerable components, maintain a usable SBOM, distribute secure updates and react quickly to a critical vulnerability, these capabilities must already have been built into the architecture and development processes.

CRA conformity cannot simply be added at the end of a project. It must be built into the product and maintained throughout its lifecycle.

Responsibility continues after the product reaches the market

This logic does not stop when the product is commercialised.

Article 13(8) of the CRA requires manufacturers to determine a support period reflecting the length of time during which the product is reasonably expected to remain in use.

That period must be at least five years, unless the product is reasonably expected to be used for less than five years. Where the expected lifetime is longer, particularly for certain industrial devices, operating systems or network equipment, the support period must be adapted accordingly.

Five years should therefore not be understood as either a ceiling or necessarily the standard support period.

This provision gives a regulatory dimension to questions that were previously often dealt with mainly through contracts:

How long will the product actually be maintained? How long will security patches remain available? What happens when a critical vulnerability is discovered in a third-party dependency? How are customers informed? And how can an update be distributed securely without introducing new risk?

Lifecycle management therefore becomes an integral part of both product cybersecurity and conformity.

The CRA is also a supply chain issue

Modern digital products are rarely built exclusively from components developed by the manufacturer itself.

Open-source libraries, frameworks, operating systems, hardware components, third-party modules and APIs now form a significant part of almost every digital product.

The CRA reflects this reality.

This means that a manufacturer cannot limit its security analysis to the code it develops internally. It must also understand the risks associated with the components it integrates.

This is where the SBOM becomes particularly relevant.

An SBOM helps answer a fundamental question:

“What does my product actually contain?”

But inventory is only the beginning.

An SBOM that is not connected to vulnerability monitoring, risk assessment, prioritisation and remediation remains largely documentary.

Real maturity means being able to answer another question quickly:

“A new vulnerability has just been disclosed: which products, which versions and which customers are affected, and what do we need to do?”

The CRA therefore brings Product Security, vulnerability management and supply chain security much closer together.

Who is really the “manufacturer”?

This is one of the areas that deserves the closest attention.

An organisation should not determine its CRA role solely on the basis of its commercial or contractual title.

The regulation sets out distinct obligations for manufacturers, importers and distributors. But these roles can change.

An importer or distributor is considered a manufacturer if it places the product on the market under its own name or trademark, or if it makes a substantial modification to a product already placed on the market.

The CRA goes even further: another natural or legal person that makes a substantial modification and then makes the product available again on the market may also be considered a manufacturer for the affected part — or potentially for the product as a whole where the modification affects its overall cybersecurity.

This question is particularly important for integrators, resellers, white-label providers and organisations that heavily customise products before supplying them to their own customers.

Being initially described as a “buyer” or “integrator” does not guarantee that an organisation will remain outside the legal responsibilities of a manufacturer.

The European Commission also published specific guidance in July 2026 intended, among other things, to clarify the concept of substantial modification, the CRA’s scope and support periods.

Internal software: avoid shortcuts

The same need for precision applies to internally developed software.

The CRA applies to products with digital elements made available on the market, meaning products supplied in the course of a commercial activity, whether for payment or free of charge.

An application developed and used exclusively within the same organisation should therefore not automatically be treated as a product placed on the market for the purposes of the CRA.

At the same time, simply describing an application as “internal” is not enough to conclude that it necessarily falls outside the scope.

The actual situation must be examined: how the software is supplied, to whom, under whose responsibility, and whether it is made available to third parties or other entities in the context of a commercial activity.

The right approach is therefore to avoid broad assumptions and perform a product-by-product scope assessment.

What about cloud services and SaaS?

The CRA also does not mean that the entire European cloud market automatically falls within the scope of the regulation.

The regulation does, however, introduce the concept of a remote data processing solution.

Such a solution can form part of the product where it is necessary for the performance of one of the product’s functions and has been designed or developed by the manufacturer, or under the manufacturer’s responsibility.

A backend service or API that is essential to the operation of an application may therefore, in certain circumstances, form part of the CRA scope.

Conversely, this does not mean that the entire cloud infrastructure used by a product automatically becomes part of the product itself.

The European Commission specifically included remote data processing solutions among the areas clarified in its CRA guidance published in July 2026.

For organisations, the consequence is straightforward:

the technical perimeter of the product must be understood before the conformity perimeter can be defined.

Procurement becomes a product cybersecurity lever

The CRA does not only affect the teams that develop products.

It will also influence the way they are purchased.

Article 5 contains an explicit provision on public procurement: where a product covered by the CRA is purchased in that context, Member States must ensure that compliance with the essential cybersecurity requirements — including the manufacturer’s ability to handle vulnerabilities effectively — is taken into account during the procurement process.

For the private sector, the CRA does not create an equivalent general obligation.

However, the regulation makes clear that public or private organisations may define additional cybersecurity requirements for their own procurement or usage purposes, beyond those required simply to place a product on the market.

It is therefore reasonable to expect CRA-related requirements to appear increasingly in:

• requests for proposal;

• procurement specifications;

• security questionnaires;

• supplier security annexes;

• contractual clauses;

• supplier assessments;

• third-party risk management programmes.

The questions asked of suppliers are likely to become much more precise.

It will no longer be sufficient to ask:

“Do you follow cybersecurity best practices?”

Organisations will increasingly need to understand how vulnerabilities are handled, how long the product will be supported, how patches will be provided, how third-party dependencies are managed, whether an SBOM exists, and which party is responsible when a critical vulnerability or incident affects the product.

The CRA therefore contributes to shifting supplier security from a primarily declarative model towards one that is increasingly demonstrable.

2027 is not the starting date

The CRA becomes generally applicable on 11 December 2027.

But some obligations begin earlier.

The provisions relating to the notification of conformity assessment bodies have applied since 11 June 2026, while the reporting obligations under Article 14 become applicable from 11 September 2026.

For an actively exploited vulnerability, the framework requires an initial early warning within a maximum of 24 hours, followed by a more detailed notification within a maximum of 72 hours.

Another provision deserves particular attention.

Products placed on the market before 11 December 2027 are generally only brought within the full scope of the CRA requirements if they subsequently undergo a substantial modification.

However, Article 69 provides an explicit exception for reporting obligations:

Article 14 also applies to products within the CRA scope that were already placed on the market before 11 December 2027.

This changes the way the timeline should be understood.

2027 is the date of general application of the CRA. It is not a reasonable date to start preparing for it.

Where should organisations start?

Organisations can already begin several workstreams without waiting for all harmonised standards to be finalised:

1. Map the CRA scope
   Identify the relevant products, how they are made available, and the organisation’s actual role in the value chain.

2. Assess existing product security practices
   Review architecture, secure development, testing, vulnerability management, updates, maintenance and end-of-life processes.

3. Understand components and dependencies
   Assess the ability to generate, maintain and operationally use reliable SBOMs.

4. Review the supply chain and contracts
   Consider support periods, vulnerability notification obligations, third-party components, patching responsibilities and contractual allocation of responsibilities.

5. Connect requirements, controls and evidence
   Build traceability so that conformity can be demonstrated rather than merely declared.

6. Follow ETSI, CEN and CENELEC standardisation work
   The standards now being developed will progressively define the technical mechanisms used to demonstrate conformity.

DarkProtect’s perspective: from documentary compliance to continuous capability

At DarkProtect, we believe that the main challenge of the CRA will not be producing more documentation.

It will be building a continuous chain of traceability:

risk → requirement → control → action → evidence.

A vulnerability management policy only has value if vulnerabilities are actually identified, assessed, assigned and remediated.

A supplier requirement only improves security if compliance with that requirement can be assessed and monitored over time.

An SBOM becomes genuinely useful when it allows an organisation to quickly determine product exposure when a new vulnerability emerges.

And a security control only provides meaningful assurance if the organisation can demonstrate that it exists, that it operates effectively and that it remains effective over time.

This is where the CRA reflects a broader evolution in European cybersecurity governance.

We are gradually moving from a model where compliance is assessed at a specific point in time, often around an audit, towards one where organisations need to demonstrate continuously how their risks are being managed.

That requires closer integration between disciplines that still too often operate in silos: GRC, Product Security, architecture, engineering, vulnerability management, procurement and third-party risk management.

The objective is no longer simply to state that a product is compliant.

Organisations must be able to explain why it is considered compliant, which requirements apply, which controls address those requirements, which evidence supports them and which risks remain open.

The standards are still being developed. The change has already started.

As of 7 September 2026, the 17 draft standards published by ETSI are still undergoing public enquiry and are not yet final harmonised standards.

Other standardisation work is continuing in parallel as part of the 41 standards requested by the European Commission.

It would therefore be premature to build a CRA programme today around a definitive interpretation of standards that are still evolving.

But waiting for their final publication before starting would be equally risky.

Evolving a secure development lifecycle, implementing operational SBOM management, reviewing supplier contracts, clarifying product responsibilities and building effective control traceability cannot be achieved in a few weeks.

The direction is already clear enough.

For manufacturers, the CRA means embedding cybersecurity more deeply into engineering and the product lifecycle.

For buyers, it means strengthening product security within procurement and supplier management.

For cybersecurity and GRC teams, it means building the connection between regulation, standards, risks, controls and evidence.

The Cyber Resilience Act should therefore not be seen simply as a compliance project to be completed in 2027. It represents a lasting change in the way Europe expects digital products to be designed, secured, maintained and governed.