Cyber Resilience Act: The New Product-Security Baseline

A technical and legal analysis of the EU Cyber Resilience Act, explaining product scope, economic-operator roles, essential cybersecurity requirements, conformity assessment, component dependencies, vulnerability reporting, transition, and practical assurance governance.

Why the CRA changes the EU cybersecurity architecture

The Cyber Resilience Act (CRA) establishes a horizontal Union product-security regime for products with digital elements. Article 1 defines that regime through four connected elements: rules governing the making available of products with digital elements on the Union market; essential cybersecurity requirements for their design, development, and production; essential requirements for the vulnerability-handling processes that manufacturers must operate during the period in which their products are expected to be used; and rules on market surveillance and enforcement.¹

This structure is important because the CRA does not treat cybersecurity only as an organisational-management obligation. It embeds cybersecurity into Union product law. The Commission’s 2026 material explains that the CRA is built on the EU’s New Legislative Framework (NLF), including the concepts of manufacturer responsibility, conformity assessment, EU declarations of conformity, CE marking, accreditation, supply-chain economic operators, and market surveillance.²

For an in-scope product, the manufacturer must therefore connect technical cybersecurity engineering to a legally controlled market-placement process. The manufacturer must identify the product it is placing on the market, perform the cybersecurity risk assessment required by Article 13, implement the applicable essential cybersecurity requirements, prepare the technical documentation, complete the appropriate conformity-assessment procedure, draw up the EU declaration of conformity, and affix CE marking. Depending on the product classification and the applicable conformity route, a notified body may participate in that assessment. Importers and distributors have separate verification and corrective duties, while national market-surveillance authorities supervise products and economic operators under the CRA together with Regulation (EU) 2019/1020.³

The resulting architecture differs from the entity-level cybersecurity regimes already present in Union law. NIS2 imposes cybersecurity risk-management, governance, incident-handling, business-continuity, supply-chain-security, and reporting duties on covered entities.⁴ DORA establishes a specialised ICT-risk and digital-operational-resilience framework for financial entities.⁵ The CRA addresses a different legal object: the cybersecurity conditions under which an in-scope product with digital elements may be made available on the Union market and supported throughout the relevant lifecycle.

The distinction is therefore functional rather than hierarchical. The CRA does not replace NIS2, DORA, or sector-specific legislation. It adds a horizontal product-security layer whose obligations can apply to the same technology at the same time as organisational, safety, data-protection, sectoral, or liability rules.

Cybersecurity consequently becomes part of the legal conditions governing the product itself rather than merely:

• a contractual service level between supplier and customer;
• a voluntary certification claim;
• a security feature offered in a premium product tier;
• an internal secure-development policy; or
• an operational risk left entirely to the organisation deploying the technology.

The CRA also does not stop at the moment of initial market placement. The manufacturer must maintain vulnerability-handling processes, make security updates available as required, keep the cybersecurity risk assessment appropriately updated, provide required information to users, take corrective measures where non-conformity is identified, and comply with Article 14 reporting obligations when their statutory triggers are met.⁶ The product-law model is therefore lifecycle-oriented even though individual obligations have different temporal limits.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
    MFR([Manufacturer]):::entity
    PRODUCT[Product with digital elements]:::product
    USER([Customer or operator]):::entity
    MSA([Market-surveillance authority]):::entity

    CRA[/Cyber Resilience Act<br/>risk assessment, essential requirements<br/>conformity, support and reporting/]:::overlay
    SURVEILLANCE[/"Regulation (EU) 2019/1020<br/>market surveillance"/]:::overlay
    NIS2[/NIS2<br/>entity cybersecurity governance<br/>and risk management/]:::overlay
    DORA[/DORA<br/>financial-sector ICT risk<br/>and operational resilience/]:::overlay
    SECTOR[/Other Union product<br/>and sectoral legislation/]:::overlay
    AI[/AI Act<br/>coordinated requirements<br/>where Article 12 applies/]:::overlay
    LIABILITY[/Product-liability law/]:::overlay

    MFR --> PRODUCT
    PRODUCT --> USER

    CRA ==> PRODUCT
    SURVEILLANCE ==> MSA
    MSA --> PRODUCT

    NIS2 ==> USER
    DORA ==> USER
    SECTOR ==> PRODUCT
    AI ==> PRODUCT
    LIABILITY ==> PRODUCT

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;

Figure 1: The CRA adds a horizontal product-lifecycle cybersecurity regime to entity-level, sectoral, safety, market-surveillance, AI, and liability frameworks.

The regimes in Figure 1 can therefore apply simultaneously. A connected machine can fall within both the CRA and the Machinery Regulation where the respective conditions are met.⁷ For a product within both regimes, compliance with one Regulation does not automatically establish full compliance with the other, and the conformity-assessment procedure required by one does not automatically satisfy the procedure required by the other. CRA evidence can facilitate demonstration of overlapping cybersecurity risks—notably the Machinery Regulation requirements concerning protection against corruption and the safety and reliability of control systems in Annex III, sections 1.1.9 and 1.2.1—but the manufacturer must demonstrate the claimed synergy and complete the applicable procedures under both instruments.⁸⁹

The CRA also contains explicit coordination rules for products with digital elements that are classified as high-risk AI systems under the AI Act. Under Article 12, satisfaction of specified CRA requirements can establish compliance with the AI Act’s cybersecurity requirement, and the applicable conformity-assessment procedures are coordinated according to the product and assessment route.¹⁰

Civil liability remains a separate question. The revised Product Liability Directive is complementary to the CRA and can make cybersecurity characteristics, interconnection, post-market control, and necessary safety-related software updates relevant when assessing whether a product is defective.¹¹ Compliance with a CRA conformity procedure therefore does not eliminate possible liability under a separate legal regime.

A useful distinction is:

The CRA governs the cybersecurity conditions applicable to an in-scope product with digital elements and the manufacturer processes that sustain its conformity. Entity-level cybersecurity laws govern how covered organisations manage cybersecurity and operational risk in the systems, services, and activities for which they are responsible.

The distinction is not absolute. A vulnerability in a CRA-regulated product can contribute to a reportable NIS2 or DORA incident for an organisation using it. Conversely, compromise of a manufacturer’s build, signing, development, or update infrastructure can compromise the security of products supplied to users. A single technical event can therefore engage several legal regimes while the responsible actors, triggering conditions, evidence, and reporting channels remain legally distinct.

Market surveillance is consequently part of the CRA’s architecture rather than an administrative afterthought. Article 52 makes Regulation (EU) 2019/1020 applicable to products with digital elements and requires Member States to designate market-surveillance authorities. Those authorities can cooperate with CSIRTs, ENISA, cybersecurity-certification authorities, data-protection authorities, and other market-surveillance authorities where relevant.¹²

Their powers extend beyond inspecting whether CE marking is physically present. The CRA permits access, where the statutory conditions are met, to data and internal documentation relevant to design, development, production, vulnerability handling, and conformity. Authorities can evaluate products presenting significant cybersecurity risks and require corrective measures, restriction, withdrawal, or recall. Under Article 57, measures can also be required where a product and the processes put in place by its manufacturer comply with the CRA but nevertheless present a significant cybersecurity risk as well as a risk to health or safety, compliance with obligations protecting fundamental rights, the availability, authenticity, integrity or confidentiality of services offered by NIS2 essential entities, or other aspects of public-interest protection.¹³

The implementation timetable reflects the staged construction of this regime. The CRA entered into force on 10 December 2024. Chapter IV, concerning notification and operation of conformity-assessment bodies, has applied since 11 June 2026. Article 14 reporting obligations apply from 11 September 2026, while the Regulation applies generally from 11 December 2027.¹⁴

This sequencing has an important operational consequence: Article 14 readiness cannot be deferred until the general conformity date. Manufacturers of products falling within the CRA’s scope can become subject to the vulnerability and incident-reporting regime before the general product requirements apply to products newly placed on the market.

The interpretive status of the Commission’s 2026 material should also be stated precisely. On 27 July 2026, the Commission published C(2026) 5252 and the annexed content of draft guidance on the application of the CRA. The Commission’s public implementation pages describe the material as CRA guidance, but the accompanying communication states that the annexed guidance is to be formally adopted at a later date once all language versions are available.¹⁵

In any event, the annex itself states that the guidance is non-binding, does not cover the Regulation in its entirety, and does not replace case-by-case analysis. Authoritative interpretation of the CRA remains with the Court of Justice of the European Union.¹⁶ The legal baseline for the analysis that follows is therefore Regulation (EU) 2024/2847; the Commission material is used as official, non-binding implementation guidance explaining how the Commission currently interprets and expects key provisions to operate in practice.

Scope: which products, software, components, and remote services are regulated

The CRA’s scope begins with Article 2(1): it applies to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.¹⁷ Article 3 then defines a product with digital elements as a software or hardware product and its remote data-processing solutions, including software or hardware components placed on the market separately.

A defensible scope analysis therefore asks four questions:

1. Is there a software or hardware product, including a software or hardware component placed on the market separately?
2. Is that product made available on the Union market, meaning supplied for distribution or use in the course of a commercial activity, whether for payment or free of charge?
3. Does its intended purpose or reasonably foreseeable use include a direct or indirect logical or physical data connection to a device or network?
4. Does a specific Article 2 exclusion or legally established limitation apply?

A positive answer to the first three questions establishes the general scope conditions; the fourth determines whether the Regulation is nevertheless excluded or limited for the particular product.¹⁸ Commercial activity should not be equated simply with charging a purchase price: the Regulation expressly recognises that commercial activity can exist through other forms of monetisation, while the detailed treatment of free and open-source software requires a separate analysis.

A remote data-processing solution (RDPS) is then analysed as part of the product boundary. It is not an independent fourth type of candidate alongside hardware, software, and separately marketed components. It is remote processing that becomes part of an existing product with digital elements when the Article 3(2) conditions are satisfied.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    CANDIDATE[Software or hardware product<br/>including separately<br/>marketed components]:::product

    MARKET{Made available on the Union market<br/>in the course of<br/>commercial activity?}:::test
    CONNECTION{Intended purpose or foreseeable use<br/>includes direct or indirect<br/>logical or physical data connection?}:::test
    EXCLUSION{Article 2 exclusion or<br/>legally established limitation?}:::test

    INSCOPE[Product within CRA scope]:::product
    OUTSIDE[Outside CRA product scope<br/>on these facts]:::context
    EXCLUDED[CRA excluded or limited<br/>to the statutory extent]:::context

    REMOTE[/Remote-processing candidate/]:::overlay
    DISTANCE{Data processing<br/>at a distance?}:::test
    FUNCTION{Would its absence prevent<br/>one product function?}:::test
    RESPONSIBILITY{Software designed and developed<br/>by or under responsibility<br/>of the manufacturer?}:::test

    RDPS[RDPS software included<br/>within product boundary]:::product
    EXTERNAL[External service, infrastructure<br/>or dependency]:::context

    CANDIDATE --> MARKET
    MARKET -- No --> OUTSIDE
    MARKET -- Yes --> CONNECTION
    CONNECTION -- No --> OUTSIDE
    CONNECTION -- Yes --> EXCLUSION
    EXCLUSION -- Yes --> EXCLUDED
    EXCLUSION -- No --> INSCOPE

    INSCOPE --> REMOTE
    REMOTE --> DISTANCE
    DISTANCE -- No --> EXTERNAL
    DISTANCE -- Yes --> FUNCTION
    FUNCTION -- No --> EXTERNAL
    FUNCTION -- Yes --> RESPONSIBILITY
    RESPONSIBILITY -- No --> EXTERNAL
    RESPONSIBILITY -- Yes --> RDPS

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 2: CRA scope depends on a product with digital elements, Union-market supply in commercial activity, qualifying connectivity, and the absence of an applicable statutory exclusion; qualifying remote processing is then included within the product boundary.

Products manufactured solely for one’s own use do not cross the market-placement threshold

The CRA applies when a product with digital elements is placed on the Union market and to subsequent instances of making that product available. FAQ 1.5, applying the 2022 Blue Guide, explains that placing on the market does not occur where a product is manufactured solely for one’s own use. Its example concerns development and configuration tools created for the manufacturer’s internal use: those tools are outside CRA product scope unless they are subsequently placed on the market as separate products. Supply to another legal person, including another group company, requires a fresh analysis of whether the product has been made available on the market in the course of a commercial activity.¹⁹

Placing standalone software on the market requires a software-specific analysis

The CRA distinguishes making available on the market from placing on the market. Making available means supplying a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether for payment or free of charge. Placing on the market is the first such making available.²⁰

For physical products, the NLF ordinarily applies those concepts to individual units. Standalone software requires a different treatment because a new physical unit does not have to be manufactured each time a user receives an identical copy.

The Commission guidance therefore considers a completed standalone software product to have been placed on the Union market when that version is first supplied for distribution or use in commercial activity. The manufacturer is treated as having placed the identical copies of that software product on the market at that time, even where individual users obtain their copies later.²¹

Subsequent software iterations do not automatically establish a new placing-on-the-market date. Where an iteration does not constitute a substantial modification, the guidance treats it as continuing the existing placement. Where an iteration does constitute a substantial modification, it is newly placed on the market and the associated conformity consequences follow.²²

The analysis is also product-variant specific. Where software variants differ in their included components, configurations, or enabled functionalities, the Commission states that they cannot be treated as multiple identical copies of the same software product for placement-on-the-market purposes. They should instead be treated as distinct products with digital elements.²³

This makes a marketing name an insufficient product identifier. For software, the CRA inventory may need to distinguish:

• platform or operating-system build;
• included components;
• enabled functionality;
• relevant configuration;
• release or version family; and
• changes capable of affecting the substantial-modification analysis.

The Commission’s special treatment of simultaneous placement applies specifically to standalone software. It should not be transferred automatically to software that forms part of a hardware-software product.

Locally supplied software is different from software that is merely accessed remotely

Standalone software can itself be a product with digital elements where it is supplied to a user, obtained by that user, and operated on or as part of an electronic information system on the user’s side.²⁴

The Commission guidance therefore treats, subject to the other CRA conditions, examples such as:

• a mobile application downloaded and installed on a smartphone;
• a desktop application installed on a user’s system;
• a browser extension; and
• an application built with web technologies but packaged for local execution

as capable of constituting software products with digital elements.

By contrast, software that executes remotely and is merely accessed by the user does not become a standalone product with digital elements for that reason alone. The guidance specifically states that a web application accessed exclusively through a web browser is not, on that basis, a product with digital elements. Websites are likewise not themselves products with digital elements merely because some code executes in the user’s browser.²⁵

Remote software can nevertheless enter CRA scope as part of another product where it qualifies as an RDPS. The correct distinction is therefore between:

• software supplied to and operated on the user’s electronic information system;
• remote software that qualifies as part of another product through Article 3(2); and
• remote services that satisfy neither route.

Source code can itself be a software product

Article 3 defines software as the part of an electronic information system consisting of computer code. The Commission guidance interprets that definition as covering both machine code and source code.²⁶

Source code is therefore not outside the CRA merely because it requires adaptation, compilation, or interpretation before execution. The decisive question remains whether the code is supplied as a product with digital elements on the Union market in commercial activity.

The guidance gives the example of a company licensing source code to another company for a customisable internal platform. Even where the customer must modify and compile that source code, the supplier can still be placing a software product with digital elements on the market.²⁷

This should be distinguished from code that has not reached the supply phase. Unfinished code shared during design and development for testing or review, or sample and demonstration code supplied as part of training materials, is not ordinarily treated as a completed product placed on the market.

There is also an express statutory testing rule that should not be confused with that conclusion. Article 4(3) permits unfinished software that does not comply with the CRA to be made available for a limited period required for testing, provided that a visible indication makes clear that it does not comply and will not remain available for purposes other than testing.²⁸

This testing derogation is not a security-free zone. Recital 37 states that the manufacturer should release the unfinished software only after a risk assessment, comply with the product-security requirements to the extent possible, implement the vulnerability-handling requirements to the extent possible, and not force users to upgrade to versions released only for testing.²⁹³⁰

Free and open-source software requires a further analysis of responsibility, commercial activity, monetisation, support, and stewardship. The mere availability of source code is not sufficient to determine its CRA status.

Hardware and necessary manufacturer-provided software can constitute one product

Delivery through separate channels does not necessarily create separate products.

The Commission guidance states that where a hardware product is designed to work with specific software supplied by the same manufacturer and that software is necessary for the product to perform its intended functions, the hardware and software together constitute one product with digital elements.³¹

The software can therefore form part of the product even when it is:

• downloaded from the manufacturer’s website;
• obtained through an application store;
• installed after the hardware has been supplied; or
• otherwise delivered through a different channel.

The guidance illustrates this with a network printer whose manufacturer-provided drivers are necessary for operation and a fitness wearable whose manufacturer-provided mobile application is required to display measurements, history, or configuration. The legal boundary follows the functional relationship, not the packaging or delivery channel.

For such hardware-software combinations, the Commission guidance links the software’s placing on the market to the placing on the market of the relevant hardware units rather than applying the standalone-software placement model.

A data connection requires transmission of digitally encoded information

Article 2 requires a direct or indirect logical or physical data connection. The CRA defines logical connection, physical connection, and indirect connection, but does not separately define data connection.

The Commission guidance interprets the term by reference to the transmission of digitally encoded information. Mere presence of electrical or electronic signalling is therefore insufficient.³²

At a basic level, there must be:

• a source deliberately generating digital symbols according to an encoding scheme; and
• a destination capable of interpreting those symbols as information.

An electrical state that merely switches a function on or off does not automatically constitute a data connection simply because it can be represented as a binary state. The states must be intended to convey digitally encoded information.

Connectivity is nevertheless broader than direct Internet access. A product or component can be indirectly connected through a host device, gateway, controller, operating system, or larger technical system. The CRA definition of indirect connection expressly covers a connection to a device or network that does not take place directly but as part of a larger system.³³

Complex systems can themselves be products, but integration alone does not automatically create one

Products with digital elements can consist of multiple hardware and software elements operating together. The Commission guidance states that where such a complex system is placed on the market as a single product with digital elements, the system itself constitutes the product for CRA purposes.³⁴

The reverse does not follow automatically. A factory, building installation, telecommunications environment, or enterprise architecture can contain multiple CRA-regulated products without necessarily becoming a further single CRA product merely because the elements are technically interconnected. The market and product boundary must be established from the actual supply arrangement.

The Commission gives particular attention to long-lived and complex systems that rely on:

• architectures designed before the CRA;
• components acquired before the CRA applies;
• long development cycles;
• mandatory interoperability;
• established infrastructure; or
• dependencies that are difficult to change without affecting safety, reliability, or intended purpose.

Those characteristics do not themselves exclude the system from the CRA. They become part of the product’s risk and compliance context.

The guidance recognises that, in some cases, an essential cybersecurity requirement may not be applicable or may not be capable of implementation through the otherwise relevant state-of-the-art security measure because of the product’s intended purpose, dependency structure, or interoperability requirements. The manufacturer should then identify and document the constraint, assess the associated risks, and implement appropriate alternative or compensating risk-mitigation measures so that product security is not undermined.³⁵

Those constraints are not necessarily permanent. Because the cybersecurity risk assessment must remain updated during the support period, the manufacturer should periodically reassess whether the limitation still exists and, where it can reasonably be removed or reduced, update the product accordingly.

Products designed before full CRA application are not automatically grandfathered or required to be redesigned

The Commission guidance specifically addresses products designed or developed before the CRA’s general application date but whose units will be placed on the market after 11 December 2027.

A pre-existing design does not automatically have to be redesigned. The manufacturer must carry out the Article 13 cybersecurity risk assessment and determine which Annex I Part I requirements apply to the product, taking into account its intended purpose and reasonably foreseeable use.³⁶

Where that assessment demonstrates that the existing design already incorporates appropriate and effective security measures addressing the relevant risks, the CRA does not require additional security features merely because the original design process predates the Regulation.

This is not a grandfathering exemption. Units placed on the market after the CRA applies generally must still satisfy the applicable obligations, including:

• the cybersecurity risk assessment;
• applicable Annex I requirements;
• vulnerability-handling processes;
• the appropriate conformity-assessment procedure;
• technical documentation;
• the EU declaration of conformity;
• CE marking; and
• required information and instructions for users.

The Commission guidance also recognises that a manufacturer of a legacy design may be unable to reconstruct evidence showing how a CRA-style risk assessment influenced the original development process. In that situation, the manufacturer may perform and document a current risk assessment and demonstrate how the existing product mitigates the identified risks. The guidance does not require historical design or test evidence to be recreated where doing so would not contribute to improving product cybersecurity.³⁷

The accommodation concerns historical evidence; it does not relax the substantive requirement that the product placed on the market satisfy the CRA.

Remote data processing has three cumulative elements

Article 3(2) defines remote data processing through three elements:

1. data processing occurs at a distance;
2. absence of that processing would prevent the product with digital elements from performing one of its functions; and
3. the software for that processing was designed and developed by the manufacturer or under the manufacturer’s responsibility.³⁸

The Commission guidance adds an important product-boundary clarification: an RDPS consists of the software elements that perform the qualifying remote processing. The underlying physical or virtual hardware used to run that software does not thereby become part of the product with digital elements.³⁹

Nor does the RDPS concept extend the CRA to the manufacturer’s IT environment as a whole. Human-resources systems, payroll, CRM, general CI/CD infrastructure, penetration-testing systems, threat-hunting environments, and other internal systems do not become RDPS merely because they contribute indirectly to development or operation.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    LOCAL[Local product with digital elements]:::product
    REMOTE[/Remote-processing candidate/]:::overlay

    DISTANCE{Data processing<br/>at a distance?}:::test
    FUNCTION{Would its absence prevent<br/>one product function?}:::test
    RESPONSIBILITY{Relevant software designed<br/>and developed by or under<br/>manufacturer responsibility?}:::test

    RDPS[[RDPS software<br/>inside product boundary]]:::system
    EXTERNAL[Third-party or deeper<br/>external dependency]:::context
    INFRA[Underlying cloud or<br/>network infrastructure]:::context
    RISK[Cybersecurity risk assessment<br/>and product-level mitigation]:::product

    LOCAL --> REMOTE
    REMOTE --> DISTANCE
    DISTANCE -- Yes --> FUNCTION
    DISTANCE -- No --> EXTERNAL
    FUNCTION -- Yes --> RESPONSIBILITY
    FUNCTION -- No --> EXTERNAL
    RESPONSIBILITY -- Yes --> RDPS
    RESPONSIBILITY -- No --> EXTERNAL

    LOCAL --> RDPS
    EXTERNAL -. may affect security .-> RISK
    INFRA -. may affect security .-> RISK
    RISK -. informs .-> LOCAL
    RISK -. informs .-> RDPS

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef system fill:#f1f3f5,stroke:#5c6770,stroke-width:1.5px,color:#252a2e;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 3: A remote software element enters the CRA product boundary only when remote processing is functionally necessary and the relevant software was designed and developed by or under the responsibility of the manufacturer.

At a distance does not mean in a public cloud

The Commission guidance deliberately avoids an exhaustive definition of at a distance and requires case-by-case assessment. Remote processing typically occurs outside the user’s environment or, for a professional user, outside the organisation’s operational environment. Processing at the network edge can nevertheless qualify.⁴⁰

The infrastructure can therefore include:

• public-cloud infrastructure;
• private-cloud infrastructure;
• edge infrastructure;
• manufacturer-operated remote servers; or
• third-party infrastructure.

Physical ownership or geographic distance is not the decisive test.

The remote processing must be necessary for one product function

The second element is broader than core functionality. The function supported remotely need not define the product’s classification or entire intended purpose.

The guidance identifies examples such as:

• remote commands;
• file or state synchronisation;
• onboarding;
• product configuration or personalisation;
• automated distribution of functionality or security updates; and
• identity and access management.

The existence of a manual alternative does not necessarily eliminate the remote function. If a connected product offers remote control as one of its functions, the fact that the same physical result can also be produced manually does not mean that the remote-control function disappears from the Article 3(2) analysis.

Conversely, remote processing used solely for statistics, analytics, or future product development is not an RDPS where its absence would leave all product functions available. It can nevertheless remain relevant to the cybersecurity risk assessment if compromise of that external processing can affect the product.

The same distinction applies to web functionality. A webpage that merely presents product information does not become an RDPS. An authentication portal that supplies credentials or tokens necessary for a product function can qualify if the other elements of the definition are satisfied.

Under the manufacturer’s responsibility concerns design and development

The third element asks who designed and developed the relevant remote software.

Software designed and developed internally by the manufacturer can qualify. Software produced by an external contractor can also qualify where it is genuinely developed under the manufacturer’s responsibility. The Commission explains this as a tailor-made solution built solely by or on behalf of the manufacturer on the basis of the manufacturer’s designs and specifications.⁴¹

Merely licensing an existing third-party service, or using a slightly modified version of a generally offered service, does not satisfy that condition solely because the manufacturer configures or integrates it.

Who operates the resulting solution is not decisive. Manufacturer-designed software can remain an RDPS when hosted or operated by a third party.

The guidance illustrates the distinction through common cloud models:

• with IaaS, software deployed by the manufacturer on third-party infrastructure can qualify as an RDPS if the other elements are satisfied, while the underlying infrastructure itself does not;
• with PaaS, a manufacturer-controlled application can qualify even though the execution platform is supplied by a third party;
• with SaaS, a fully developed third-party application offered generally by the SaaS provider is not an RDPS where it was not designed and developed by or under the responsibility of the product manufacturer.

The RDPS boundary does not extend indefinitely through backend dependencies

The Commission’s banking-application example adds an important architectural limit.

Where an application interacts directly with a manufacturer-controlled banking interface that is necessary for the application’s functions, that interface can qualify as RDPS. Deeper account-management, ledger, settlement, or clearing systems with which the application does not directly interact do not become RDPS merely because the qualifying interface itself relies on them.⁴²

Those deeper systems remain capable of creating cybersecurity risk. They should therefore be represented as external dependencies in the product’s risk assessment and mitigated through appropriate product-level controls.

The product boundary and the cybersecurity-risk boundary are consequently not identical.

A system can remain outside the statutory product or RDPS boundary while still creating risks that the manufacturer must identify and address in the cybersecurity risk assessment.

Third-party remote services can be dependencies without becoming RDPS

The Commission illustrates this distinction with an e-reader that depends on a generic third-party SaaS storage service. The service is necessary for one of the e-reader’s functions, but it was not designed and developed by or under the responsibility of the e-reader manufacturer. It therefore does not qualify as RDPS.⁴³

The manufacturer must nevertheless assess the risks introduced by that dependency. The guidance says that such a third-party SaaS dependency should be treated like a component for assurance purposes, with appropriate due diligence and product-level measures such as secure authentication, encryption, integrity protection, or controlled data flows.⁴⁴

This reasoning should not be extended to every infrastructure dependency. In the Commission’s cellular-network example, the telecommunications network is a connectivity enabler rather than RDPS or an integrated component. The guidance therefore states that the manufacturer is not required to perform component-style due diligence on the network provider merely because the product relies on cellular connectivity.⁴⁵

Exclusions must be tied to the exact statutory provision

A product that satisfies the general Article 2(1) conditions can still be outside the CRA where Article 2 establishes a specific exclusion.

The Regulation excludes products with digital elements to which specified Union medical-device, in-vitro-diagnostic, and motor-vehicle legislation applies. It also excludes products certified in accordance with Regulation (EU) 2018/1139, equipment within the scope of the Marine Equipment Directive, qualifying identical spare parts, products developed or modified exclusively for national-security or defence purposes, and products specifically designed to process classified information. Commission Delegated Regulation (EU) 2025/1535 additionally excludes products with digital elements falling within the scope of Regulation (EU) No 168/2013 on two- or three-wheel vehicles and quadricycles, except L1e-category vehicles designed to be pedalled.⁴⁶⁴⁷

Dual-use products are not excluded merely because they also have defence applications. The national-security and defence exclusion applies only where the product was developed or modified exclusively for those purposes; the separate exclusion for products specifically designed to process classified information remains independently applicable.⁴⁸

Article 2(5) creates a different mechanism. Where another Union rule addresses all or some of the cybersecurity risks covered by Annex I, application of the CRA may be limited or excluded by delegated act where the limitation or exclusion is consistent with the overall regulatory framework and the sectoral rules achieve the same or a higher level of protection. The mere existence of another regulatory regime does not itself activate that mechanism.⁴⁹

The spare-part exclusion is similarly narrow. Article 2(6) concerns spare parts made available to replace identical components and manufactured according to the same specifications. The Commission guidance explains that functional compatibility alone is not enough. A replacement that changes security-relevant characteristics can fail the identity test even where it performs the same commercial function.⁵⁰

Scope conclusions should therefore be recorded against the actual product and architecture rather than against a commercial label such as software, platform, cloud service, system, solution, or spare part. The final scope record should establish what is supplied, when and how it is made available on the Union market, which hardware and software belong to the product, which remote software qualifies as RDPS, which systems remain external dependencies, how the product exchanges digital data, and which exact provision supports any claimed exclusion or limitation.

The legal roles: manufacturer, importer, distributor, integrator, and user

The CRA assigns obligations according to the legal entity’s conduct in relation to a particular product with digital elements, not according to commercial descriptions such as vendor, reseller, system integrator, solution provider, or cloud provider. The same undertaking can therefore occupy different CRA roles for different products or transactions.

Article 3 defines an economic operator as a manufacturer, authorised representative, importer, distributor, or another natural or legal person subject to CRA obligations concerning the manufacture of products with digital elements or their making available on the market.⁵¹

Role allocation matters because the duties are not interchangeable:

• the manufacturer establishes and maintains the conformity of the product and the vulnerability-handling processes associated with it;
• the authorised representative performs only tasks covered by a written mandate and permitted to be delegated;
• the importer controls the first Union-market placement of a product bearing the name or trademark of a person established outside the Union;
• the distributor controls subsequent making available of a product without affecting its properties; and
• an integrator or customer has no autonomous statutory status merely because it is called an integrator or user—the legal role follows from the activity actually performed.

The same product can therefore involve several economic operators simultaneously, while the same company can move between roles as its conduct changes.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    ACTOR([Organisation]):::entity
    PRODUCT[Defined product<br/>with digital elements]:::product

    OWN{Develops or manufactures,<br/>or has the product designed,<br/>developed or manufactured,<br/>and markets it under its<br/>own name or trademark?}:::test

    IMPORT{Union-established actor first placing<br/>on the Union market a product bearing<br/>the name or trademark of a person<br/>established outside the Union?}:::test

    IMP21{Article 21 trigger?<br/>Places under own name or trademark<br/>or substantially modifies<br/>the already placed product?}:::test

    DISTRIBUTE{Makes an already placed product<br/>available on the Union market<br/>without affecting its properties?}:::test

    DIST21{Article 21 trigger?<br/>Places under own name or trademark<br/>or substantially modifies<br/>the already placed product?}:::test

    MODIFY{Other person substantially modifies<br/>an already placed product and<br/>makes the modified product<br/>available on the market?}:::test

    INTEGRATE{Combines components into<br/>a new product and markets<br/>that new product under its<br/>own name or trademark?}:::test

    MFR([Manufacturer]):::entity
    IMPORTER([Importer]):::entity
    DISTRIBUTOR([Distributor]):::entity
    MODMFR([Manufacturer under Article 22<br/>for the affected part or,<br/>where cybersecurity of the whole<br/>product is affected, the whole product]):::entity
    INTMFR([Manufacturer of the<br/>new integrated product]):::entity
    USER([Customer or user]):::entity

    ACTOR --> PRODUCT
    PRODUCT --> OWN

    OWN -- Yes --> MFR
    OWN -- No --> IMPORT

    IMPORT -- Yes --> IMP21
    IMP21 -- Yes --> MFR
    IMP21 -- No --> IMPORTER

    IMPORT -- No --> DISTRIBUTE
    DISTRIBUTE -- Yes --> DIST21
    DIST21 -- Yes --> MFR
    DIST21 -- No --> DISTRIBUTOR

    DISTRIBUTE -- No --> MODIFY
    MODIFY -- Yes --> MODMFR
    MODIFY -- No --> INTEGRATE

    INTEGRATE -- Yes --> INTMFR
    INTEGRATE -- No --> USER

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;

Figure 4: CRA roles follow the actor’s conduct toward a defined product. Importers and distributors can become manufacturers under Article 21, while other persons can become manufacturers under Article 22 following substantial modification.

The decision logic in Figure 4 is deliberately product-specific. Corporate structure, contracting language, or a generic supplier classification cannot replace the statutory analysis.

The manufacturer is defined by development responsibility and market identity

A manufacturer is a natural or legal person that develops or manufactures products with digital elements, or has them designed, developed, or manufactured, and markets them under its own name or trademark, whether for payment, monetisation, or free of charge.⁵²

Physical fabrication is therefore not the decisive criterion. A company can be the manufacturer even where:

• a contract developer writes the software;
• an electronics manufacturing service assembles the hardware;
• third parties manufacture significant components;
• development work is distributed across several group companies; or
• contractors implement architecture and specifications controlled by the company.

The manufacturer is the actor that combines responsibility for development or manufacture with the market identity under which the product is supplied.

Outsourcing does not transfer that statutory responsibility. Engineering, manufacturing, testing, vulnerability analysis, hosting, conformity-assessment support, update infrastructure, and other activities can be performed by contractors, but the manufacturer remains responsible for the obligations the CRA assigns to it.

Those obligations include, among others, ensuring conformity with Annex I, undertaking and documenting the cybersecurity risk assessment, exercising due diligence when integrating third-party components, maintaining vulnerability-handling processes, determining the support period, preparing technical documentation, following the applicable conformity-assessment procedure, issuing the EU declaration of conformity, affixing CE marking, operating corrective processes, and meeting the Article 14 reporting duties.⁵³

The practical implication is that a manufacturer cannot cure an incomplete product-security system merely by assigning contractual responsibility to a software house, component vendor, test laboratory, cloud operator, or other supplier.

An authorised representative performs delegated tasks but does not replace the manufacturer

A manufacturer may appoint an authorised representative established in the Union through a written mandate.⁵⁴

The CRA expressly prevents several central manufacturer obligations from forming part of that mandate. Article 18 excludes the obligations in Article 13(1)–(11), Article 13(12), first subparagraph, and Article 13(14). The manufacturer therefore cannot transfer through the authorised-representative mandate the substantive responsibility for product cybersecurity, cybersecurity risk assessment, component due diligence, vulnerability handling, support-period determination, preparation of technical documentation, or procedures intended to maintain conformity across a product series.

The authorised representative must perform the tasks specified in the mandate. At minimum, that mandate must permit it to:

• keep the EU declaration of conformity and technical documentation at the disposal of market-surveillance authorities for at least ten years after placement on the market or for the support period, whichever is longer;
• provide, following a reasoned request, the information and documentation necessary to demonstrate conformity; and
• cooperate with market-surveillance authorities on measures taken to eliminate risks posed by products covered by the mandate.

The authorised representative is therefore an authority-facing legal interface for specified tasks, not an alternative manufacturer.

The importer is a statutory Union-market gatekeeper

An importer is a natural or legal person established in the Union that places on the market a product with digital elements bearing the name or trademark of a natural or legal person established outside the Union.⁵⁵

Article 19 does not require the importer to reproduce the manufacturer’s development process or perform a second cybersecurity risk assessment. It does, however, impose a substantive pre-market verification duty.

Before placing the product on the market, the importer must ensure that:

• the appropriate Article 32 conformity-assessment procedure has been carried out by the manufacturer;
• the manufacturer has drawn up the technical documentation;
• the product bears CE marking;
• the product is accompanied by the EU declaration of conformity;
• the Annex II information and instructions are provided in an appropriate language; and
• the manufacturer has fulfilled the specified product-identification, manufacturer-identification, and support-period disclosure requirements.

For those purposes, the importer must be able to provide the documents necessary to prove fulfilment of its Article 19 obligations.⁵⁶

The importer must also identify itself on the product, packaging, or accompanying documentation as required by Article 19(4).

If the importer considers or has reason to believe that either the product or the manufacturer’s processes do not conform to the CRA, it must not place the product on the market until conformity is restored. If the product presents a significant cybersecurity risk, the importer must inform the manufacturer and the relevant market-surveillance authorities.

The importer’s duties continue after placement. Where it knows or has reason to believe that a product it placed on the market is non-conforming, it must immediately take the corrective measures necessary to bring it into conformity or, where appropriate, withdraw or recall it. When it becomes aware of a vulnerability, it must inform the manufacturer without undue delay.

The importer’s document-retention duty must be stated precisely. Article 19(6) requires the importer, for at least ten years after the product is placed on the market or for the support period, whichever is longer, to:

• keep a copy of the EU declaration of conformity at the disposal of market-surveillance authorities; and
• ensure that the technical documentation can be made available to those authorities on request.⁵⁷

The CRA does not state that the importer must itself retain the manufacturer’s complete technical documentation for that entire period.

If the manufacturer ceases operations and can no longer comply with the CRA, the importer must inform the relevant market-surveillance authorities and, using available means and to the extent possible, users of the products concerned.

The distributor controls subsequent making available on the market

A distributor is a natural or legal person in the supply chain, other than the manufacturer or importer, that makes a product with digital elements available on the Union market without affecting its properties.⁵⁸

That final qualification distinguishes distribution from activities that can require a different role analysis.

When making a product available, the distributor must act with due care. Before supply, Article 20 requires it to verify that:

• the product bears CE marking;
• the manufacturer has complied with the specified product-identification, manufacturer-identification, user-information, support-period, and declaration obligations;
• the importer has provided its required identification and contact information where applicable; and
• the necessary documents have been provided to the distributor.

The distributor does not have to perform the manufacturer’s conformity assessment again. It does, however, have to respond to information indicating non-conformity.

Where it considers or has reason to believe, on the basis of information in its possession, that the product or the manufacturer’s processes do not comply with the essential cybersecurity requirements in Annex I, it must not make the product available until conformity is restored.

If a product already supplied is found to be non-conforming, the distributor must make sure that the necessary corrective action, withdrawal, or recall is undertaken. It must also inform the manufacturer without undue delay when it becomes aware of a vulnerability and cooperate with market-surveillance authorities.⁵⁹

A distributor that becomes aware that the manufacturer has ceased operations and can no longer comply with the CRA must also inform the relevant authorities without undue delay and, by available means and to the extent possible, the affected users.

Importers and distributors can become manufacturers

A CRA role is not permanently fixed by an organisation’s original place in the supply chain.

Under Article 21, an importer or distributor is considered a manufacturer and becomes subject to Articles 13 and 14 where it:

• places a product with digital elements on the market under its own name or trademark; or
• carries out a substantial modification of a product already placed on the market.⁶⁰

Private labelling can therefore have regulatory consequences beyond branding. Where an importer or distributor becomes the market-facing manufacturer under Article 21, it cannot rely on its former intermediary role to avoid the manufacturer’s obligations.

The second path—substantial modification—depends on the statutory modification test and is developed later in the article. The role consequence is already clear: a supply-chain intermediary can become the manufacturer because of what it does to, or how it places, the product on the market.

System integrator is a commercial description, not an autonomous CRA role

The CRA does not define system integrator as a separate economic-operator category. The Commission’s 2026 guidance instead requires the legal role to be derived from the integration activity.⁶¹

An organisation described commercially as a system integrator can therefore be:

• a customer or user installing products for its own operation;
• a distributor supplying unchanged products already placed on the Union market;
• an importer first placing products bearing a non-Union manufacturer’s name or trademark on the Union market;
• the manufacturer of a new integrated product;
• an importer or distributor that becomes a manufacturer under Article 21; or
• another person that becomes a manufacturer following substantial modification under Article 22.

The Commission guidance draws an important distinction between integration into a new product and substantial modification of an existing product.

Where an organisation combines components into a new product with digital elements and markets that new product under its own name or trademark, the relevant CRA object is the newly created product. The integrator is its manufacturer. This remains true even where many of the integrated components were already separately placed on the market and already carried their own conformity evidence.⁶²

Upstream conformity evidence can facilitate the final manufacturer’s work, but it does not establish conformity of the resulting integration. The final manufacturer’s risk assessment must address the complete product, including how component privileges, interfaces, data flows, dependencies, update mechanisms, and interactions affect its cybersecurity.

Integrator activity	Likely CRA position
Acquires and operates products solely for its own use	Customer or user, absent a separate making-available activity
Supplies unchanged products already placed on the Union market	Distributor
First places a product bearing the name or trademark of a person established outside the Union on the Union market	Importer
Combines components into a new product and markets that product under its own name or trademark	Manufacturer of the new product
Places an existing product on the market under its own name or trademark	Manufacturer under Article 21 where the statutory conditions are met
Substantially modifies an already placed product as importer or distributor	Manufacturer under Article 21
Substantially modifies an already placed product as another person and makes it available on the market	Manufacturer under Article 22
Repairs, maintains, configures, or changes a product without substantial modification	Modification alone does not create manufacturer status; the surrounding market activity must still be analysed

Table 1: CRA role consequences for common system-integrator activities.

The distinction in the table is temporal as well as technical. Integration begins with components and results in a newly marketed product. Substantial modification begins with a product that has already been placed on the market.

Article 22 can allocate responsibility to the modified part or the complete product

Article 22 addresses substantial modifications carried out by a natural or legal person other than the manufacturer, importer, or distributor.

Where that person substantially modifies a product already placed on the market and makes the modified product available, it is considered a manufacturer for CRA purposes.⁶³

The scope of that manufacturer’s resulting Articles 13 and 14 obligations depends on the reach of the modification:

• where the substantial modification affects a defined part of the product, the obligations apply to that affected part; or
• where the substantial modification has an impact on the cybersecurity of the product as a whole, the obligations apply to the entire product.⁶⁴

The statutory formulation is therefore about the cybersecurity impact of the change, not merely the physical size of the modified component or the number of lines of software changed.

Detailed determination of what constitutes a substantial modification is reserved for the later modification analysis.

Customers and users do not become economic operators merely through use

A customer does not become an economic operator merely by purchasing, configuring, deploying, or operating a product.

The CRA nevertheless incorporates user context into manufacturer obligations. Intended purpose, reasonably foreseeable use, conditions of use, operational environment, and assets to be protected influence the cybersecurity risk assessment. Manufacturers must also provide user information and instructions, support-period information, security-update information, and vulnerability contact information.

A user can acquire a different CRA role if its subsequent conduct satisfies one of the statutory definitions. For example, an organisation that acquires components for its own infrastructure is in a different position from an organisation that combines those components into a new product and makes that product available on the market.

Transfers within corporate groups, bespoke projects, outsourcing arrangements, and customer-specific deployments therefore require fact-specific analysis. The decisive question is whether a distinct legal entity is engaging in manufacture, placing on the market, making available, rebranding, or substantial modification—not whether the parties belong to the same corporate group or describe the activity internally as integration.

Roles should be mapped per legal entity, product, and market activity

The resulting allocation can be summarised as follows.

Role	What establishes the role	Principal CRA function
Manufacturer	Develops or manufactures, or has a product designed, developed, or manufactured, and markets it under its own name or trademark	Establish and maintain conformity of the product and manufacturer processes
Authorised representative	Written mandate from the manufacturer	Perform specified delegable tasks and act as an authority-facing interface
Importer	Union-established actor placing on the market a product bearing the name or trademark of a person established outside the Union	Operate the statutory pre-market import gate and maintain required post-market cooperation
Distributor	Makes an already placed product available without affecting its properties	Exercise due care, verify specified markings and documentation, and respond to known problems
Integrator	No autonomous CRA category	Determine whether the actual activity creates user, distributor, importer, manufacturer, or modifier status
Customer or user	Acquires or operates the product without itself engaging in a regulated market activity	No economic-operator status from use alone

Table 2: CRA role allocation according to conduct toward the product.

The practical rule is therefore:

Assign the CRA role separately for each legal entity, defined product, and market activity.

Contracts can allocate engineering tasks, warranties, evidence delivery, vulnerability cooperation, remediation duties, and indemnities. They cannot override the statutory role created by the underlying conduct.

For a complex supply chain, the controlling questions are consequently: what is the product; who develops or has it developed; under whose name or trademark is it marketed; who first places it on the Union market; who subsequently makes it available; and whether anyone creates a new product or substantially modifies an existing one.

The security baseline: risk assessment, secure design, defaults, and updates

The CRA does not prescribe one identical technical control catalogue for every product with digital elements. It combines a universal risk-based objective with a set of more specific product and vulnerability-handling requirements whose applicability and implementation must be determined through the manufacturer’s cybersecurity risk assessment.⁶⁵

The distinction inside Annex I is important.

Part I, point (1) requires every product with digital elements to be designed, developed, and produced so that it ensures an appropriate level of cybersecurity based on the risks.

Part I, point (2) then lists more specific product-security requirements that apply on the basis of the Article 13 cybersecurity risk assessment and where applicable.

Part II imposes vulnerability-handling requirements on manufacturers, including vulnerability and component documentation, remediation, testing, coordinated disclosure, secure update distribution, and security advisories.

Risk-based implementation therefore does not mean that the manufacturer may choose freely which CRA obligations to observe. The manufacturer must perform the risk assessment, determine applicability, implement the applicable requirements, and clearly justify in the technical documentation any essential cybersecurity requirement considered not applicable.⁶⁶

The cybersecurity risk assessment is a lifecycle engineering input

Article 13 requires the manufacturer to undertake an assessment of the cybersecurity risks associated with the product and to take the outcome into account during:

• planning;
• design;
• development;
• production;
• delivery; and
• maintenance.

The objective is to minimise cybersecurity risks, prevent incidents, and minimise their effects, including effects on the health and safety of users.⁶⁷

The risk assessment must be documented and updated as appropriate during the support period. At minimum, it must analyse risks in light of:

• intended purpose;
• reasonably foreseeable use;
• conditions of use;
• the operational environment;
• assets to be protected; and
• the length of time the product is expected to be in use.

It must also state whether and how the individual requirements in Annex I, Part I, point (2) apply, how those requirements are implemented, how the general risk-based requirement in Part I, point (1) is applied, and how the vulnerability-handling requirements in Part II are addressed.

The assessment forms part of the Article 31 technical documentation before market placement. The CRA does not mandate a particular cybersecurity risk-assessment methodology. The manufacturer may select and structure an appropriate methodology, but it must support documentation of how relevant risks were identified, evaluated, and treated and allow market-surveillance authorities to verify that analysis. A single assessment may support several applicable Union acts, but compliance with each individual act must remain demonstrable.⁶⁸

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    MFR([Manufacturer]):::entity
    CONTEXT[Purpose, foreseeable use<br/>environment, assets<br/>expected use and dependencies]:::product
    RISK[Cybersecurity risk assessment]:::product
    REQ[Applicable Annex I<br/>requirements]:::product
    BUILD[Design, development<br/>production and verification]:::product
    MARKET[Market placement]:::product
    SUPPORT[Support, vulnerability handling<br/>security updates and monitoring]:::product
    CHANGE{New vulnerability, incident<br/>component, threat or<br/>product change?}:::test
    CORRECT{{Reassess, correct<br/>withdraw or recall<br/>as appropriate}}:::enforcement

    MFR --> CONTEXT
    CONTEXT --> RISK
    RISK --> REQ
    REQ --> BUILD
    BUILD --> MARKET
    MARKET --> SUPPORT
    SUPPORT --> CHANGE
    CHANGE -- Relevant to risk or conformity --> RISK
    CHANGE -- Non-conformity requiring action --> CORRECT
    CHANGE -- No relevant effect --> SUPPORT

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef enforcement fill:#f8dddd,stroke:#9b2f2f,stroke-width:2px,color:#501717;

Figure 5: The CRA risk assessment connects product context to applicable cybersecurity requirements and is updated when lifecycle information changes the security case.

The feedback loop in Figure 5 is not limited to formal product modifications. Article 13(7) requires manufacturers to systematically document relevant cybersecurity aspects—including vulnerabilities of which they become aware and relevant information received from third parties—in a manner proportionate to the nature and cybersecurity risks of the product, and to update the risk assessment where applicable.

The risk assessment is therefore not merely a pre-market document. It is part of the evidence system used to preserve the validity of the product-security decisions during support.

Annex I separates product properties from vulnerability-handling processes

Annex I, Part I governs cybersecurity properties of the product.

Its general requirement is an appropriate level of cybersecurity based on risk. On the basis of the cybersecurity risk assessment and where applicable, the product must also:

• be made available without known exploitable vulnerabilities;
• be made available with a secure-by-default configuration, subject to the specific tailor-made-product exception;
• allow vulnerabilities to be addressed through security updates;
• protect against unauthorised access;
• protect confidentiality;
• protect integrity;
• implement data minimisation;
• protect availability of essential and basic functions;
• minimise harmful effects on the availability of services provided by other devices or networks;
• limit attack surfaces, including external interfaces;
• reduce incident impact through exploitation-mitigation techniques;
• provide security-relevant recording and monitoring with a user opt-out mechanism; and
• permit secure and easy permanent removal of user data and settings and secure transfer where applicable.⁶⁹

Annex I, Part II governs the manufacturer’s vulnerability-handling processes. Manufacturers must:

• identify and document vulnerabilities and components;
• maintain an SBOM in a commonly used, machine-readable format covering at least top-level dependencies;
• address and remediate vulnerabilities without delay in relation to the risks posed;
• apply effective and regular security tests and reviews;
• disclose information about fixed vulnerabilities, subject to the Regulation’s narrowly framed possibility of delayed public disclosure;
• operate a coordinated vulnerability-disclosure policy;
• provide mechanisms and a contact address for vulnerability reporting;
• securely distribute updates; and
• disseminate security updates without delay and, subject to the tailor-made business-product exception, free of charge, together with relevant advisory information.⁷⁰

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
    RISK[Cybersecurity risk assessment]:::product

    PARTI[Annex I Part I<br/>product properties]:::product
    PARTII[Annex I Part II<br/>manufacturer processes]:::product

    BASE[Appropriate cybersecurity<br/>based on risks]:::product
    PROTECT[Secure defaults, access control<br/>confidentiality, integrity<br/>availability and minimisation]:::product
    REDUCE[Attack-surface limitation<br/>exploitation mitigation<br/>monitoring and data removal]:::product
    UPDATECAP[Security-update capability]:::product

    INVENTORY[Components, vulnerabilities<br/>and SBOM]:::product
    TEST[Regular testing<br/>and security review]:::product
    REMEDIATE[Remediation, disclosure<br/>and advisories]:::product
    DISTRIBUTE[Secure update<br/>distribution]:::product

    EVIDENCE[Technical documentation<br/>conformity and support evidence]:::product

    RISK --> PARTI
    RISK --> PARTII

    PARTI --> BASE
    PARTI --> PROTECT
    PARTI --> REDUCE
    PARTI --> UPDATECAP

    PARTII --> INVENTORY
    PARTII --> TEST
    PARTII --> REMEDIATE
    PARTII --> DISTRIBUTE

    BASE --> EVIDENCE
    PROTECT --> EVIDENCE
    REDUCE --> EVIDENCE
    UPDATECAP --> EVIDENCE
    INVENTORY --> EVIDENCE
    TEST --> EVIDENCE
    REMEDIATE --> EVIDENCE
    DISTRIBUTE --> EVIDENCE

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;

Figure 6: Annex I combines risk-based product-security properties with continuing manufacturer vulnerability-handling processes.

The two branches in Figure 6 are different but interdependent. A product architecture that cannot be updated securely undermines the vulnerability-remediation process; a strong vulnerability-management process cannot compensate for a product whose applicable Part I requirements were not implemented.

Secure by default is a requirement on the product as supplied

Annex I requires, where applicable, a product to be made available with a secure-by-default configuration and to include the possibility of resetting the product to its original state.⁷¹

The Regulation establishes one explicit alternative: the manufacturer and a business user may agree otherwise in relation to a tailor-made product with digital elements.

That exception is narrow. FAQ 4.2.5 describes a tailor-made product as one fitted to a particular purpose for a particular business user where the manufacturer and user have explicitly agreed to different contractual terms. Minor customisation of a product sold to multiple customers—including configuration choices, plugins, or APIs—does not by itself make that product tailor-made. The manufacturer should preserve evidence supporting the classification in its technical documentation. The exception therefore cannot be generalised into a right to ship ordinary products insecurely on the assumption that the customer will harden them later.⁷²

The precise technical measures needed to establish a secure default depend on the product and its risk assessment. Depending on the architecture, engineering evidence may therefore need to show, for example, that:

• unnecessary externally exposed services are not enabled by default;
• authentication and access-control mechanisms start in a secure state;
• predictable or shared credentials do not create an avoidable initial exposure;
• debugging or maintenance capabilities are appropriately restricted;
• insecure compatibility modes are not enabled without a justified reason;
• security-relevant monitoring defaults are consistent with the applicable Annex I requirements; and
• the update configuration satisfies the separate requirements for automatic security updating where those requirements are applicable.

These examples are implementation patterns, not a separate control catalogue written into the CRA. The legal test remains whether the delivered configuration satisfies the applicable Annex I requirements in light of the documented risk assessment.

Known exploitable vulnerability is narrower than known vulnerability

Annex I does not require a manufacturer to prove the absence of every defect or every theoretically exploitable weakness.

The CRA defines an exploitable vulnerability as a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions.⁷³

Annex I, Part I, point (2)(a) then requires, where applicable, products to be made available on the market without known exploitable vulnerabilities.

The relevant release question is therefore not merely whether a scanner, researcher, supplier, or vulnerability database has identified a weakness. The manufacturer must determine whether a known weakness constitutes an exploitable vulnerability in the practical operational conditions relevant to the product.

A defensible assessment can consider matters such as:

• affected product versions and configurations;
• whether the vulnerable code or function is present and reachable;
• required privileges or attacker position;
• operational preconditions;
• available mitigations;
• consequences for confidentiality, integrity, availability, or other protected functions; and
• whether a corrective security update or other mitigation must precede market placement.

Those are engineering factors used to support the statutory determination, not additional legal criteria inserted into the definition.

This release requirement must also be distinguished from the later Article 14 concept of an actively exploited vulnerability, which requires reliable evidence of malicious exploitation without the system owner’s permission. A vulnerability can therefore be exploitable for Annex I purposes without yet being actively exploited for Article 14 reporting purposes.

Security-update capability is part of the product architecture

Annex I requires products, where applicable, to ensure that vulnerabilities can be addressed through security updates.

Where automatic security updates are applicable, the Regulation goes further. Those updates are to be:

• installed within an appropriate timeframe;
• enabled as a default setting;
• accompanied by a clear and easy-to-use opt-out mechanism;
• notified to users; and
• capable of being temporarily postponed.⁷⁴

Part II separately requires mechanisms for the secure distribution of updates so that vulnerabilities can be fixed or mitigated in a timely manner and, where applicable, automatically.

The CRA does not prescribe a single update architecture. Depending on the product and threat model, a defensible implementation can require controls such as:

• cryptographically authenticated update packages;
• integrity-protected update metadata;
• controlled signing-key management;
• anti-rollback or version-control mechanisms;
• compatibility and prerequisite validation;
• atomic or failure-safe installation;
• recovery from interrupted or failed updates;
• staged deployment where appropriate; and
• monitoring sufficient to determine whether remediation has been deployed successfully.

These are engineering means of demonstrating secure update capability rather than a statutory checklist. FAQ 4.3.3 states that the manufacturer is not responsible under the CRA merely because a user does not install an available security update where automatic updating is not applicable or the user exercises the available opt-out. This does not reduce the manufacturer’s own duties concerning update capability, secure and timely dissemination, user information, vulnerability handling, and continuing conformity.⁷⁵

Vulnerabilities must be remediated; security updates must be distributed and communicated

Part II requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed to the product, including by providing security updates.⁷⁶

Addressing and remediating a vulnerability does not mean that every discovered vulnerability requires a dedicated patch. FAQ 4.3.1 treats the remedy as risk-based: depending on the vulnerability and its operational conditions, the response may include an immediate patch, a workaround followed by an update, revised user instructions, configuration guidance disabling an affected function, or documented treatment where the vulnerability is not exploitable in the product. The manufacturer must still act without delay in relation to the risk and update the risk assessment and technical documentation where appropriate. Conversely, where a very significant vulnerability cannot be adequately remediated and the product cannot be restored to conformity, Article 13(21) may require withdrawal or recall, as appropriate.⁷⁷

Where technically feasible, new security updates must be supplied separately from functionality updates. Once security updates are available to address identified security issues, they must be disseminated:

• without delay;
• free of charge, unless the manufacturer and a business user have agreed otherwise for a tailor-made product; and
• with advisory messages providing relevant information, including actions users may need to take.

The vulnerability-handling obligation is therefore broader than producing a patch. The manufacturer needs a functioning path from vulnerability intake to analysis, remediation, secure distribution, advisory communication, and maintenance of the update artefact.

Fixed-vulnerability disclosure is part of the vulnerability-handling process

After a security update has been made available, Annex I requires the manufacturer to share and publicly disclose information about fixed vulnerabilities.

That information includes:

• a description of the vulnerability;
• information enabling users to identify affected products;
• the impact and severity of the vulnerability; and
• clear information enabling users to remediate it.

The CRA permits delayed public disclosure in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits, allowing users an opportunity to apply the patch before publication.⁷⁸

This obligation should be distinguished from Article 14 reporting to CSIRTs and ENISA. Public disclosure of a fixed vulnerability, mandatory reporting of an actively exploited vulnerability, user notification, and coordinated vulnerability disclosure are related mechanisms but have different triggers and purposes.

Support periods are based on expected use, not an automatic five-year default

The support period is the period during which the manufacturer must ensure that vulnerabilities in the product are handled effectively in accordance with Annex I, Part II.⁷⁹

Article 13(8) requires the manufacturer to determine that period so that it reflects the length of time the product is expected to be used.

The assessment must take into account, in particular:

• reasonable user expectations;
• the nature of the product;
• its intended purpose; and
• relevant Union law determining product lifetime.

The manufacturer may also take into account:

• support periods of products with similar functionality;
• availability of the operating environment;
• support periods of integrated third-party components providing core functions; and
• relevant ADCO and Commission guidance.

Those considerations must be applied proportionately.

The statutory baseline is that the support period must be at least five years. A shorter period is permitted only where the product is expected to be used for less than five years, in which case the support period must correspond to that expected use time.⁸⁰

Five years is therefore a minimum rule with an expected-use exception, not a universal target or safe harbour. A product reasonably expected to remain in use materially longer than five years requires the manufacturer to determine a support period reflecting that longer expected use.

This is particularly relevant to industrial, infrastructure, and embedded products with long operational lifetimes.

Component support is an input to, not a substitute for, the product support decision

Article 13 allows the manufacturer to consider the support periods of integrated third-party components that provide core functions when determining the final product’s support period.

That does not mean that an upstream component’s shorter support commitment automatically determines the support period of the final product.

For the final-product manufacturer, a mismatch between the expected product lifetime and the support horizon of a security-critical dependency is a lifecycle risk that can require measures such as replacement planning, maintained forks, alternative components, architectural isolation, contractual support, or other mitigation.

The detailed due-diligence consequences for components are developed in the later components section.

Security-update availability can extend beyond the vulnerability-handling support period

Article 13(9) contains an obligation that is easy to misread.

Every security update made available to users during the support period must remain available after issuance for:

• at least ten years; or
• the remainder of the support period,

whichever is longer.⁸¹

This is an availability obligation for an update already issued. It does not, by itself, extend the vulnerability-handling support period by another ten years or require the manufacturer to continue developing new security updates throughout that additional availability period.

For example, if a security update is issued during the fourth year of a five-year support period, the update must ordinarily remain available for ten years from issuance even though the manufacturer’s Article 13(8) vulnerability-handling support period ends earlier.

The manufacturer must also specify the support-period end date—including at least the month and year—clearly and understandably at the time of purchase. Where technically feasible, the product must notify users when it reaches the end of the support period.

Expiry of support does not automatically prohibit downstream sale of units already placed on the market

FAQ 4.5.3 distinguishes units already placed on the market from additional units placed later. Expiry of the support period does not, by itself, prevent a distributor from continuing to make available units that were already placed on the market. Additional units of the same model that are first placed on the market later must be assigned a support period in accordance with Article 13(8). Manufacturers and distributors should therefore retain unit- or batch-level evidence of placement dates; a model-level end-of-support date alone does not establish which units belong to which population.⁸²

Software support can, under narrow conditions, focus on the latest substantially modified version

Article 13(10) creates a specific rule for software products where the manufacturer has placed subsequent substantially modified versions on the market.

In that situation, the manufacturer may comply with the Annex I Part II remediation requirement only for the version most recently placed on the market if:

• users of previously placed versions have access to the latest version free of charge; and
• those users do not incur additional costs to adjust the hardware and software environment in which they used the original version.⁸³

This is a constrained lifecycle mechanism rather than a general permission to abandon old versions whenever a new release exists. Its conditions should therefore be checked explicitly before relying on the latest-version approach.

Historical software archives are permitted, but unsupported status must be clear

Article 13 also permits manufacturers to maintain public software archives that improve access to historical versions.

Where they do so, users must be informed clearly and accessibly about the risks associated with using unsupported software.⁸⁴

The distinction is useful operationally:

• continuing to make an historical artefact downloadable does not necessarily mean that the version remains supported; but
• the manufacturer must not present unsupported historical software in a manner that obscures its security status.

Taken together, the CRA security baseline is therefore not a one-time secure-development checklist. It is a traceable relationship among risk assessment, product architecture, applicable Annex I requirements, verification, vulnerability handling, security-update capability, support-period commitments, and continuing reassessment. A product can satisfy that baseline only where those elements remain aligned with the product that is actually placed on the market and supported.

Classification and conformity assessment

The CRA separates substantive cybersecurity obligations from the procedure used to demonstrate conformity. Every manufacturer must assess the cybersecurity risks of the product and ensure that the applicable essential cybersecurity requirements in Annex I are satisfied. Classification does not determine how secure the product must be; it determines which conformity-assessment procedures are legally available for demonstrating that the product and the manufacturer processes meet those requirements.⁸⁵

Articles 7 and 8 classify products according to their core functionality. A product whose core functionality corresponds to a category in Annex III is an important product with digital elements, divided into class I and class II. A product whose core functionality corresponds to a category in Annex IV is a critical product with digital elements. Products whose core functionality does not correspond to either annex are described by the Commission guidance as belonging to the default category; that expression is useful shorthand but is not a term defined by the CRA.⁸⁶

Commission Implementing Regulation (EU) 2025/2392 provides the technical descriptions of the categories listed in Annexes III and IV.⁸⁷ Classification should therefore be based on the actual technical capabilities and intended purpose of the product, read against those descriptions, rather than on marketing labels such as security platform, gateway, endpoint suite, or network appliance.

Core functionality controls classification

The CRA itself does not define core functionality. The Commission guidance interprets it as the product’s main features and technical capabilities without which the product would not be able to meet its intended purpose.⁸⁸

That assessment is contextual. Relevant evidence includes:

• the manufacturer’s stated intended purpose;
• technical capabilities;
• instructions for use;
• promotional and sales material;
• statements made by the manufacturer;
• conditions of use; and
• technical documentation.

Classification therefore cannot be determined solely from one feature present in the code or hardware.

A product can incorporate functionality corresponding to an Annex III or Annex IV category without acquiring that classification if the functionality is ancillary to the product’s core functionality. A router that integrates firewall functionality, for example, does not become a class II firewall merely because a firewall component is included. The complete product must still be assessed for the cybersecurity risks introduced by that functionality, but its conformity-assessment category follows the core functionality of the product as a whole.⁸⁹

The same principle applies to software. The Commission guidance distinguishes a product that performs some SIEM-like operations from one whose main functionality actually corresponds to the technical description of a SIEM. Conversely, a broader security-orchestration product can have functionality that extends beyond a listed category while still having that listed functionality at its core. Functional similarity, terminology, or the presence of one security capability is therefore not enough: the product must be compared with the technical category description as a whole.⁹⁰

For conformity-classification purposes, the Commission guidance takes the position that the manufacturer should identify one core functionality for the product. The product can perform many other functions, but the classification analysis must establish which main functionality defines the intended purpose for the purposes of Articles 7, 8, and 32.⁹¹

That analysis must also remain internally consistent. A manufacturer should not describe a function as central in sales material and user documentation while treating the same function as merely ancillary in its CRA classification solely to obtain a less demanding conformity route.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    PRODUCT[Defined product with digital elements]:::product
    CORE[Identify core functionality<br/>from intended purpose, technical capabilities<br/>instructions, marketing and documentation]:::product
    CATEGORY{Which category matches<br/>the core functionality?}:::test

    DEFAULT[Default category<br/>outside Annexes III and IV]:::product
    CLASSI[Important<br/>class I]:::product
    CLASSII[Important<br/>class II]:::product
    CRITICAL[Critical]:::product

    A[Module A<br/>internal control]:::product
    C1TEST{"Article 32(2)<br/>conditions for Module A met?"}:::test
    BC[Modules B + C<br/>EU-type examination plus<br/>conformity to EU type]:::product
    H[Module H<br/>full quality assurance]:::product
    CERT[/Applicable European cybersecurity<br/>certification scheme/]:::overlay
    CRTCERT{"Article 8(1) certification<br/>requirement applicable?"}:::test

    RISK[Cybersecurity risk assessment<br/>of the complete product]:::product
    EXTRA[Ancillary functionality<br/>integrated components and risks]:::product

    PRODUCT --> CORE
    CORE --> CATEGORY

    CATEGORY -- Outside Annexes III and IV --> DEFAULT
    CATEGORY -- Annex III class I --> CLASSI
    CATEGORY -- Annex III class II --> CLASSII
    CATEGORY -- Annex IV --> CRITICAL

    DEFAULT --> A
    DEFAULT --> BC
    DEFAULT --> H
    DEFAULT --> CERT

    CLASSI --> C1TEST
    C1TEST -- Yes --> A
    C1TEST -- No --> BC
    C1TEST -- No --> H

    CLASSII --> BC
    CLASSII --> H
    CLASSII --> CERT

    CRITICAL --> CRTCERT
    CRTCERT -- Yes --> CERT
    CRTCERT -- No --> BC
    CRTCERT -- No --> H
    CRTCERT -- No --> CERT

    PRODUCT --> RISK
    EXTRA --> RISK

    RISK -. complete-product conformity .-> A
    RISK -. complete-product conformity .-> BC
    RISK -. complete-product conformity .-> H
    RISK -. complete-product conformity .-> CERT

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;

Figure 7: CRA classification follows the product’s core functionality, while conformity remains an assessment of the complete product and the relevant manufacturer processes.

The distinction in Figure 7 is fundamental:

Classification follows core functionality; conformity still concerns the complete product and the processes put in place by the manufacturer.

Ancillary functions that do not alter classification can still introduce risks that must be identified and addressed.

Separately supplied modules can become separately classified products

Product boundaries remain decisive.

A product can contain several internal modules that perform technically different functions. If those modules are not independently made available on the market, they are assessed as parts of the complete product. Their functionality and risks can affect the complete-product risk assessment without giving each internal module an independent CRA classification.

The result changes if a module is also supplied separately—for example through a separate purchase, licence, download, or subscription. In that case, the Commission guidance treats the separately supplied module as its own product with digital elements, requiring its own core-functionality and classification analysis.⁹²

The guidance illustrates this with a security suite composed of modules that can also be purchased independently. A separately supplied SIEM, intrusion-detection, or analytics module cannot rely only on the classification assigned to the broader suite. Each separately made-available product must be classified according to its own intended purpose and core functionality.

Classification determines the permitted conformity route

Article 32 provides four forms of conformity assessment:

1. Module A. Internal control;
2. Module B followed by Module C. EU-type examination followed by conformity to EU type based on internal production control;
3. Module H. Conformity based on full quality assurance; and
4. where available and applicable, a European cybersecurity certification scheme specified for CRA purposes under Article 27(9).⁹³

The category determines which of those routes can be used.

Classification	Conformity-assessment consequence
Default category	Module A is available; the manufacturer can instead choose B+C, H, or an available and applicable Article 27(9) certification route
Important class I	Module A is available where the Article 32(2) conditions concerning relevant harmonised standards, common specifications, or eligible certification are satisfied; otherwise B+C or H is required with regard to the requirements triggering Article 32(2)
Important class II	B+C, H, or, where available and applicable, an Article 27(9) European cybersecurity certification scheme at assurance level at least substantial
Critical	European cybersecurity certification is required where Article 8(1) and the relevant delegated act make it mandatory; otherwise the class II routes are available
Important class I or II FOSS under Article 32(5)	The Article 32(1) procedures, including module A, may be used if the Article 31 technical documentation is made available to the public when the product is placed on the market

Table 3: Relationship between CRA classification and conformity-assessment routes.

Where the CRA permits a choice of conformity-assessment procedure, a manufacturer may voluntarily use a procedure involving third-party assessment even where a less demanding route would otherwise be available. This does not displace a mandatory European cybersecurity certification requirement applicable under Article 8(1) and Article 32(4).

Important FOSS receives a specific conformity-route treatment

Article 32(5) creates a specific rule for manufacturers of products qualifying as free and open-source software that fall within Annex III.

For important class I or class II FOSS, the manufacturer can use one of the procedures in Article 32(1), including module A, provided that the Article 31 technical documentation is made available to the public when the product is placed on the market.⁹⁴

The effect is significant for class II FOSS because an equivalent proprietary class II product would ordinarily require third-party involvement.

The provision does not extend to Annex IV critical products. Nor does it answer whether a particular FOSS project is placed on the market, who is its manufacturer, or whether a legal person is instead an open-source software steward. Those questions depend on the distinct FOSS scope analysis developed in the next section.

Class I self-assessment depends on the coverage of core-functionality risks

Article 32(2) does not give all important class I manufacturers an unconditional right to use module A.

Where the manufacturer has not applied, or has applied only in part, the relevant harmonised standards, common specifications, or applicable European cybersecurity certification schemes at assurance level at least substantial, or where those instruments do not exist, the specified requirements must be assessed through B+C or H.⁹⁵

The Commission guidance clarifies when a harmonised standard can support use of internal control for a class I product. Two conditions are central:

1. the manufacturer must apply all applicable requirements of the relevant harmonised standard; and
2. the standard’s scope must cover at least all cybersecurity risks associated with the product’s core functionality.⁹⁶

The same interpretive logic applies, where relevant, to common specifications and European cybersecurity certification schemes.

The standard does not have to cover every ancillary function of the complete product. The manufacturer remains responsible for identifying and treating additional risks by other means.

The Commission illustrates this with antivirus software whose core functionality is malware detection, removal, or quarantine, but which also contains disk-cleaning and anti-tracking capabilities. If a relevant harmonised standard covers the cybersecurity risks associated with the antivirus core functionality, the manufacturer can still use internal control while separately identifying, treating, and documenting the risks created by those additional functions.

Likewise, a router that includes firewall functionality can remain classified according to its routing core functionality. The manufacturer may use a relevant standard covering the router’s core-functionality risks and separately apply appropriate measures—including, where useful, a firewall standard—to address the additional firewall risks.⁹⁷

The result avoids two opposite errors:

• classification inflation, where every incorporated security function determines the classification of the complete product; and
• risk omission, where functionality is ignored merely because it does not determine classification.

Module A is a conformity assessment performed under manufacturer responsibility

Under module A, conformity assessment takes place without mandatory notified-body participation.

That does not convert the CRA into a self-declaration unsupported by evidence. The manufacturer remains responsible for demonstrating that the product and relevant processes satisfy the applicable essential cybersecurity requirements.⁹⁸

Module A therefore still requires the manufacturer to:

• establish the applicable cybersecurity requirements;
• perform and document the cybersecurity risk assessment;
• implement appropriate security measures;
• prepare the technical documentation;
• carry out appropriate examinations and tests;
• control production and release;
• ensure conformity of products placed on the market;
• draw up the EU declaration of conformity; and
• affix CE marking.

Self-assessment describes the absence of mandatory third-party conformity assessment. It does not reduce the underlying substantive requirements or evidentiary burden.

Modules B and C separate type examination from continuing conformity to the type

Under module B, a notified body performs an EU-type examination of the technical design and development of the product and of the vulnerability-handling processes put in place by the manufacturer. It determines whether the product meets the essential cybersecurity requirements in Annex I, Part I, and whether the manufacturer’s vulnerability-handling processes meet Annex I, Part II. The assessment is based on the technical documentation, supporting evidence, examinations, and tests specified in Annex VIII.⁹⁹

Module B is followed by module C. Under module C, the manufacturer assumes responsibility for ensuring that the products subsequently produced or released remain in conformity with the approved EU type and the applicable essential cybersecurity requirements.

This distinction is particularly important for software. An EU-type examination applies to the assessed product design and its relevant state. The manufacturer cannot assume that every future version remains covered merely because the commercial product name is unchanged. Changes affecting the approved design, conformity, or assessment basis must be handled within the applicable module and change-control requirements.

Module H assesses a full quality-assurance system

Module H provides a different third-party conformity route.

Instead of relying on an EU-type examination followed by manufacturer-controlled conformity to type, module H requires an approved quality system covering the relevant design, development, production, final product inspection and testing, and vulnerability handling. The system must ensure conformity of the product with Annex I, Part I and of the manufacturer’s vulnerability-handling processes with Annex I, Part II, remain effective throughout the support period, and remain subject to notified-body surveillance. A notified body assesses the quality system and performs surveillance in accordance with Annex VIII.¹⁰⁰

For manufacturers with multiple related products or frequent software releases, this can create a more systematic conformity framework. It is not, however, a blanket approval of every future release. Products covered by the system must continue to satisfy the CRA, and changes affecting the approved quality system or the conformity case must be controlled appropriately.

Harmonised standards create bounded presumptions of conformity

The legal effect of a technical standard must be distinguished from its engineering usefulness.

Under Article 27(1), a product with digital elements and the relevant manufacturer processes that conform to a harmonised standard, or part of such a standard, whose reference has been published in the Official Journal of the European Union benefit from a presumption of conformity only with respect to the essential cybersecurity requirements covered by that standard or part.¹⁰¹

The same structure extends to:

• common specifications adopted by the Commission under Article 27, for the requirements they cover; and
• qualifying European cybersecurity certification schemes, to the extent specified and covered under Article 27(8) and (9).

A technical specification therefore does not acquire CRA presumption-of-conformity status merely because:

• it is widely adopted;
• it is an ISO or IEC standard;
• CEN, CENELEC, or ETSI has approved it;
• the manufacturer or supplier claims alignment with it; or
• it is expected eventually to become a harmonised standard.

For a harmonised standard, publication of the reference in the Official Journal is legally decisive.

Presumption of conformity does not replace complete-product risk assessment

A presumption of conformity is bounded by coverage.

The Commission guidance stresses that manufacturers remain responsible for assessing all cybersecurity risks associated with their products even where they rely on harmonised standards.¹⁰²

A cited standard can establish a presumption for requirements and risks within its scope. It does not establish that:

• every product function lies within that scope;
• every relevant risk has been considered;
• all applicable Annex I requirements have been addressed;
• additional components or interfaces introduce no new risks; or
• the product cannot be compromised.

The distinction between conformity-route eligibility and presumption-of-conformity coverage is therefore essential.

For an important class I product, a harmonised standard can cover all cybersecurity risks associated with the product’s core functionality and thereby permit module A under the Commission’s interpretation. The complete product can nevertheless contain additional functions that create risks outside the standard’s scope. Those additional risks must still be assessed, mitigated, and documented even though they do not force a different classification.

A manufacturer should therefore map each relied-upon standard or certification artefact to the precise:

• product or process scope;
• essential requirements covered;
• product state;
• technical assumptions; and
• residual requirements that still require independent evidence.

The EU declaration and CE marking conclude the conformity process

Once conformity has been demonstrated through the applicable procedure, the manufacturer draws up the EU declaration of conformity and assumes responsibility for compliance of the product with the CRA. The declaration must be kept up to date as appropriate.¹⁰³

Where the same product is subject to several Union acts requiring an EU declaration of conformity, a single declaration can cover those acts where the applicable legal conditions are satisfied.

The manufacturer then affixes CE marking. Under the CRA definition, CE marking indicates that the manufacturer considers the product with digital elements and the processes put in place by the manufacturer to conform to the essential cybersecurity requirements and other applicable Union harmonisation legislation requiring the marking.

CE marking is therefore the visible output of a conformity chain. It is not a warranty that:

• no unknown vulnerability exists;
• no future vulnerability will be discovered;
• the product cannot be exploited;
• the configuration used by a particular customer is secure; or
• future product changes remain automatically covered by the existing conformity evidence.

The defensible sequence is:

define the product → identify its core functionality → determine its CRA category → assess cybersecurity risks across the complete product → choose a legally permitted conformity route → generate evidence aligned with the assessed product → draw up the declaration → affix CE marking → preserve conformity as the product and its evidence evolve.

Classification determines the procedural route. It never narrows the manufacturer’s responsibility for conformity of the complete product.

Components, open source, integration, and substantial modification

The CRA makes the final-product manufacturer responsible for the cybersecurity of the product it places on the market even where important parts of that product originate upstream.

Article 13(5) therefore requires manufacturers to exercise due diligence when integrating components sourced from third parties, so that those components do not compromise the cybersecurity of the final product. The duty expressly extends to free and open-source software components that have not themselves been made available on the market in the course of a commercial activity.¹⁰⁴

This creates two related but distinct obligations:

• the manufacturer must assess the cybersecurity risks of the complete product under Article 13(2); and
• it must exercise component-specific due diligence under Article 13(5).

Upstream conformity evidence can reduce uncertainty. It does not transfer responsibility for the downstream integration. CRA conformity evidence or CE marking can be one component-due-diligence input, but it is not a prerequisite for integration. A manufacturer may integrate a component that does not bear CE marking—for example, a pre-CRA component, a component not separately placed on the market, or FOSS outside commercial activity—provided that it uses other risk-proportionate means to ensure that the component does not compromise the cybersecurity of the final product.¹⁰⁵

Component due diligence begins with the security requirement of the final product

Due diligence should not begin with the question Does the supplier have a certificate? It should begin with the cybersecurity properties that the final product requires from the component.

If a component provides cryptography, authentication, network communication, secure boot, storage, update verification, access control, or another security-relevant function, the manufacturer should identify the security assumptions placed on that component and obtain evidence proportionate to the associated risk.¹⁰⁶

Relevant due-diligence activities can include, as applicable:

• identifying the component, version, supplier, provenance, and configuration;
• examining relevant conformity information or CE marking where the component itself is a CRA-regulated product;
• reviewing security-update history and support commitments;
• checking publicly available vulnerability information;
• reviewing technical and security documentation;
• evaluating how the component is configured and invoked in the final product;
• performing additional security testing where justified by risk; and
• assessing whether the component’s lifecycle can support the final product’s obligations.

The appropriate depth is risk-dependent. A low-privilege formatting library and a privileged cryptographic or remote-management component do not create the same assurance problem.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    COMPONENT[Third-party component]:::product
    ID[Identity, version<br/>provenance and configuration]:::product
    NEED[Security properties required<br/>by the final product]:::product
    DUE[Risk-proportionate<br/>due diligence]:::product
    CONTROL[Integration architecture<br/>configuration and isolation]:::product
    TEST[Complete-product<br/>verification]:::product
    PRODUCT[[Controlled final-product state]]:::system

    EVIDENCE[/Conformity information<br/>security documentation<br/>vulnerability and support evidence/]:::overlay
    OPAQUE[Unsupported, unknown<br/>or weakly evidenced dependency]:::context
    FAILURE{{Unresolved component<br/>or integration risk}}:::enforcement

    COMPONENT --> ID
    ID --> NEED
    NEED --> DUE
    EVIDENCE ==> DUE
    OPAQUE -. uncertainty .-> DUE
    DUE --> CONTROL
    CONTROL --> TEST
    TEST --> PRODUCT

    DUE -- insufficient treatment --> FAILURE
    TEST -- unacceptable result --> FAILURE

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef system fill:#f1f3f5,stroke:#5c6770,stroke-width:1.5px,color:#252a2e;
    classDef enforcement fill:#f8dddd,stroke:#9b2f2f,stroke-width:2px,color:#501717;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 8: Third-party component evidence informs a risk-based integration decision but does not replace the cybersecurity assessment of the complete product.

The logic in Figure 8 is deliberately directional:

final-product security objective → component requirement → component evidence → integration control → complete-product verification.

A certificate or declaration should not reverse that logic into an assumption that the downstream product is secure because an upstream component was assessed in isolation.

An SBOM is a required inventory, not a security verdict

Annex I, Part II requires manufacturers to identify and document components contained in their products, including by drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format covering at least the product’s top-level software dependencies.¹⁰⁷

An SBOM can support questions such as:

• which software components are present;
• which versions are used;
• how components relate to one another;
• which supplier or package identity applies; and
• whether a newly disclosed vulnerability potentially affects the product.

It does not by itself establish:

• that the listed artefact is authentic;
• that every runtime dependency has been captured;
• whether vulnerable code is reachable;
• whether a component is securely configured;
• whether an identified vulnerability is exploitable in the final product;
• whether the dependency will remain supported;
• whether a component is appropriate for its assigned privilege; or
• whether the final integration satisfies Annex I.

Other records can therefore be necessary for hardware components, remote services, build dependencies, dynamically resolved artefacts, signing infrastructure, and external systems that affect the product’s risk profile.

Vulnerabilities in upstream components remain part of the final-product problem

Article 13 does not allow a manufacturer to stop its vulnerability process at the component boundary.

Where a manufacturer identifies a vulnerability in a component—including an open-source component—integrated into its product, it must inform the person or entity manufacturing or maintaining that component and address the vulnerability in relation to the final product.¹⁰⁸

Where the integrating manufacturer itself develops a modification to address a vulnerability in the component, the CRA requires the relevant code or documentation to be shared with the person or entity manufacturing or maintaining that component in accordance with Article 13(6).

If upstream remediation is unavailable or arrives too late, the final-product manufacturer must still satisfy its own vulnerability-handling obligations. Depending on the architecture and risk, this can require measures such as:

• patching or maintaining the component itself;
• maintaining a controlled fork;
• disabling the affected functionality;
• isolating the vulnerable component;
• applying compensating controls;
• replacing the dependency; or
• redesigning the affected part of the product.

The end of an upstream component’s support period likewise does not automatically end the support period of the final product. The final manufacturer remains responsible for vulnerability handling across the product during its declared support period and must address unsupported dependencies through other means where necessary.

Free and open-source licensing does not itself determine CRA status

The CRA defines free and open-source software (FOSS) by reference to openly shared source code and licensing that makes the software freely accessible, usable, modifiable, and redistributable.

That licensing model does not by itself determine whether:

• the software has been placed on the market;
• a particular person is its manufacturer;
• a legal person is an open-source software steward; or
• a contributor has obligations under the CRA.

The Commission guidance requires a more structured sequence:

1. Who has responsibility for the particular FOSS?
2. Is that FOSS supplied on the Union market in the course of a commercial activity?
3. If it is not placed on the market, does a legal person meet the definition of an open-source software steward for that specific FOSS?¹⁰⁹

These questions should be answered separately for each software product or edition.

Responsibility is not created by a contribution alone

For FOSS, the Commission guidance associates responsibility primarily with the person that publishes and exercises control over the relevant software product, for example through decisions over releases, roadmap, governance, or maintenance.¹¹⁰

A developer does not become the manufacturer of a FOSS project merely because the developer:

• submits a patch;
• contributes source code;
• participates in discussion;
• has commit rights; or
• is paid to implement a feature that is then contributed openly to the project.

The CRA recital expressly excludes persons contributing source code to FOSS products that are not under their responsibility.

Responsibility must therefore be distinguished from contribution.

Commercial activity must be assessed from the supply of the FOSS itself

FOSS is subject to the ordinary manufacturer regime where the relevant software is made available on the market in commercial activity under the conditions of the CRA.

Directly charging for access is the simplest case, but the Commission guidance identifies several other mechanisms that can amount to commercial supply.¹¹¹

A FOSS product can be treated as commercially supplied where, for example:

• access to it is conditioned on payment;
• the software is used as a platform through which the publisher monetises other services or products;
• access requires processing of personal data for purposes unrelated to improving the software’s security, compatibility, or interoperability; or
• payments described as donations operate in substance as the price for access, functionality, updates, binaries, or contractual benefits.

The analysis remains case-specific.

The guidance also identifies circumstances that do not by themselves establish commercial supply.

Optional paid services do not automatically commercialise freely available FOSS

A publisher can make FOSS freely available while separately charging for consultancy, training, installation assistance, documentation, deployment support, or other professional services.

Where access to the FOSS itself and its maintenance remain freely available and the professional service is genuinely optional, the Commission guidance does not treat the FOSS as placed on the market merely because those surrounding services are sold.¹¹²

The result changes where access to a particular software edition, maintained build, functionality, update stream, or other essential aspect of the product is conditioned on remuneration. A paid enterprise edition can therefore be a commercially placed product even where a functionally related community edition remains freely available.

Those editions should be analysed separately.

Donations require substance rather than labels

Voluntary donations without an intention to make a profit do not ordinarily constitute commercial activity. The guidance states that merely providing a donation link does not itself establish an intention to monetise the product, even where donations fluctuate or exceed narrowly defined infrastructure costs.¹¹³

A different conclusion can follow where donations are de facto consideration for the product—for example where only donors receive:

• current binaries;
• essential functionality;
• security updates;
• guaranteed fixes; or
• contractual advantages going beyond ordinary community recognition.

The legal analysis therefore follows the economic substance of access rather than the label donation.

External financing does not itself make FOSS commercial

Funding can take the form of grants, sponsorships, bug bounties, paid feature development, research support, or contributions from manufacturers that use the software downstream.

The Commission guidance states that the way FOSS development is financed does not itself determine whether the resulting software is placed on the market.¹¹⁴

If a developer is paid to add a feature to an open project but the resulting software remains openly shared and is not otherwise monetised by the publisher, the funding alone does not make that FOSS a commercially placed product.

The downstream manufacturer integrating it remains subject to Article 13(5) due diligence.

The CRA gives qualifying not-for-profit publishers special treatment

Recital 18 and the Commission guidance also distinguish FOSS published by a not-for-profit organisation structured so that all earnings after costs are used to achieve not-for-profit objectives.

For such an entity, the guidance treats the FOSS it publishes as not placed on the market on that basis, even where the organisation receives revenue associated with the project. If the entity satisfies the separate steward definition, it can instead fall within the open-source software steward regime.¹¹⁵

FOSS intended for downstream integration is not automatically placed on the market

The CRA expressly recognises that FOSS components are frequently published so that other manufacturers can integrate them into commercial products.

The Commission guidance states that FOSS intended for integration into other products is not considered placed on the Union market merely because downstream manufacturers use it. For the original publisher, such a component is treated as made available on the market only where it is monetised under the relevant CRA analysis.¹¹⁶

This produces an important separation of responsibilities:

• the non-commercial FOSS publisher may have no manufacturer obligations for that software;
• a qualifying legal person can instead be its open-source software steward; and
• every manufacturer integrating the component into a commercial product remains responsible for Article 13(5) due diligence and for conformity of its own complete product.

Downstream commercial use does not automatically transform the upstream non-commercial publisher into the component’s manufacturer.

Open-source software stewards occupy a separate, product-specific role

An open-source software steward is not a lighter form of manufacturer.

Article 3 defines the steward as a legal person other than a manufacturer whose purpose or objective is systematically to provide support on a sustained basis for the development of specific FOSS intended for commercial activities and that ensures the viability of that software.¹¹⁷

The Commission guidance emphasises several limits to the category:

• the relevant FOSS is published but is not itself made available on the market within the meaning of the CRA;
• stewardship is assessed for each specific FOSS product;
• the actor must be a legal person;
• the software must ultimately be intended for commercial activities; and
• the legal person must provide sustained support and play the relevant role in ensuring the project’s viability.

A legal person can consequently be:

• manufacturer of one monetised FOSS product;
• steward of another non-commercial FOSS product; and
• outside the CRA entirely for a third project for which it does not meet either definition.

Sustained support can include, depending on the project:

• governing or managing the project;
• steering development;
• hosting and managing collaboration infrastructure;
• hosting source code or software;
• operating version-control infrastructure;
• maintaining signing infrastructure; or
• otherwise systematically supporting the project’s continued viability.

Article 24 imposes a deliberately tailored regime. A steward must put in place and verifiably document a cybersecurity policy that fosters secure development and effective vulnerability handling, cooperate with market-surveillance authorities, and comply with the Article 14 reporting obligations that apply to it to the extent specified by Article 24.¹¹⁸

Stewardship does not itself make the steward the manufacturer of the FOSS, does not make the FOSS a commercially placed product, and does not authorise the steward to affix CE marking merely by virtue of that role.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    FOSS[Specific FOSS product]:::product
    RESPONSIBLE{Software under the<br/>actor's responsibility?}:::test
    COMMERCIAL{Placed on the Union market<br/>in commercial activity?}:::test
    LEGAL{Legal person providing sustained support<br/>for FOSS intended for commercial activities<br/>and ensuring its viability?}:::test

    FMFR([Manufacturer of<br/>that FOSS product]):::entity
    STEWARD([Open-source<br/>software steward]):::entity
    NOROLE[No manufacturer or steward role<br/>for that FOSS on these facts]:::context
    CONTRIBUTOR[Contributor whose code is<br/>not under its responsibility]:::context

    CHANGE[Change after<br/>market placement]:::product
    PURPOSE{Modifies intended purpose<br/>for which product was assessed?}:::test
    COMPLIANCE{Affects compliance with<br/>Annex I Part I?}:::test
    SUB[Substantial modification]:::product
    NONSUB["Not substantial<br/>under Article 3(30)"]:::context

    FOSS --> RESPONSIBLE
    RESPONSIBLE -- No --> CONTRIBUTOR
    RESPONSIBLE -- Yes --> COMMERCIAL
    COMMERCIAL -- Yes --> FMFR
    COMMERCIAL -- No --> LEGAL
    LEGAL -- Yes --> STEWARD
    LEGAL -- No --> NOROLE

    CHANGE --> PURPOSE
    PURPOSE -- Yes --> SUB
    PURPOSE -- No --> COMPLIANCE
    COMPLIANCE -- Yes --> SUB
    COMPLIANCE -- No --> NONSUB

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 9: FOSS status depends on responsibility, commercial supply and stewardship, while substantial modification is a separate post-market test based on intended purpose and Annex I Part I compliance.

The two branches in Figure 9 should not be conflated. FOSS status concerns responsibility, commercial supply, and stewardship. Substantial modification concerns a change made after a product has already been placed on the market.

Integration and substantial modification begin from different legal states

Integration and modification can look technically similar while having different legal starting points.

When a manufacturer combines components into a new product with digital elements and places that new product on the market, the manufacturer must assess conformity of the newly integrated product. That is ordinary product manufacture, not necessarily a substantial modification of each upstream component.¹¹⁹

A substantial modification, by definition, begins with a product that has already been placed on the market.

Article 3(30) defines substantial modification as a post-market change that either:

1. affects the product’s compliance with the essential cybersecurity requirements in Annex I, Part I; or
2. results in a modification to the intended purpose for which the product was assessed.¹²⁰

Release-management terminology does not decide the issue. A vendor’s labels such as patch, minor release, service pack, feature update, or major version have no independent legal effect under that definition.

Software-update size is not the substantial-modification test

The Commission guidance applies the Article 3(30) definition to software updates through a risk-based analysis.¹²¹

A change can be substantial where it:

• changes the product’s intended purpose;
• introduces new cybersecurity risks that were not addressed in the original risk assessment;
• materially increases an existing cybersecurity risk in a way not covered by the original assessment and treatment;
• changes the implementation of applicable Annex I Part I requirements so that the existing conformity case no longer applies; or
• changes security-relevant architecture, dependencies, interfaces, privileges, or data flows in a way that affects compliance.

The amount of code changed is not determinative.

A small change to authentication or remote access can affect Annex I compliance. Conversely, a large refactoring or user-interface redesign can remain non-substantial if it does not change intended purpose or affect the product’s compliance with Annex I Part I.

New functionality is not automatically a substantial modification either. Where the functionality and resulting risks were anticipated and adequately covered by the original risk assessment and conformity case, the change can remain non-substantial on those facts.

Security updates are generally risk-reducing but can still become substantial modifications

A security update that fixes vulnerabilities without changing intended purpose or creating a new or increased unaddressed cybersecurity risk will ordinarily not constitute a substantial modification merely because it is technically extensive.¹²²

The label security update, however, is not decisive.

An update can still become substantial if, for example, remediation fundamentally changes:

• the product boundary;
• trust relationships;
• external dependencies;
• remote-processing architecture;
• interfaces;
• data flows; or
• implementation of essential cybersecurity requirements.

Replacing a local security mechanism with a remote service, or introducing a new external key-management dependency, can therefore require a different analysis from replacing one cryptographic library with another compatible implementation under the same assessed architecture.

The correct question is not How large was the patch? but:

Did the post-market change modify intended purpose or affect the product’s compliance with Annex I Part I?

Physical repair, maintenance, and refurbishment are generally not substantial modifications

The Commission guidance separately addresses physical repair, refurbishment, and maintenance.

Those operations are generally not substantial modifications where they restore or preserve the product’s intended functionality without changing its intended purpose or adversely affecting its conformity with Annex I Part I.¹²³

A replacement part can even improve performance without automatically making the repaired product substantially modified, provided that the relevant intended-purpose and cybersecurity-compliance conditions remain satisfied.

Repair terminology is not conclusive, however. An activity described commercially as maintenance can still become a substantial modification if its actual technical effects meet Article 3(30).

The spare-part exclusion requires more than technical compatibility

Article 2(6) excludes certain spare parts supplied to replace identical components in products with digital elements where those spare parts are manufactured according to the same specifications as the components they replace.¹²⁴

The Commission guidance interprets the exemption in the context of spare parts specifically supplied to repair or extend the durability of products already placed on the market.¹²⁵

Technical compatibility alone is insufficient.

The relevant comparison includes security-relevant characteristics. A replacement that differs in matters such as:

• cryptographic implementation;
• secure-boot behaviour;
• authentication;
• access control;
• network protocols;
• privilege model;
• security interfaces; or
• update mechanisms

can fail the identity test even where it performs the same high-level commercial function.

Conversely, differences that do not affect the relevant functional and cybersecurity characteristics do not necessarily prevent the replacement from being treated as identical.

A replacement component that does not qualify for the Article 2(6) exclusion can itself be a CRA-regulated product with digital elements when the ordinary scope conditions are met.

The host product then requires a separate question: does installation of that replacement amount to a substantial modification of the already placed product?

A substantial modifier can become manufacturer of the affected part or the complete product

Article 22 contains an explicit affected-boundary rule for a natural or legal person other than the manufacturer, importer, or distributor that substantially modifies an already placed product and makes the modified product available on the market. That person becomes a manufacturer, and Articles 13 and 14 apply to the part of the product affected by the substantial modification or, where the modification affects the cybersecurity of the product as a whole, to the entire product.

Article 21 separately provides that an importer or distributor is considered a manufacturer and becomes subject to Articles 13 and 14 where it places a product on the market under its own name or trademark or carries out a substantial modification of an already placed product. Article 21 does not reproduce Article 22(2)’s express affected-part formulation.¹²⁶

For Article 22, the scope of the new manufacturer’s Articles 13 and 14 obligations follows the cybersecurity reach of the substantial modification. Where the modification affects only a defined part of the product without affecting the cybersecurity of the product as a whole, Article 22(2) limits those obligations to the affected part. Where the substantial modification affects the cybersecurity of the product as a whole, the obligations apply to the entire product.

That affected-boundary rule should not be imported automatically into Article 21. Article 21 makes an importer or distributor a manufacturer when either of its statutory triggers is met, but it does not reproduce Article 22(2)’s express limitation to the affected part.

An original manufacturer can also substantially modify its own product

Substantial modification is not limited to third parties.

Where the original manufacturer substantially modifies a product or software version after its earlier placement on the market, the modified state must be analysed under the CRA as appropriate. For standalone software, the Commission guidance’s market-placement analysis treats a subsequent iteration constituting a substantial modification as a new placement on the market.¹²⁷

The manufacturer must therefore ensure that the conformity case corresponds to the modified product rather than relying mechanically on evidence generated for the earlier state.

That does not mean that all historical evidence must be discarded. The Commission guidance permits continued reliance on existing assessments, documentation, and verification evidence for parts of the product that remain unaffected, provided that the manufacturer can demonstrate why that evidence continues to apply.¹²⁸

The efficient model is therefore impact-based reassessment, not automatic complete reassessment and not automatic evidence reuse.

Substantial modification can also change the support-period analysis

A substantial modification does not automatically restart a new five-year support period merely because the modified product is newly assessed or newly placed on the market.

The Commission guidance links the support period to the Article 13(8) expected-use criteria. Where the modification does not change those factors, the remaining support period can continue to reflect the original expected use. Where the modification changes the product’s expected use, intended purpose, or other relevant factors, the manufacturer should recalculate the support period for the modified product.¹²⁹

The practical consequence across components, FOSS, integration, repair, and modification is the same:

Upstream artefacts and historical evidence can support the final conformity case, but responsibility follows the product that is actually placed on the market and the security-relevant state in which it is supplied.

A disciplined CRA implementation therefore maintains traceability from each integrated component and FOSS dependency to its provenance, support and vulnerability status; from each product change to the risk and conformity assumptions it affects; and from each substantial modification to the person and product boundary for which manufacturer obligations arise.

What customers, integrators, manufacturers, and importers must check

The CRA does not give every stakeholder the same duties, evidence, or decision rights. A manufacturer must establish and demonstrate conformity of the product and its vulnerability-handling processes. An importer performs a statutory verification before placing a third-country manufacturer’s product on the Union market. An integrator must determine what legal role follows from its activity and whether integration creates a new product or modifies an existing one. A customer or user does not ordinarily perform the manufacturer’s conformity assessment and does not become an economic operator merely through use.

These actors nevertheless need to reason about the same identifiable product. A declaration, certificate, test result, support statement, advisory, SBOM, or supplier assurance is relevant only to the extent that it can be connected to the product, version, configuration, and lifecycle state to which the decision relates.

The controlled product identity used in this article is an internal assurance concept rather than a statutory CRA term. Its purpose is to prevent evidence produced for one product state from being relied upon for another.

Depending on the product and actor, a useful assurance record can distinguish:

• product name and type;
• model, batch, serial number, package, or other traceability identifier;
• software and firmware versions affecting conformity;
• security-relevant configuration;
• intended purpose and reasonably foreseeable use;
• represented operating or security environment;
• qualifying remote data-processing solutions;
• relevant integrated components and external dependencies;
• manufacturer identity and contact details;
• importer identity where applicable;
• conformity-assessment procedure;
• relevant notified-body or certification evidence where applicable;
• EU declaration of conformity;
• support-period end date;
• vulnerability-reporting contact;
• update mechanism;
• integration assumptions and limitations; and
• the actual artefact or configuration delivered or deployed.

The CRA itself requires many—but not all—of those elements to be recorded or communicated. Article 13 and Annex II require product identification, manufacturer contact details, a single point of contact for vulnerabilities, information and instructions for secure use, support information, and a copy or simplified copy of the EU declaration of conformity.¹³⁰ Annex VII requires the manufacturer’s technical documentation to contain, as applicable, software versions affecting conformity, design and architecture information, vulnerability-handling processes, the SBOM, the cybersecurity risk assessment, support-period reasoning, standards or specifications relied upon, test reports, and conformity documentation.¹³¹

The practical control is therefore evidence alignment: before relying on an artefact, determine what claim it supports and what product state it covers.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    STATE[Controlled product identity<br/>model, version, configuration<br/>purpose and dependencies]:::product

    MFR([Manufacturer]):::entity
    IMPORTER([Importer]):::entity
    INTEGRATOR([Integrator]):::entity
    CUSTOMER([Customer or user]):::entity

    INTERNAL[Risk assessment, component evidence<br/>technical documentation, tests<br/>and conformity evidence]:::product
    IMPORTCHECK[Conformity procedure, CE marking<br/>declaration, required information<br/>and support-period disclosure]:::product
    INTEGRATION[Product boundary, interfaces<br/>configuration, dependencies<br/>and change assessment]:::product
    USERINFO[Identification, declaration<br/>support, vulnerability contact<br/>updates and secure-use instructions]:::product

    LIFE[Support, vulnerability handling<br/>updates and change control]:::product
    DECISION{Evidence appropriate to<br/>the actor and product state?}:::test
    ACCEPT[Release, import<br/>integrate or accept]:::product
    BLOCK{{Block, remediate<br/>or reassess}}:::enforcement

    MFR --> INTERNAL
    IMPORTER --> IMPORTCHECK
    INTEGRATOR --> INTEGRATION
    CUSTOMER --> USERINFO

    STATE --> INTERNAL
    STATE --> IMPORTCHECK
    STATE --> INTEGRATION
    STATE --> USERINFO

    INTERNAL --> LIFE
    IMPORTCHECK --> DECISION
    INTEGRATION --> DECISION
    USERINFO --> DECISION
    LIFE --> DECISION

    DECISION -- Yes --> ACCEPT
    DECISION -- No --> BLOCK

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef enforcement fill:#f8dddd,stroke:#9b2f2f,stroke-width:2px,color:#501717;

Figure 10: Role-specific CRA assurance converges on alignment between the identifiable product, the evidence available to each actor, and the lifecycle state.

Customers should distinguish mandatory product information from additional assurance

The CRA does not generally require a manufacturer to provide customers with its complete technical documentation.

Instead, Article 13(18) requires products to be accompanied by the information and instructions specified in Annex II. At minimum, those include:

• the manufacturer’s identity and contact details;
• the single point of contact through which vulnerability information can be reported and received and where the coordinated-vulnerability-disclosure policy can be found;
• information uniquely identifying the product;
• intended purpose, including the security environment provided by the manufacturer;
• essential functionality and information about security properties;
• known or foreseeable circumstances associated with intended use or reasonably foreseeable misuse that can lead to significant cybersecurity risks;
• either the full EU declaration of conformity or a simplified EU declaration of conformity; if the simplified form is used, it must contain the exact internet address at which the full declaration can be accessed;
• the type of technical security support offered and the support-period end date;
• measures required during commissioning and throughout the product lifetime for secure use;
• information on how changes to the product can affect data security;
• instructions for installing security-relevant updates;
• instructions for secure decommissioning and removal of user data;
• information on disabling automatic security updates where that functionality exists; and
• for products intended for integration, the information required by the integrator to address Annex I and Annex VII requirements.¹³²

If the manufacturer decides to make the SBOM available to users, Annex II additionally requires information on where it can be accessed. The conditional wording matters: the CRA requires the manufacturer to create the SBOM, but does not generally require it to disclose the SBOM to customers.¹³³

The same distinction applies to the broader technical documentation. That documentation is principally a conformity artefact maintained for the regulatory process and market-surveillance authorities. Apart from specific rules such as Article 32(5) for important FOSS relying on the relevant conformity route, customers have no general CRA entitlement to receive the complete technical file.¹³⁴

A customer should therefore distinguish between:

1. CRA-required product-facing information, which the manufacturer must supply;
2. public conformity signals, such as CE marking and the declaration supplied with the product; and
3. additional assurance evidence, which may be requested contractually according to the customer’s own risk.

Additional contractual evidence can include, for example:

• an SBOM;
• penetration-test results;
• architectural threat analysis;
• secure-development evidence;
• vulnerability-response metrics;
• component support commitments;
• cloud-dependency information;
• business-continuity arrangements; or
• more detailed certification documentation.

Those requests can be prudent, particularly for high-impact deployments, but they should not be represented as universal customer rights created by the CRA.

Customer acceptance testing assesses suitability, not CRA conformity anew

A customer can also test whether a product behaves appropriately in the customer’s actual environment.

Useful checks can include:

• secure initial commissioning;
• creation and protection of administrative credentials;
• exposed services and interfaces;
• installation of an authentic security update;
• recovery following an interrupted update;
• behaviour when remote services are unavailable;
• logging and time synchronisation;
• reset and secure-data-removal functions;
• integration with identity and access controls; and
• end-of-support migration.

These tests can provide evidence about deployment suitability and internal risk. They do not transfer the manufacturer’s conformity-assessment duty to the customer or constitute a second CRA conformity procedure.

A customer should therefore avoid two opposite mistakes: treating CE marking as proof that no additional deployment analysis is needed, and treating internal acceptance testing as though it superseded the manufacturer’s statutory conformity assessment.

Support-period information is a procurement constraint

Article 13(19) requires the manufacturer to specify the support-period end date clearly and understandably at the time of purchase, including at least the month and year. Where technically feasible in light of the nature of the product, the manufacturer must also notify users when the product reaches the end of its support period.¹³⁵

For procurement, the important question is not merely whether a support date has been stated. It is whether the support period is operationally compatible with the intended deployment.

Relevant considerations can include:

• expected asset lifetime;
• planned replacement cycle;
• operating-system or platform dependencies;
• third-party component support horizons;
• migration lead time;
• safety or availability requirements;
• integration into longer-lived systems; and
• sectoral requirements affecting continued use.

The Commission guidance emphasises that five years is not a universal target. Article 13(8) requires support to reflect expected use, subject to the statutory minimum rule and its shorter-expected-use exception.¹³⁶

A product can therefore satisfy the CRA support-period rules on its own facts while still being a poor procurement choice for an organisation that needs a materially longer operating horizon.

Integrators should establish the product boundary and legal role before assessing evidence

An integrator’s first question should be what product its activity creates or changes.

Integrator is not an autonomous CRA economic-operator role. Depending on the facts, an organisation described commercially as an integrator can remain a customer, become a distributor or importer, manufacture a new integrated product, or acquire manufacturer obligations following substantial modification.

Before relying on upstream evidence, an integration record should therefore establish:

• components and versions being combined;
• which components have been separately placed on the market;
• software and firmware included in the resulting system;
• security-relevant configuration;
• intended purpose;
• which remote processing forms part of the product boundary;
• which remote systems remain external dependencies;
• interfaces and trust relationships;
• accounts and privilege boundaries;
• keys, certificates, trust stores, and credential ownership;
• data flows;
• update authority;
• responsibility for vulnerability remediation;
• support-period dependencies; and
• changes capable of altering the product boundary, intended purpose, or conformity case.

Where the product is intended for integration into another product with digital elements, Annex II, point 8(f), requires the manufacturer to provide the integrator with the information necessary to comply with the applicable Annex I essential cybersecurity requirements and Annex VII documentation requirements.¹³⁷

That requirement does not mean the upstream manufacturer’s evidence establishes conformity of the final product. Integration can change exposure, privilege, attack surface, trust relationships, remote dependencies, update paths, and failure consequences.

A component certificate or declaration is therefore an input to the integration assurance case, not the conclusion of that case.

Integrators should distinguish components from external risk dependencies

The Commission guidance distinguishes three concepts that should remain separate:

• components integrated into the product;
• remote data-processing solutions included in the product boundary; and
• infrastructure, services, systems, or networks outside the product that can nevertheless affect its security.

Article 13(5) imposes component-specific due diligence for integrated third-party components. Article 13(2) separately requires the complete-product cybersecurity risk assessment to consider relevant external risks.¹³⁸

An integrator should therefore not assume that every external service is a component, or that everything outside the product boundary can be ignored.

Where an external system remains outside the manufacturer’s control, the product may still require appropriate safeguards such as:

• authentication;
• integrity protection;
• encryption;
• input validation;
• isolation;
• bounded privileges;
• controlled failure behaviour; and
• clear integration assumptions.

The assurance record should preserve those assumptions because a later change to the surrounding environment can alter the deployment risk without changing the supplier’s product identifier.

Manufacturers need a release gate tied to the assessed state

The manufacturer’s evidence burden is broader than that of every downstream actor.

Before placing a product on the market, Article 13 requires the manufacturer to draw up the technical documentation, carry out or have carried out the applicable conformity-assessment procedure, issue the EU declaration of conformity once conformity has been demonstrated, and affix CE marking.¹³⁹

The technical documentation must permit assessment of both:

• conformity of the product with Annex I, Part I; and
• conformity of the manufacturer processes with Annex I, Part II.

Annex VII requires, as applicable:

• a general description and intended purpose;
• software versions affecting conformity;
• user information and instructions;
• design, development, production, and architecture information;
• relevant diagrams and explanations;
• vulnerability-handling processes;
• the SBOM;
• the cybersecurity risk assessment;
• support-period reasoning;
• standards, common specifications, certification schemes, or alternative technical solutions relied upon;
• test reports;
• the EU declaration of conformity; and
• further SBOM information where required by a reasoned market-surveillance request.¹⁴⁰

A practical release-readiness gate should therefore verify that:

• the product being released is uniquely identifiable;
• the assessed architecture corresponds to the released architecture;
• the cybersecurity risk assessment covers the release;
• applicability of Annex I requirements is documented;
• any non-applicability conclusions are justified;
• third-party component due diligence is current;
• the SBOM reflects the relevant software state;
• known vulnerabilities have been evaluated;
• required testing and reviews have been completed;
• classification remains correct;
• the conformity-assessment procedure remains appropriate;
• third-party assessment or certificate scope still covers the relevant state where applicable;
• Annex II user information matches the release;
• the disclosed support date matches the documented support analysis;
• vulnerability-reporting and update mechanisms are operational;
• the EU declaration identifies the relevant product; and
• CE marking is affixed only after conformity has been demonstrated.

This gate is an internal governance mechanism, not a checklist prescribed verbatim by the CRA. Its function is to make the manufacturer’s statutory obligations auditable as one release decision.

Continuing conformity requires controlled change

Article 13(14) requires manufacturers to establish procedures to ensure that products forming part of a series remain in conformity. Changes in the design or characteristics of the product, and changes in harmonised standards, European cybersecurity certification schemes, or common specifications by reference to which conformity is declared, must be adequately taken into account.¹⁴¹

The manufacturer should therefore reopen the relevant assurance decision when a change can affect:

• intended purpose;
• product boundary;
• cybersecurity risk;
• applicable Annex I requirements;
• classification;
• conformity route;
• approved type;
• dependencies;
• support;
• technical evidence; or
• the continuing validity of relied-upon standards or certificates.

The result need not be a complete reassessment in every case. As discussed earlier, evidence can remain reusable where the manufacturer can demonstrate that the relevant security assumptions and product characteristics remain unchanged.

Importers must operate the Article 19 pre-market gate

The importer does not repeat the manufacturer’s conformity assessment. It must nevertheless verify defined facts before placing the product on the Union market.

Article 19 requires the importer to ensure that:

• the appropriate conformity-assessment procedure has been carried out by the manufacturer;
• the manufacturer has drawn up the technical documentation;
• the product bears CE marking;
• the product is accompanied by the EU declaration of conformity;
• the Annex II information and instructions are supplied in a language that can be easily understood by users and market-surveillance authorities; and
• the manufacturer has complied with the specified product-identification, manufacturer-identification, and support-period disclosure requirements.¹⁴²

The importer must also provide its own identity and contact information as required by Article 19(4).

For the Article 19(2) verification, the importer must be able to provide the documents necessary to prove fulfilment of those requirements.

The document-retention rule is narrower than requiring the importer to keep the manufacturer’s entire conformity file. For at least ten years after placement on the market or for the support period, whichever is longer, the importer must:

• keep a copy of the EU declaration of conformity at the disposal of market-surveillance authorities; and
• ensure that the manufacturer’s technical documentation can be made available to those authorities upon request.¹⁴³

Following a reasoned request, Article 19(7) can additionally require the importer to provide the information and documentation necessary to demonstrate conformity and to cooperate with the authority.

If the importer considers or has reason to believe that the product or manufacturer processes are non-conforming, it must not place the product on the market until conformity has been restored. A supplier warranty or contractual statement that a product is CRA compliant cannot substitute for the Article 19 gate.

The actors should not use one undifferentiated CRA checklist

The resulting assurance model is role-specific.

Control question	Customer or user	Integrator	Manufacturer	Importer
What product is involved?	Match the purchased and deployed product to identification, declaration, instructions, support information, and inventory	Establish components, versions, configuration, interfaces, remote processing, dependencies, and the resulting product boundary	Define the product state covered by the risk assessment, documentation, testing, and conformity procedure	Match imported units to the manufacturer, CE marking, declaration, instructions, and verified product identity
What CRA role applies?	Identify manufacturer and importer; use alone does not ordinarily create economic-operator status	Determine whether the activity is use, distribution, import, manufacture of a new product, rebranding, or substantial modification	Establish manufacturer responsibility and any lawful delegation	Confirm Article 19 importer status and identify the non-Union manufacturer
What evidence is relevant?	CRA user information plus voluntarily or contractually supplied assurance evidence	Upstream evidence plus integration-specific risk and configuration evidence	Complete risk, architecture, component, vulnerability, technical-documentation, testing, classification, and conformity case	Evidence sufficient to perform and demonstrate Article 19 verification and make documentation available to authorities
Can lifecycle support operate?	Evaluate update usability, support horizon, vulnerability communication, and migration feasibility	Allocate monitoring, remediation, update, testing, and support responsibilities	Operate support, vulnerability handling, updates, reporting, and corrective processes	Maintain manufacturer contact, document access, corrective capability, and authority cooperation
What triggers reassessment?	Product update, support expiry, environmental change, vulnerability information, or dependency change	Product-boundary, component, interface, privilege, configuration, remote-processing, branding, or supply-model change	Any change affecting risk, conformity, intended purpose, assessment basis, product series, or support	Any evidence or product change that undermines the verified Article 19 conditions

Table 4: Role-specific CRA assurance and verification questions.

The distinction between legal obligation and internal assurance should remain explicit. Manufacturer and importer controls in the table are closely tied to CRA duties. Many customer and integrator controls are governance measures used to assess suitability, preserve traceability, and detect when an organisation has crossed into a different statutory role.

The common principle is not that every stakeholder should possess the same documents. It is that each stakeholder should understand which product it is dealing with, which legal role it occupies, which evidence is relevant to that role, and whether that evidence still corresponds to the product state on which the decision depends.

Vulnerability reporting, market surveillance, liability, and transition

The CRA separates vulnerability handling, mandatory event reporting, user communication, and market surveillance.

A vulnerability can require remediation under Annex I without satisfying the Article 14 reporting threshold. An actively exploited vulnerability can be reportable before a patch exists. A product can become a market-surveillance concern without any Article 14 event. Conversely, an Article 14 notification can provide information that later supports market-surveillance activity.

Those mechanisms should therefore be connected operationally without treating them as the same legal process.

Article 14 has two mandatory reporting triggers

Article 14 requires manufacturers to report two kinds of event.

The first is an actively exploited vulnerability contained in the product with digital elements.

Article 3 defines an actively exploited vulnerability as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.¹⁴⁴

That threshold is different from ordinary technical exploitability.

A vulnerability discovered through:

• internal security testing;
• a conformity-assessment laboratory;
• a bug-bounty programme;
• responsible vulnerability research; or
• a proof of concept

is not an actively exploited vulnerability merely because exploitation is technically possible. Evidence of malicious exploitation is required.

A zero-day vulnerability can nevertheless be reportable before any patch exists if the manufacturer has reliable evidence that it is being maliciously exploited.

The second trigger is a severe incident having an impact on the security of the product with digital elements.

Under Article 14(5), an incident is considered severe where it:

• negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or
• has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user.¹⁴⁵

The two Article 14 triggers are therefore related but not interchangeable. An actively exploited vulnerability focuses on malicious use of a product vulnerability. A severe incident focuses on the security impact of an incident affecting the product.

Awareness starts the reporting clock after a prompt initial assessment

Article 14 measures its deadlines from the point at which the manufacturer becomes aware of the reportable event.

The CRA does not define awareness as the first unverified alert received by any employee. The 2026 Commission guidance interprets awareness as arising when, following an initial assessment, the manufacturer has a reasonable degree of certainty that:

• a vulnerability contained in its product is being actively exploited; or
• a severe incident has occurred and has compromised the security of its product.¹⁴⁶

The distinction does not permit indefinite investigation before the clock starts.

Where a customer report, telemetry alert, threat-intelligence report, security researcher, authority, media report, or another source indicates possible active exploitation or a severe incident, the Commission guidance says that the manufacturer should assess the event immediately. In clear cases, awareness can arise quickly; in ambiguous cases, some investigation can be necessary. The emphasis remains on prompt determination of whether the reporting conditions are met.¹⁴⁷

The examples identify possible evidence sources; they do not create an Article 14 obligation to perform every listed monitoring activity or monitor every possible channel. This clarification does not displace the separate Annex I, Part II duties to provide a vulnerability-reporting contact, operate a coordinated-vulnerability-disclosure policy, and facilitate the sharing of vulnerability information.¹⁴⁸

For operational governance, the evidence chain should therefore record:

• when the first signal arrived;
• what product and versions were potentially affected;
• what the initial assessment established;
• when the manufacturer reached the reasonable-degree-of-certainty threshold;
• who made or approved that determination; and
• when each Article 14 submission was made.

This is particularly important because Article 14 is designed around progressive reporting: the first submission is intentionally made before the entire investigation is complete.

Reporting is progressive

For an actively exploited vulnerability, Article 14 requires:

• an early warning, without undue delay and in any event within 24 hours after awareness;
• a vulnerability notification, without undue delay and in any event within 72 hours after awareness, unless the relevant information has already been provided; and
• a final report, no later than 14 days after a corrective or mitigating measure becomes available, unless the required information has already been supplied.¹⁴⁹

For a severe incident, it requires:

• an early warning, without undue delay and in any event within 24 hours after awareness;
• an incident notification, without undue delay and in any event within 72 hours after awareness; and
• a final report within one month after submission of the 72-hour incident notification.¹⁵⁰

The 24-hour vulnerability warning must indicate, where applicable, the Member States in which the manufacturer is aware that the product has been made available. The 72-hour vulnerability notification adds available information on the product, the exploit and vulnerability, corrective or mitigating measures, user actions, and where applicable the sensitivity of the information.

For severe incidents, the 24-hour warning must indicate at least whether unlawful or malicious acts are suspected and, where applicable, the Member States in which the product was made available. The 72-hour notification includes available information on the nature and initial assessment of the incident and the corrective or mitigating measures already taken or available to users.

The coordinating CSIRT can request an intermediate report containing relevant status updates.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    SIGNAL[Suspicious event or<br/>external information]:::context
    ASSESS[Prompt initial assessment]:::product
    AWARE{Reasonable degree<br/>of certainty reached?}:::test
    TYPE{Article 14 trigger}:::test

    ACTIVE[Actively exploited<br/>vulnerability]:::product
    INCIDENT[Severe incident affecting<br/>product security]:::product

    A24[Within 24 hours<br/>early warning]:::product
    A72[Within 72 hours<br/>vulnerability notification]:::product
    AFINAL[No later than 14 days after<br/>corrective or mitigating<br/>measure is available]:::product

    I24[Within 24 hours<br/>early warning]:::product
    I72[Within 72 hours<br/>incident notification]:::product
    IFINAL[Within one month after<br/>72-hour notification]:::product

    STATUS[/Intermediate status report<br/>if requested by coordinating CSIRT/]:::overlay
    USERS([Impacted users<br/>and where appropriate all users]):::entity

    SIGNAL --> ASSESS
    ASSESS --> AWARE
    AWARE -- No --> ASSESS
    AWARE -- Yes --> TYPE

    TYPE -- Vulnerability --> ACTIVE
    TYPE -- Incident --> INCIDENT

    ACTIVE --> A24
    A24 --> A72
    A72 --> AFINAL

    INCIDENT --> I24
    I24 --> I72
    I72 --> IFINAL

    A72 ==> STATUS
    I72 ==> STATUS

    ACTIVE -. Article 14(8)<br/>communication .-> USERS
    INCIDENT -. Article 14(8)<br/>communication .-> USERS

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 11: Article 14 separates awareness from full investigation by requiring progressively richer notifications after the reporting threshold has been reached.

Component vulnerabilities are reportable only in relation to the affected product

A widely exploited upstream component vulnerability does not automatically produce identical Article 14 obligations for every downstream manufacturer.

The manufacturer of a final product must report an actively exploited vulnerability contained in its own product.

The Commission guidance clarifies the consequences for integrated components.¹⁵¹

Where a vulnerability originating in a third-party component:

• is contained in the final product; and
• is actively exploited in that product,

the final-product manufacturer must notify it. If the component itself was separately placed on the market, its manufacturer can independently have an Article 14 obligation as well.

By contrast, if the component vulnerability:

• cannot be exploited in the final product—for example because the vulnerable code is unreachable; or
• has not been exploited in the final product,

the Commission guidance does not treat it as an actively exploited vulnerability contained in that final product for mandatory reporting by that manufacturer.

That conclusion does not make the vulnerability irrelevant. Where the Annex I vulnerability-handling obligations apply, the manufacturer must still assess and remediate it as appropriate and comply with Article 13(6) upstream-reporting duties. Voluntary reporting under Article 15 also remains possible.

Article 14 applies beyond the ordinary vulnerability-handling support horizon

Article 14 has a broader temporal reach than Annex I vulnerability handling.

The Commission guidance states that the reporting obligation applies from 11 September 2026 to all products with digital elements within CRA scope, including products:

• placed on the market before the Regulation applies generally on 11 December 2027; and
• whose support period has already ended.¹⁵²

This distinction is important.

For a product whose support period has ended, the manufacturer may no longer have the CRA Annex I, Part II vulnerability-handling obligation merely by virtue of that expired product. Article 14 reporting can nevertheless still apply when the manufacturer becomes aware of an actively exploited vulnerability or severe incident affecting that product.

Likewise, a product placed on the market before 11 December 2027 is not made subject to every CRA product obligation solely because an Article 14 event occurs. Article 69(3) specifically applies the reporting obligations to those earlier products.

As a practical matter, manufacturers of unsupported legacy products may no longer retain old build environments, compatible dependencies, testing infrastructure, or personnel familiar with the product. That possibility does not remove Article 14, which the guidance expressly applies beyond the support period; it should therefore be treated as a reporting-readiness and historical-record-retention risk, not as a qualification of the notification duty.

Reporting is not retroactive to exploitation already known before 11 September 2026

The 2026 guidance also clarifies the transition into the Article 14 regime.

A manufacturer is not required to report an actively exploited vulnerability where it already became aware of the active exploitation before 11 September 2026. Article 14 does not create retroactive reporting of those previously known exploitation events.¹⁵³

The result differs where the manufacturer knew of the underlying vulnerability before 11 September 2026 but did not yet know that it was actively exploited.

If active exploitation begins after that date, or the manufacturer first becomes aware of the exploitation after that date, the Article 14 reporting obligation can apply.

The relevant transition record should therefore distinguish:

• when the vulnerability itself became known; from
• when the manufacturer became aware that it was actively exploited.

The Single Reporting Platform determines the notification route

Article 16 requires ENISA to establish and maintain the Single Reporting Platform (SRP).

Article 14 notifications are submitted through an electronic notification endpoint associated with a CSIRT designated as coordinator. The notification is simultaneously accessible to ENISA, subject to the exceptional information-dissemination rules in Article 16.¹⁵⁴

Where the manufacturer has a main establishment in the Union, the relevant Member State is the one where decisions relating to the cybersecurity of its products with digital elements are predominantly taken.

If that Member State cannot be determined, the main establishment is deemed to be in the Member State where the manufacturer has the establishment with the highest number of employees in the Union.¹⁵⁵

Where the manufacturer has no main establishment in the Union, Article 14(7) determines the reporting endpoint using the following hierarchy, based on information available to the manufacturer:

1. the Member State where the authorised representative acting for the highest number of that manufacturer’s products is established;
2. failing that, the Member State where the importer placing the highest number of the manufacturer’s products on the market is established;
3. failing that, the Member State where the distributor making available the highest number of those products is established; and
4. failing that, the Member State where the highest number of users of the manufacturer’s products are located.¹⁵⁶

The Article 14 route should therefore not be reduced to the statement that every manufacturer reports through its EU headquarters. The CRA contains its own functional definition and fallback hierarchy.

The coordinating CSIRT initially receiving the notification disseminates the information through the SRP to the other relevant coordinating CSIRTs. Commission Delegated Regulation (EU) 2026/881 specifies the terms and conditions under which dissemination can be delayed on justified cybersecurity grounds.¹⁵⁷

As of 8 August 2026, the Commission states that the platform will be operational by 11 September 2026 and that functional and security testing is under way. ENISA has already published registration and notification-submission guidance for assigned representatives.¹⁵⁸¹⁵⁹

Manufacturers should therefore establish before 11 September:

• the correct coordinating-CSIRT jurisdiction;
• authorised platform representatives;
• registration and identity-management access;
• internal escalation contacts;
• product and Member-State data needed for early warnings;
• authority for making the awareness determination;
• ownership of the 24-hour and 72-hour clocks; and
• procedures for updating notifications as the investigation progresses.

Open-source software stewards have narrower Article 14 duties

Open-source software stewards are not subject to the complete manufacturer reporting regime merely by virtue of stewardship.

Article 24(3) applies:

• Article 14(1), concerning actively exploited vulnerabilities, to a steward to the extent that it is involved in development of the product; and
• Articles 14(3) and 14(8), concerning severe incidents and user information, to the extent that severe incidents affect network and information systems provided by the steward for development of the relevant FOSS.¹⁶⁰

The Commission guidance notes that a steward can become aware of active exploitation through downstream manufacturers, users, or security researchers reporting exploitation of the FOSS component after integration into other products.¹⁶¹

This tailored treatment should not be confused with the broader manufacturer obligations applicable where a person actually places a FOSS product on the market in commercial activity.

User communication is mandatory but should remain proportionate

Article 14 reporting to public authorities does not replace communication to affected users.

After becoming aware of either mandatory reporting trigger, the manufacturer must inform impacted users and, where appropriate, all users of the vulnerability or incident and, where necessary, of risk-mitigation and corrective measures they can deploy.¹⁶²

Where appropriate, the information can be provided in a structured, machine-readable format that is easily processed automatically.

The Commission guidance makes clear that this obligation is risk-based and proportionate. Article 14(8) does not require indiscriminate public disclosure of every technical detail while exploitation is ongoing.¹⁶³

For sensitive products or environments, premature publication of detailed exploit information can itself increase risk. The manufacturer can therefore target detailed information to relevant customers or affected users where justified. Article 14(8) also provides a backstop: where the manufacturer fails to inform users in a timely manner, the notified CSIRTs designated as coordinators may provide the information when they consider this proportionate and necessary to prevent or mitigate the impact of the vulnerability or incident.¹⁶⁴

A useful user communication can identify, according to the circumstances:

• affected products and versions;
• conditions under which the issue applies;
• known impact;
• immediate containment actions;
• available security updates or mitigations;
• recovery precautions;
• credential, key, or certificate actions;
• temporary restrictions or loss of functionality; and
• the authoritative source for subsequent updates.

Once a vulnerability has been fixed and a security update made available, the separate Annex I, Part II requirement for public disclosure of information about fixed vulnerabilities also becomes relevant.

Market surveillance examines more than visible conformity markings

Market-surveillance authorities operate under the CRA together with Regulation (EU) 2019/1020.

Where necessary to assess conformity, Article 53 allows them, following a reasoned request, access to data and internal documentation required to evaluate product design, development, production, and vulnerability handling.¹⁶⁵

Enforcement should therefore not be understood as a CE-mark inspection exercise.

The CRA contains several distinct enforcement paths.

First, under Article 54, where an authority has sufficient reason to consider that a product—including its vulnerability handling—presents a significant cybersecurity risk, it must evaluate compliance. If non-conformity is found, the authority can require the economic operator to:

• bring the product or manufacturer processes into conformity;
• withdraw the product; or
• recall it within a reasonable period proportionate to the risk.¹⁶⁶

Second, Article 57 addresses a different case: a product and its manufacturer processes may formally comply with the CRA but nevertheless present a significant cybersecurity risk together with specified risks to health or safety, fundamental-rights obligations, services of NIS2 essential entities, or other public-interest protections. Appropriate measures can still be required.¹⁶⁷

Third, Article 58 addresses formal non-compliance concerning CE marking, the EU declaration of conformity, the notified body’s identification number where applicable, or the availability and completeness of the technical documentation. Failures concerning required information or product identification can still constitute CRA non-compliance, but they are not among the formal defects enumerated in Article 58(1).

Compliance therefore has both substantive and formal dimensions.

Administrative fines have three principal statutory tiers

Article 64 requires Member States to establish effective, proportionate, and dissuasive penalties.

For administrative fines, the CRA establishes the following maxima:

Infringement category	Maximum fixed fine	Maximum for an undertaking
Non-compliance with Annex I or obligations in Articles 13 and 14	€15 million	2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher
Non-compliance with the specified duties listed in Article 64(3), including relevant economic-operator, declaration, CE-marking, technical-documentation, conformity-assessment, notified-body, and cooperation obligations	€10 million	2% of total worldwide annual turnover for the preceding financial year, whichever is higher
Supplying incorrect, incomplete, or misleading information to notified bodies or market-surveillance authorities in reply to a request	€5 million	1% of total worldwide annual turnover for the preceding financial year, whichever is higher

Table 5: CRA administrative-fine tiers.

The maximum is not automatically the fine imposed. Article 64 requires the circumstances of the individual infringement to be considered, including its nature, gravity, duration and consequences, prior similar fines, and the size and market share of the economic operator.¹⁶⁸

Article 64(10) contains an unusual textual tension. Its chapeau operates “by way of derogation from paragraphs 3 to 9” and provides that the administrative fines referred to in those paragraphs do not apply to manufacturers qualifying as microenterprises or small enterprises with regard to failures to meet the 24-hour deadlines in Article 14(2)(a) and Article 14(4)(a), or to any infringement of the Regulation by open-source software stewards.¹⁶⁹

Article 14 non-compliance is, however, otherwise covered by the fine tier in Article 64(2), rather than paragraphs 3 to 9. Recital 113 expresses the intended protection more broadly, stating that administrative fines do not apply to microenterprises or small enterprises for failure to meet those 24-hour deadlines or to open-source software stewards for infringements of the Regulation. The operative provision and the recital are therefore not perfectly aligned on their face.¹⁷⁰

In any event, the protection concerning the 24-hour deadline does not remove the underlying Article 14 reporting obligation or the other CRA obligations applicable to the manufacturer.

Reporting itself does not increase liability

Article 17(4) provides that the mere act of notification under the specified mandatory or voluntary reporting provisions does not subject the notifying natural or legal person to increased liability.¹⁷¹

That protection is narrow.

It does not transform the reporting system into immunity for:

• an underlying product defect;
• failure to satisfy applicable product-security duties;
• late remediation;
• failure to report;
• misleading information supplied to authorities;
• or damage caused by a defective product.

Reporting and substantive responsibility therefore remain separate questions.

Product-liability law creates a separate civil-liability analysis

Directive (EU) 2024/2853 modernises the Union product-liability regime and expressly treats software as a product.¹⁷²

Under the Directive, assessment of defectiveness can take account of relevant product-safety requirements, including safety-relevant cybersecurity requirements, as well as recalls and other interventions by competent authorities or economic operators.

The Directive also reflects the lifecycle character of digitally connected products. Software updates and upgrades can remain within the manufacturer’s control, and lack of software updates or upgrades necessary to maintain safety can affect liability analysis where the statutory conditions are met.¹⁷³

The temporal rule should be stated precisely: Directive (EU) 2024/2853 applies to products placed on the market or put into service after 8 December 2026—that is, from 9 December 2026. Products placed on the market or put into service before 9 December 2026 remain subject to Directive 85/374/EEC.¹⁷⁴

CRA conformity and product-liability defectiveness are therefore distinct legal questions. A conformity assessment can be relevant evidence, but it is not an automatic defence against a civil-liability claim.

Transition depends primarily on when the product was placed on the market

The CRA’s general application date is 11 December 2027, but the transition is not governed by a single deadline.

Article 69 establishes three distinct rules.

First, EU type-examination certificates and approval decisions concerning cybersecurity requirements issued under other Union harmonisation legislation remain valid until 11 June 2028, unless they expire earlier or the other legislation provides otherwise.¹⁷⁵

Second, products with digital elements placed on the market before 11 December 2027 are subject to the CRA requirements only if, from that date, they undergo a substantial modification.¹⁷⁶

Third, Article 14 is an express exception: its reporting obligations apply from 11 September 2026 to all in-scope products, including products placed on the market before 11 December 2027.¹⁷⁷

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    D1[10 Dec 2024<br/>CRA entry into force]:::product
    D2[11 Jun 2026<br/>Chapter IV applies]:::product
    D3[11 Sep 2026<br/>Article 14 applies]:::product
    D4[11 Dec 2027<br/>general CRA application]:::product
    D5[11 Jun 2028<br/>specified transitional cybersecurity<br/>certificates cease unless otherwise provided]:::product

    LEGACY[Product placed on market<br/>before 11 Dec 2027]:::context
    REPORT[Article 14 reporting applies<br/>from 11 Sep 2026]:::product
    MOD{Substantially modified<br/>from 11 Dec 2027?}:::test
    FULL[CRA requirements apply<br/>to the substantially modified state]:::product
    LEGACYRULE[Other CRA requirements do not apply<br/>to that earlier product solely<br/>because 11 Dec 2027 arrives]:::context

    D1 --> D2
    D2 --> D3
    D3 --> D4
    D4 --> D5

    LEGACY --> REPORT
    LEGACY --> MOD
    D3 --> REPORT
    D4 --> MOD

    MOD -- Yes --> FULL
    MOD -- No --> LEGACYRULE

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 12: CRA transition separates conformity-assessment-body provisions, Article 14 reporting, general product requirements, substantial modification of earlier products, and transitional certificate validity.

The rule in Figure 12 also needs to be distinguished from the case discussed earlier in which a product was designed before the CRA but is first placed on the market after 11 December 2027. Such a product does not benefit from Article 69(2) merely because its design is old; it must comply with the CRA when placed on the market after the general application date.

The transition programme consequently requires at least three separately controlled populations:

• products already placed on the market before 11 December 2027;
• products designed earlier but intended for first placement on or after 11 December 2027; and
• new products and substantially modified products placed on the market after the general application date.

Across all three, Article 14 requires a separate reporting-readiness analysis from 11 September 2026.

The practical transition is therefore not simply be CRA compliant by December 2027. Manufacturers need an Article 14 reporting capability earlier, a controlled inventory of products already placed on the market, a conformity plan for products to be placed after the general application date, and a change process capable of identifying when a legacy product becomes substantially modified.

A technical assurance model for procurement and lifecycle governance

The CRA can be implemented operationally as a governed evidence system, but the model developed in this section is not a conformity-assessment procedure prescribed by Regulation (EU) 2024/2847, nor a governance architecture prescribed by the Commission guidance. It is an internal assurance model derived from legal requirements that are otherwise distributed across product identification, cybersecurity risk assessment, component due diligence, technical documentation, conformity assessment, continuing conformity, vulnerability handling, support, reporting, and product change.¹⁷⁸

Its purpose is to answer an operational question that the legal provisions repeatedly make important without defining one corresponding data model:

Which exact product state does a particular risk assessment, declaration, certificate, test, component record, support commitment, or lifecycle decision actually support?

The central assurance object should therefore be a controlled product state, rather than a supplier name, commercial product family, certificate, repository, contract, or individual artefact considered in isolation.

This abstraction follows from the structure of the CRA. Article 13 requires the cybersecurity risk assessment to reflect intended purpose, reasonably foreseeable use, conditions of use, protected assets, expected use, components, and relevant cybersecurity information. Article 31 requires technical documentation to contain the means by which the manufacturer demonstrates conformity and to be continuously updated, where appropriate, at least during the support period. Annex VII requires the documentation to identify the relevant product and, as applicable, software versions affecting conformity, architecture, vulnerability-handling processes, the SBOM, risk assessment, support-period reasoning, and conformity evidence.¹⁷⁹

For internal assurance, let the product state at time t be represented as:

P_t = \left( B_t, H_t, S_t, K_t, D_t, I_t, U_t \right), \tag{1}

where:

• B_t is the defined product boundary, including any qualifying remote data-processing solution;
• H_t is the hardware configuration relevant to cybersecurity;
• S_t is the software and firmware configuration;
• K_t is the security-relevant product configuration;
• D_t is the dependency set and the classification of those dependencies;
• I_t is the intended purpose, reasonably foreseeable use, conditions of use, and relevant operating assumptions; and
• U_t is the lifecycle state relevant to support, updates, vulnerability handling, reporting, and end of support.

None of these variables is a statutory CRA data field. Together they provide a way to represent the technical facts on which statutory conclusions depend.

Dependencies should be typed before they are assessed

The dependency set D_t should not treat every external relationship as though it had the same legal status.

At least three categories should be distinguished:

1. integrated third-party components—software or hardware forming part of the product and therefore subject to the manufacturer’s Article 13(5) due-diligence obligation;
2. remote data-processing solutions—qualifying software that forms part of the product with digital elements under Article 3(1) and (2); and
3. external infrastructure, services, systems, networks, or environmental elements that remain outside the product boundary but can create cybersecurity risks affecting the product.

The Commission guidance expressly distinguishes the first and third categories. Article 13(2) requires the manufacturer to assess risks affecting the product, including risks originating outside it, whereas Article 13(5) establishes a separate due-diligence obligation for components integrated into the product.¹⁸⁰

For an external system that remains outside the product boundary, the CRA does not generally require the manufacturer to control how that external system is organised or operated. The manufacturer must instead identify relevant risks and, where necessary, address them through the design of its own product and through appropriate integration or deployment instructions.¹⁸¹

The Commission guidance gives examples such as a compromised external backend attempting to issue malicious commands to a product. The external backend need not become part of the regulated product for the manufacturer to need measures such as command authentication, integrity validation, abnormal-behaviour logging, or secure failure behaviour.

This distinction is analytically important:

The legal product boundary determines what is regulated as the product; the cybersecurity risk boundary can extend beyond it.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    STATE[Controlled product state<br/>boundary, hardware, software<br/>configuration, dependencies<br/>purpose and lifecycle state]:::product

    ACTORS([Manufacturer, importer<br/>integrator and customer]):::entity
    ROLES[Legal role assignments]:::product
    DUTIES[Applicable CRA obligations<br/>and internal assurance requirements]:::product

    COMPONENT[Integrated third-party<br/>components]:::product
    RDPS[Qualifying remote<br/>data-processing solutions]:::product
    EXTERNAL[External infrastructure<br/>services, systems and networks]:::context

    EVIDENCE[Risk assessment, technical documentation<br/>tests, SBOM, declarations<br/>certificates and decisions]:::product
    LIFE[Support, updates, vulnerability handling<br/>reporting and corrective processes]:::product

    EVENT[/Version, component, configuration<br/>purpose, dependency, vulnerability<br/>or support change/]:::overlay
    REVIEW{Does existing evidence still<br/>support the relevant product state?}:::test

    ACCEPT[Release, import, integrate<br/>procure or continue operation]:::product
    BLOCK{{Reassess, remediate<br/>or block the decision}}:::enforcement

    ACTORS --> ROLES
    ROLES --> DUTIES
    STATE --> DUTIES

    STATE --> COMPONENT
    STATE --> RDPS
    EXTERNAL -. risk context .-> STATE

    DUTIES --> EVIDENCE
    COMPONENT --> EVIDENCE
    RDPS --> EVIDENCE
    EVIDENCE --> LIFE

    EVENT ==> STATE
    EVENT ==> REVIEW
    EVIDENCE --> REVIEW
    LIFE --> REVIEW

    REVIEW -- Yes --> ACCEPT
    REVIEW -- No --> BLOCK

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef enforcement fill:#f8dddd,stroke:#9b2f2f,stroke-width:2px,color:#501717;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef context fill:#ffffff,stroke:#7a7a7a,stroke-width:1.5px,stroke-dasharray:5 5,color:#404040;

Figure 13: The internal assurance model connects a controlled product state to legal roles, requirements, integrated components, external risks, evidence, lifecycle processes, and change decisions.

The model in Figure 13 prevents a common assurance failure: retaining a valid-looking document without establishing whether the product to which it originally applied is still the product being supplied, operated, or changed.

Product-family evidence can be reused only within the limits of cybersecurity equivalence

A controlled-state model does not imply that every colour, enclosure, memory option, or other product variant must automatically have an independent risk assessment and conformity file.

The Commission guidance expressly permits shared treatment of variants, models, or configurations where they:

• share the same architecture;
• share the same security-relevant design;
• have the same intended purpose; and
• are exposed to the same cybersecurity risks.¹⁸²

Where those conditions hold and all variants are adequately covered with respect to relevant risks and essential requirements, the manufacturer may rely on:

• one Article 13(2) cybersecurity risk assessment;
• one set of technical documentation;
• one conformity-assessment procedure; and
• one EU declaration of conformity identifying all variants to which it applies.¹⁸³

The relevant equivalence is cybersecurity equivalence, not commercial membership in the same product family.

A difference in colour or another characteristic that does not affect cybersecurity can be irrelevant. The Commission also identifies examples such as form factor or memory size where those differences do not affect cybersecurity properties.

By contrast, variants can require differentiated treatment where they change matters such as:

• communication interfaces;
• software stacks;
• update mechanisms;
• remote connectivity;
• security-relevant architecture; or
• the way an essential requirement is implemented.

Where a new variant introduces new cybersecurity risks or changes implementation of essential requirements, the risk assessment and related conformity documentation must be updated accordingly.¹⁸⁴

The controlled-state model should therefore support two complementary questions:

1. What exact state was supplied or deployed?
2. Which other states are sufficiently equivalent that the same evidence legitimately covers them?

A shared marketing name is not evidence of that equivalence.

Assurance is conjunctive rather than compensatory

For internal governance, define the assurance predicate:

\mathcal{A}(P_t) = \mathcal{I}(P_t) \land \mathcal{R}(P_t) \land \mathcal{O}(P_t) \land \mathcal{E}(P_t) \land \mathcal{L}(P_t) \land \mathcal{C}(P_t), \tag{2}

where:

• \mathcal{I}(P_t) means that the product identity and boundary are controlled;
• \mathcal{R}(P_t) means that the relevant CRA roles are correctly assigned;
• \mathcal{O}(P_t) means that the applicable legal obligations and internal requirements have been identified;
• \mathcal{E}(P_t) means that adequate evidence supports the relevant claims for P_t;
• \mathcal{L}(P_t) means that the necessary lifecycle capabilities are operational; and
• \mathcal{C}(P_t) means that relevant changes have been assessed against the existing assurance case.

Equation Equation 2 is an internal decision rule, not a formula for legal conformity under the CRA.

Its value is to make assurance non-compensatory.

For example:

• additional penetration testing cannot resolve uncertainty about which entity is legally the manufacturer;
• an EU declaration of conformity cannot prove that the deployed artefact is the product identified in the declaration;
• a component certificate cannot establish security of the final integration;
• an SBOM cannot establish that the update mechanism is secure;
• a support-period statement cannot demonstrate that vulnerability intake and remediation actually operate;
• a successful conformity assessment does not automatically cover a later security-relevant product change; and
• customer operating controls cannot be used to transfer to the customer cybersecurity risk that the manufacturer was required to address in the product.

The final point is particularly important. The Commission guidance states that the CRA does not provide for transferring cybersecurity risk or manufacturer responsibility to users or third parties in order to compensate for shortcomings in product design or leave identified risks untreated.¹⁸⁵

Component evidence should answer a product-derived question

The Commission guidance gives component due diligence a specific direction.

The manufacturer should first determine what the final product requires from the integrated component in order to meet its cybersecurity objectives. It should then verify, in a risk-based manner, whether the component satisfies those requirements.¹⁸⁶

For example, where the final product relies on a third-party component for:

• cryptographic operations;
• authentication;
• update verification;
• secure communications; or
• another security-critical capability,

the manufacturer should identify the required security property before deciding what evidence is sufficient.

Evidence may include:

• technical specifications;
• security documentation;
• conformity documentation;
• assurance or certification documentation;
• vulnerability information; and
• manufacturer-performed testing where appropriate.

The logical direction is:

product cybersecurity objective → component requirement → evidence → integration decision.

The inverse inference is unsafe:

supplier certificate → assumed conformity of the final product.

A component may implement cryptography correctly in isolation while the final product uses weak parameters, mishandles keys, exposes an unsafe API, disables verification, or cannot update the component safely.

The component evidence is therefore claim-specific support for the final-product conformity case, not a substitute for it.

External dependencies require risk treatment without necessarily becoming product components

A technical assurance model should not turn every infrastructure dependency into an integrated component merely because failure or compromise of the dependency affects the product.

The Commission guidance requires external networks, environmental factors, infrastructure, and other external systems to be considered where they create relevant cybersecurity risks.¹⁸⁷

Possible dependencies include:

• a third-party identity provider;
• DNS;
• an external certificate authority;
• a generic SaaS platform;
• telecommunications infrastructure;
• customer-managed directory services;
• cloud infrastructure outside the RDPS boundary; or
• another system exchanging commands or data with the product.

Their legal treatment depends on the architecture.

For an external element that remains outside the product, the manufacturer generally addresses the resulting risk through product-level measures, not by assuming regulatory control over the external provider.

Depending on the risk assessment, such measures can include:

• authenticated communications;
• cryptographic integrity protection;
• validation of commands and configuration;
• least privilege;
• isolation;
• safe degradation;
• timeout and recovery behaviour;
• integrity checking;
• anomaly logging; and
• deployment instructions documenting necessary environmental assumptions.

Third-party remote services require particular care. The Commission guidance indicates that some third-party remote solutions that do not qualify as RDPS can nevertheless need component-like security verification where their integration affects the product’s security. It also encourages manufacturers to obtain information about material provider changes so that the product risk assessment can be revisited where appropriate.¹⁸⁸

That should not be generalised into an Article 13(5) due-diligence requirement for every external network service. The architectural relationship must be analysed first.

Evidence should be typed by the claim it supports

An internal evidence object should identify, at minimum:

• issuer or author;
• product or product-family scope;
• version or configuration scope;
• requirement or claim supported;
• creation and approval date;
• validity or review conditions;
• assumptions and limitations;
• provenance and integrity;
• superseding evidence; and
• whether the evidence concerns the product, a component, a manufacturer process, or a conformity procedure.

These are internal assurance attributes, not a list imposed verbatim by the CRA.

Their purpose is to prevent unlike evidence from being treated as interchangeable.

An EU declaration of conformity records the manufacturer’s formal declaration and assumption of responsibility.

A notified-body certificate records the result and scope of the applicable third-party conformity procedure.

An SBOM records software-component relationships.

A penetration-test report records observations within a defined configuration, threat model, methodology, and time period.

A support statement records a lifecycle commitment.

An update test provides evidence about the behaviour of a particular update path under tested conditions.

The evidentiary question is therefore not merely whether a document exists. It is:

What claim does this artefact support, for which product state, and under what assumptions?

Change assessment should be broader than the substantial-modification test

A useful assurance system should reopen relevant evidence whenever a security-relevant change occurs, but that does not mean every such change is a substantial modification under Article 3(30).

The substantial-modification test asks whether a post-market change affects compliance with Annex I, Part I, or modifies the intended purpose for which the product was assessed.

Internal change control has a broader function. It should detect changes that can require:

• an updated risk assessment;
• revised technical documentation;
• additional testing;
• changed component due diligence;
• revised integration instructions;
• certificate or conformity review;
• a support decision; or
• a formal substantial-modification analysis.

Relevant events can include:

• hardware replacement;
• firmware or software update;
• changed communication interface;
• altered privilege or trust relationship;
• changed update mechanism;
• replacement of a security-critical component;
• rearchitected remote processing;
• a new third-party service;
• change in intended purpose;
• change in reasonably foreseeable use;
• changed support commitment;
• newly discovered vulnerability;
• end of support for an important dependency; or
• a change to a harmonised-standard, common-specification, certification, or notified-body basis on which the conformity case relies.

A change in an external service can therefore require a new cybersecurity-risk analysis even where it is not itself a substantial modification of the product because the external service is outside the manufacturer’s responsibility.

This distinction prevents the internal assurance system from using the substantial-modification threshold as the only trigger for lifecycle review.

Reassessment should be impact-based rather than all-or-nothing

Neither the CRA nor the Commission guidance requires every product change to destroy all prior evidence.

For substantial modifications, the Commission guidance explains that existing tests and documentation can continue to be used for aspects not affected by the modification, provided that the person relying on them can demonstrate why they remain applicable.¹⁸⁹

The same principle is visible in the Commission’s treatment of product families: evidence can be shared until cybersecurity-relevant differences invalidate the shared assumptions.¹⁹⁰

For governance purposes, let a change event be \Delta_t. The purpose of change analysis is then not to ask only:

Must everything be reassessed?

but:

Which claims supporting \mathcal{A}(P_t) are invalidated, weakened, or unaffected by \Delta_t?

That impact analysis should identify which parts of the following require revision:

• product identity and boundary;
• cybersecurity risk assessment;
• component records;
• SBOM;
• architecture documentation;
• tests and reviews;
• conformity-assessment evidence;
• declaration;
• user or integration instructions;
• support analysis; and
• vulnerability-handling procedures.

The resulting approach is more precise than either extreme: treating every release as an entirely new conformity exercise or treating version continuity as proof that historical evidence remains valid.

Technical documentation should be maintained as a versioned assurance record

Article 31 requires technical documentation to be drawn up before the product is placed on the market and to be continuously updated, where appropriate, at least during the support period.¹⁹¹

For internal governance, that implies that technical documentation should be managed as a versioned body of evidence rather than as a static dossier generated immediately before CE marking.

Its internal structure should make it possible to determine:

• what product or variants the documentation covers;
• which architecture and software state were assessed;
• which risk assessment applies;
• which components were considered;
• which tests support which requirements;
• what support assumptions were made;
• what conformity route was followed;
• what changed between relevant product states; and
• which earlier evidence remains applicable.

This does not require every technical file to use one prescribed database schema. It requires the organisation to preserve the links that make conformity evidence intelligible.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    STATE[Controlled product state]:::product
    RISK[Cybersecurity risks<br/>and assumptions]:::product
    REQUIREMENT[Applicable Annex I<br/>and internal requirements]:::product
    CONTROL[Implemented security measures]:::product
    VERIFY[Tests, analysis<br/>review and inspection]:::product
    CONFORMITY[Conformity evidence<br/>declaration and certificates]:::product
    LIFECYCLE[Support, vulnerability, update<br/>reporting and change records]:::product

    COMPONENT[/Component specifications<br/>security documentation<br/>and assurance evidence/]:::overlay

    DECISION{Evidence still supports<br/>the current product state?}:::test
    ACCEPT[Supported assurance decision]:::product
    BLOCK{{Unsupported claim<br/>or reassessment required}}:::enforcement

    STATE --> RISK
    RISK --> REQUIREMENT
    REQUIREMENT --> CONTROL
    CONTROL --> VERIFY
    VERIFY --> CONFORMITY

    COMPONENT ==> REQUIREMENT
    COMPONENT ==> VERIFY

    CONFORMITY --> DECISION
    LIFECYCLE --> DECISION
    LIFECYCLE ==> RISK

    DECISION -- Yes --> ACCEPT
    DECISION -- No --> BLOCK

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef enforcement fill:#f8dddd,stroke:#9b2f2f,stroke-width:2px,color:#501717;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;

Figure 14: Assurance evidence should be traceable from a defined product state through cybersecurity risks and applicable requirements to implementation, verification, conformity, and lifecycle decisions.

The analytical point in Figure 14 is that traceability should run from evidence to a claim and from that claim to a product state. Merely storing evidence under a supplier or product-family folder does not establish that relationship.

Procurement can implement recurrent assurance gates

The CRA does not prescribe a procurement-gate methodology. The following gates are an internal control architecture for keeping procurement and lifecycle decisions aligned with the product-security obligations developed throughout this article.

Gate	Decision	Representative evidence
G0. Scope and role	What product is being considered, and what CRA role would each relevant legal entity occupy?	Product description, connectivity, product boundary, manufacturer, importer, preliminary role analysis
G1. Requirements	What security, lifecycle, integration, evidence, and deployment properties does the intended use require?	Deployment context, risk assumptions, technical requirements, support and migration constraints
G2. Selection	Does the candidate product and its lifecycle model satisfy the intended use?	Product identity, declaration, conformity information, support period, update model, vulnerability information
G3. Contract and baseline	Are product identity, dependencies, responsibilities, evidence access, and change obligations sufficiently controlled?	Version baseline, support commitments, dependency information, notification clauses, evidence-delivery obligations
G4. Delivery and acceptance	Does the delivered state match the accepted state and behave as represented?	Artefact verification, secure commissioning, configuration review, update and recovery testing
G5. Operation and change	Does continued use remain supported by current security and lifecycle evidence?	Vulnerabilities, advisories, updates, dependencies, incidents, support state, configuration changes, reassessment decisions
G6. Exit	Can the product be retired without unmanaged credentials, data, dependencies, or unsupported residual use?	Data removal, credential and key revocation, dependency removal, migration record, evidence archive

Table 6: Procurement and lifecycle assurance gates.

The gate model distinguishes procurement assurance from legal conformity. G4 testing, for example, does not repeat the manufacturer’s Article 32 conformity assessment. It determines whether the product actually delivered to the organisation corresponds to the product and conditions on which the acquisition decision was based.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    G0[G0<br/>Scope and role]:::product
    G1[G1<br/>Requirements]:::product
    G2[G2<br/>Selection]:::product
    G3[G3<br/>Contract and baseline]:::product
    G4[G4<br/>Delivery and acceptance]:::product
    G5[G5<br/>Operation and change]:::product
    G6[G6<br/>Exit]:::product

    EVENT[/Security-relevant<br/>lifecycle change/]:::overlay
    IMPACT{Which assurance claims<br/>does the change affect?}:::test
    DECISION{Affected claims<br/>still supported?}:::test
    REMEDIATE{{Remediate, revisit gate<br/>reject change or retire}}:::enforcement

    G0 --> G1
    G1 --> G2
    G2 --> G3
    G3 --> G4
    G4 --> G5
    G5 --> G6

    G5 --> EVENT
    EVENT ==> IMPACT
    IMPACT --> DECISION

    DECISION -- Yes --> G5
    DECISION -- No --> REMEDIATE

    REMEDIATE -. requirements .-> G1
    REMEDIATE -. product selection .-> G2
    REMEDIATE -. contractual baseline .-> G3
    REMEDIATE -. acceptance .-> G4
    REMEDIATE -. retirement .-> G6

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef enforcement fill:#f8dddd,stroke:#9b2f2f,stroke-width:2px,color:#501717;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;

Figure 15: Procurement assurance is recurrent: security-relevant lifecycle changes reopen only the decisions and evidence that they affect.

Contracts should preserve evidence and cooperation, not attempt to rewrite statutory roles

Contracts can allocate engineering responsibilities, notification processes, evidence-delivery obligations, warranties, remedies, and commercial risk. They cannot make a CRA role disappear where the underlying statutory facts establish that role.

Nor can contractual language transfer to a customer cybersecurity risk that the manufacturer was required to address in order for the product to satisfy the applicable essential requirements.

Contracts can nevertheless make lifecycle compliance substantially more operable.

Depending on the supply relationship, useful provisions can address:

• exact product and version identity;
• manufacturer-controlled RDPS;
• third-party remote services;
• security-relevant dependencies;
• support-period end dates;
• availability and delivery of security updates;
• vulnerability communication between the parties;
• security-relevant component or service changes;
• SBOM access where contractually required;
• access to defined assurance evidence;
• manufacturer cessation;
• update-signing or distribution continuity;
• remediation or replacement;
• migration assistance;
• preservation of evidence; and
• notice of changes that can affect product cybersecurity or the customer’s deployment assumptions.

The most useful contractual control is ordinarily specific and testable. A general clause requiring a supplier to remain CRA compliant does not itself establish which product state is covered, what evidence must be supplied, what events require notification, or what remedy follows when an assumption ceases to hold.

A lifecycle control plane should preserve referential integrity

Procurement, engineering, product security, legal, compliance, operations, vulnerability management, and incident response do not need to use one software platform.

They do need to refer to the same product identity and evidence relationships.

An internal control plane can therefore connect:

• product and asset inventory;
• manufacturer and supplier records;
• legal-role determinations;
• hardware, firmware, and software versions;
• product boundaries;
• RDPS;
• external dependencies;
• cybersecurity risk assessments;
• component due-diligence evidence;
• SBOMs;
• technical-documentation versions;
• test evidence;
• declarations and certificates;
• support-period end dates;
• vulnerabilities and advisories;
• security updates;
• Article 14 reporting records where applicable;
• change decisions; and
• retirement records.

The Commission guidance’s product-family analysis illustrates why these relationships matter. One risk assessment and one conformity case can legitimately cover several variants only while the relevant architecture, security design, intended purpose, cybersecurity risks, and implementation of essential requirements remain sufficiently aligned.¹⁹²

A new interface, software stack, update architecture, or remote-connectivity model can break that equivalence even where the commercial product family remains unchanged.

The operational test of the control plane is reconstructability: the ability, from controlled records, to establish under time pressure:

• which product or variants are affected;
• which version and configuration are involved;
• which legal entities occupy which roles;
• which components and external dependencies matter;
• which risk assessment applies;
• which conformity evidence remains relevant;
• what support state applies;
• whether Article 14 records exist;
• which customers or users are affected;
• what changed; and
• why release, continued operation, remediation, reassessment, or retirement was considered justified.

Reconstructability is not a legal term used by the CRA and is not an additional essential cybersecurity requirement. It is an internal governance property that makes the Regulation’s distributed product-lifecycle obligations traceable as a coherent assurance system.

Limits, Open Questions, and the Compliance Horizon

The CRA substantially reduces regulatory fragmentation for products with digital elements, but it does not eliminate uncertainty. Compliance still requires decisions about product boundaries, legal roles, technical risk, evidence coverage, implementation infrastructure, and future product states. The correct response to those uncertainties is not to postpone decisions until every standard, authority practice, and technical dependency is stable. It is to make the assumptions on which each decision depends explicit, owned, testable, and subject to reassessment.

Five kinds of uncertainty are particularly relevant:

• legal uncertainty concerns the application of statutory concepts such as commercial activity, responsibility for FOSS, product boundaries, remote data processing, substantial modification, expected use, and Article 14 awareness to particular facts;
• technical uncertainty concerns vulnerabilities, attack paths, dependency behaviour, configuration, emergent threats, and limitations of available security mechanisms;
• evidential uncertainty concerns whether declarations, certificates, tests, SBOMs, supplier information, risk assessments, and other evidence are authentic, current, sufficiently complete, and aligned with the product state under consideration;
• institutional uncertainty concerns the evolving availability and scope of harmonised standards, notified bodies, certification routes, reporting infrastructure, market-surveillance practice, and further Commission measures; and
• operational uncertainty concerns whether the manufacturer and its supply chain will actually be capable of vulnerability intake, analysis, remediation, secure update delivery, Article 14 reporting, user communication, corrective action, and long-term support when those capabilities are required.

These uncertainties have different sources and cannot be collapsed into one generic compliance risk. A legal interpretation cannot eliminate an unknown vulnerability. A penetration test cannot establish whether a conformity route is legally available. A valid certificate cannot establish that the manufacturer’s update organisation will still function several years later. A documented support process cannot prove that the product state currently deployed corresponds to the state that was assessed.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
    STATE[Controlled product state]:::product

    LEGAL[/Legal uncertainty<br/>scope, role and interpretation/]:::overlay
    TECH[/Technical uncertainty<br/>vulnerabilities and attack paths/]:::overlay
    EVIDENCE[/Evidential uncertainty<br/>coverage, provenance and freshness/]:::overlay
    INSTITUTION[/Institutional uncertainty<br/>standards, bodies and infrastructure/]:::overlay
    OPERATIONS[/Operational uncertainty<br/>support, remediation and reporting/]:::overlay

    TEST{Assumptions, limitations, owners<br/>monitoring sources and<br/>review triggers explicit?}:::test

    DECISION[Conditioned assurance decision]:::product
    BLOCK{{Unsupported reliance<br/>or reassessment required}}:::enforcement

    STATE --> LEGAL
    STATE --> TECH
    STATE --> EVIDENCE
    STATE --> INSTITUTION
    STATE --> OPERATIONS

    LEGAL ==> TEST
    TECH ==> TEST
    EVIDENCE ==> TEST
    INSTITUTION ==> TEST
    OPERATIONS ==> TEST

    TEST -- Yes --> DECISION
    TEST -- No --> BLOCK

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef enforcement fill:#f8dddd,stroke:#9b2f2f,stroke-width:2px,color:#501717;

Figure 16: A defensible CRA decision makes legal, technical, evidential, institutional, and operational uncertainty explicit rather than hiding it behind a binary compliance label.

The model in Figure 16 does not imply that uncertainty itself establishes non-conformity. It distinguishes a known and controlled limitation from an unsupported assumption. A manufacturer can make a defensible decision in the presence of uncertainty where the applicable legal requirement is satisfied and the remaining assumption, evidence limitation, or implementation dependency is understood and appropriately managed.

The 2026 Commission guidance has an important formal-status nuance

On 27 July 2026, the Commission published C(2026) 5252 and the accompanying 84-page annex addressing scope, FOSS, substantial modification, support periods, important and critical products, cybersecurity risk assessment, remote data processing, reporting, vulnerability handling, and interaction with other Union legislation.¹⁹³

The Commission’s public implementation pages describe this material as the first Commission guidance on CRA implementation and expressly describe it as non-binding.

There is nevertheless a formal-status distinction that should not be hidden. The C(2026) 5252 communication approving the content of the draft guidance states that the annexed guidance is to be formally adopted by the Commission at a later date once all language versions are available. The annex states that the guidance is not binding on economic operators or other actors subject to the CRA, does not cover the CRA exhaustively, and cannot displace authoritative interpretation by the Court of Justice of the European Union.¹⁹⁴

As of 8 August 2026, the Commission’s current CRA implementation pages continue to identify the 27 July publication as the first set of CRA guidance and link to C(2026) 5252; they do not identify a later replacement in the implementation roadmap.¹⁹⁵

The correct evidentiary treatment is therefore neither to ignore the guidance nor to treat it as though it amended the Regulation.

For product decisions, organisations should record:

• the version and date of the guidance relied upon;
• the specific paragraph or example supporting the interpretation;
• whether the conclusion follows directly from the Regulation or only from Commission interpretation;
• any material factual assumptions required by the example;
• whether later Commission material has changed the interpretation; and
• whether relevant case law, delegated acts, implementing acts, or harmonised standards subsequently alter the analysis.

The CRA itself remains the binding legal baseline.

The Commission-services FAQs should be treated even more cautiously. Version 1.3 expressly states that the FAQs are a preliminary, living document prepared by Commission services, are not representative of the Commission’s official position, do not add obligations, and cannot prejudge future Commission positions or interpretation by the Court of Justice.¹⁹⁶

Harmonised standards remain an implementation dependency, not a prerequisite for starting engineering

The CRA is deliberately written through essential cybersecurity requirements rather than a complete prescriptive technical control catalogue. Harmonised standards are intended to provide important implementation detail and, once the legal conditions in Article 27 are satisfied, can create a presumption of conformity for the requirements they cover.

The Commission standardisation request M/606 asks CEN, CENELEC, and ETSI to develop 41 standards supporting CRA implementation.¹⁹⁷ The programme includes horizontal product-agnostic work and vertical standards addressing categories of important and critical products.

The implementation timetable contains several important requested ESO delivery dates:

• 30 August 2026 for the horizontal standard on risk-based design, development, and production and the horizontal vulnerability-handling standard;
• 30 October 2026 for the requested product-specific vertical deliverables; and
• 30 October 2027 for the remaining horizontal standards addressing the specific product-property requirements in Annex I, Part I.¹⁹⁸

On 8 August 2026, all three dates remain future milestones.

They should also not be confused with the date on which a manufacturer can necessarily obtain an Article 27 presumption of conformity. Adoption of a European standard by an ESO is followed by Commission assessment under Regulation (EU) No 1025/2012. For a harmonised standard to produce the Article 27(1) legal presumption, its reference must be published in the Official Journal of the European Union.¹⁹⁹ The Commission’s general harmonised-standards framework likewise identifies Official Journal publication as the relevant legal step.

The implementation sequence is therefore more accurately represented as:

technical drafting → ESO adoption → Commission assessment → Official Journal citation → bounded presumption of conformity.

A requested delivery date is not a guarantee that every needed standard will be cited in the Official Journal on that date.

Manufacturers should consequently not postpone risk assessment, secure design, component due diligence, testing, vulnerability handling, or technical-documentation work until the standards programme is complete. The legal obligations derive from the CRA itself.

Where a cited harmonised standard is not yet available, a manufacturer can still design and demonstrate conformity using appropriate engineering methods and evidence. What is unavailable is the legal presumption that would otherwise arise for the requirements covered by the cited harmonised standard.

The conformity-assessment ecosystem is still being built

Chapter IV has applied since 11 June 2026, enabling Member States to designate notifying authorities and begin the notification of conformity-assessment bodies.²⁰⁰

A conformity-assessment body becomes a CRA notified body only after the applicable assessment, designation, and notification process. The Commission identifies NANDO as the authoritative public register in which CRA notified bodies are published once notified.²⁰¹

Availability should therefore be checked dynamically rather than assumed from accreditation claims, supplier statements, or experience under another Union product regime.

For products requiring or electing third-party conformity assessment, manufacturers need to verify at least:

• that the organisation is actually notified under Regulation (EU) 2024/2847;
• the product or technical scope covered by its notification;
• the conformity modules it can perform;
• relevant technical competence;
• laboratory and assessment capacity;
• lead time;
• treatment of frequent software changes;
• certificate-change procedures; and
• interaction with conformity assessments required under other Union legislation.

Article 35(2) requires Member States to strive to ensure, by 11 December 2026, that a sufficient number of notified bodies exists in the Union to carry out conformity assessments and avoid bottlenecks and hindrances to market entry.²⁰² The Commission implementation roadmap repeats that statutory target.²⁰³

That is an implementation milestone rather than a reason for manufacturers of class II and critical products to defer planning until December. Capacity risk is itself a project dependency.

Certification-based conformity routes are also evolving

The CRA permits certain European cybersecurity certification schemes to participate in the conformity architecture where Article 27 and Article 32 conditions are satisfied.

The existence of an EU cybersecurity certification scheme does not, by itself, make that scheme an operative CRA conformity route. The Commission must specify the applicable conditions, including the relevant requirements, product categories, and assurance level.²⁰⁴

The Commission’s current implementation roadmap identifies Q4 2026 for a delegated act specifying CRA presumption-of-conformity treatment for the European Cybersecurity Certification Scheme on Common Criteria (EUCC).²⁰⁵

Until the relevant legal conditions exist for the particular product and route, manufacturers should not treat an existing cybersecurity certificate as an automatic substitute for the conformity procedure required by Article 32.

Certification evidence can remain technically valuable. Its legal effect under the CRA must be assessed separately.

The Single Reporting Platform remains a near-term operational dependency

Article 14 begins to apply on 11 September 2026. The reporting obligation is therefore much closer than the general CRA application date.

As of 8 August 2026, the Commission’s reporting page states that ENISA’s Single Reporting Platform will be operational by 11 September and that functional and security testing are under way.²⁰⁶

Manufacturers should distinguish platform availability from organisational readiness.

Even if the production platform becomes available exactly as scheduled, a manufacturer cannot meet a 24-hour early-warning obligation reliably if an incident is the first time the organisation determines:

• which product is affected;
• which legal entity is the manufacturer;
• which product versions were made available in which Member States;
• who can determine that the Article 14 awareness threshold has been reached;
• who has authority to submit the report;
• which coordinating-CSIRT endpoint applies;
• who holds the necessary platform identity or representative rights; or
• where relevant exploit, incident, and mitigation information can be obtained.

Preparation before 11 September should therefore cover the decision and evidence system, not merely platform registration.

A practical readiness test is whether the organisation can simulate the interval from an external vulnerability or incident signal to:

1. initial technical triage;
2. determination of the affected product state;
3. escalation to the person authorised to establish awareness;
4. identification of the correct reporting jurisdiction;
5. collection of the minimum early-warning data;
6. submission;
7. continued investigation; and
8. preparation of the 72-hour and final reports.

The platform is an external implementation dependency. The reporting capability is an internal organisational capability.

Legal conformity, internal assurance, and actual security remain different propositions

The existence of a legal conformity framework does not eliminate epistemic uncertainty about security.

Three propositions should remain separate:

• legal conformity asks whether the applicable CRA obligations have been satisfied for the relevant product and manufacturer processes;
• internal assurance asks whether an organisation has sufficient evidence to justify a release, import, integration, procurement, operation, or change decision; and
• actual security concerns how the product behaves against the threats, vulnerabilities, configurations, failures, and adversaries that exist in practice.

Neither conformity assessment nor internal assurance can demonstrate permanent invulnerability.

A cybersecurity risk assessment can omit an attack path.

A penetration test is bounded by:

• time;
• product version;
• configuration;
• test scope;
• attacker model;
• methodology; and
• available knowledge.

An SBOM identifies software relationships but does not establish runtime reachability or secure integration.

A certificate can cease to correspond to the current product state.

A scanner can produce false negatives.

The absence of reported exploitation can reflect the absence of exploitation, but it can also reflect limited visibility or detection.

The CRA responds to this unavoidable uncertainty through lifecycle obligations: vulnerability handling, risk-assessment updates, security updates, support, reporting, corrective action, and continuing conformity. It does not establish a legal fiction that successful conformity assessment proves permanent security.

Assurance can decay without a new locally released executable

The security context surrounding a product can change even when the manufacturer has not released a new local binary.

Examples include:

• a cloud backend changing behaviour;
• a third-party SaaS dependency changing implementation;
• an external API changing authentication requirements;
• an identity provider changing token semantics;
• a certificate authority or trust chain changing;
• a dependency reaching end of support;
• a previously trusted package source being compromised;
• a vulnerability being discovered in an unchanged component;
• threat capabilities changing; or
• customer configuration making a previously unreachable interface externally accessible.

Not all of those events constitute a modification of the CRA product. Some concern external systems outside the product boundary.

They can nevertheless affect the cybersecurity risk assessment, deployment assumptions, evidence validity, or continued-use decision.

That is why the internal assurance model developed in the preceding section uses security-relevant change as a broader review trigger than the statutory definition of substantial modification.

The concept can be expressed as assurance decay: evidence obtained at time t_0 can become progressively less informative about a decision at time t_1 as product state, dependencies, threat information, or operating assumptions diverge from those present when the evidence was generated.

A defensible lifecycle system therefore couples point-in-time evidence with:

• vulnerability monitoring;
• component and dependency monitoring;
• support monitoring;
• product-change control;
• environment-change detection where relevant;
• periodic review of standards and certificates; and
• explicit triggers for reassessment.

SMEs face fixed implementation costs as well as proportionate obligations

The CRA contains proportionality mechanisms, simplified documentation possibilities, specific FOSS treatment, support mechanisms, and protections for smaller organisations. Those mechanisms do not eliminate the existence of fixed technical and organisational capabilities required to place and support a product securely.

ENISA’s 2026 SME CRA survey provides useful—but bounded—evidence about that problem. The survey received 194 responses from 31 countries or geographical groupings, including 25 EU Member States. Among respondents, 66% had heard of the CRA before the survey; incident response and product lifecycle management were the weakest maturity area; more than 70% requested technical-documentation templates and secure-development templates; and 142 respondents identified financial support as a need.²⁰⁷

Those figures describe the survey respondents rather than establishing population-wide estimates for every European SME. The sample nevertheless supports an important distinction: awareness of the Regulation is not equivalent to implementation capacity.

A small manufacturer can still need capabilities for:

• controlled product and source inventories;
• secure build infrastructure;
• signing-key protection;
• reproducible or otherwise traceable release processes;
• cybersecurity risk assessment;
• component due diligence;
• technical documentation;
• independent conformity assessment where required;
• vulnerability intake and triage;
• security-update development and distribution;
• Article 14 readiness;
• multi-year support;
• dependency monitoring; and
• preservation of product knowledge after staff turnover.

Many of those activities have a significant fixed-cost component. The fact that the product volume or organisation is small does not reduce the need for a signing key to be protected, a critical vulnerability to be assessed, or a 24-hour reporting decision to be made.

Open questions should be managed as controlled implementation dependencies

For implementation purposes, an open question should not remain an unowned note in a compliance spreadsheet. It should be converted into a dependency with a monitoring source, responsible owner, decision deadline, and fallback.

Domain	Open question as of 8 August 2026	Required control
Guidance	Has the status, wording, translation, correction, or interpretation of the 27 July guidance changed?	Preserve the relied-upon version and monitor Commission publications and relevant case law
Standards	Which M/606 deliverables have been adopted by the ESOs, assessed by the Commission, and cited in the Official Journal?	Maintain a standards register distinguishing technical availability from Article 27 legal status
Notified bodies	Which bodies are currently notified for the required product scope and conformity module?	Verify current NANDO notification and scope before relying on a provider
Certification	Has a certification scheme been made applicable to the relevant CRA requirements and conformity route?	Verify the enabling act, assurance level, product scope, certificate scope, and validity
Reporting	Is the production SRP operational and are representatives, access, formats, and contingency procedures tested?	Perform a reporting exercise before 11 September 2026
Scope	Does a remote service, FOSS arrangement, component, or complex system fall within the product boundary?	Preserve a case-specific legal and architectural analysis
Modification	Does a change modify intended purpose or affect Annex I, Part I compliance?	Perform documented change-impact and substantial-modification analysis
Dependencies	Has an integrated component or external service changed in a way that affects risk or evidence?	Maintain dependency monitoring and predefined reassessment triggers
Support	Does the support period still reflect expected use and can critical dependencies be supported for that period?	Preserve support reasoning, dependency strategy, migration options, and end-of-support controls
Awareness	When did the manufacturer obtain a reasonable degree of certainty that an Article 14 trigger existed?	Time-stamp incoming evidence, assessment, uncertainty, decision, and escalation
Overlap	Which parallel product, entity, safety, data, AI, sectoral, or liability regimes apply to this product and actor?	Maintain a regime-specific obligation, conformity, authority, and reporting map

Table 7: Controlled CRA implementation questions as of 8 August 2026.

The table is deliberately dynamic. A resolved institutional dependency can become an ordinary configuration item: once a harmonised standard is cited, for example, the question changes from will it exist? to does its scope cover the relevant requirement and product state?

The compliance horizon contains legal deadlines and implementation milestones

The remaining implementation horizon should distinguish dates established by the CRA from delivery dates and roadmap milestones for the surrounding conformity ecosystem.

As of 8 August 2026, the most relevant near-term points are:

• 30 August 2026: requested ESO adoption date for the initial horizontal risk-based-development and vulnerability-handling standards;
• 11 September 2026: Article 14 reporting obligations begin to apply, and the Commission states that the SRP will be operational by that date;
• 30 October 2026: requested ESO adoption date for the CRA product-specific vertical standardisation deliverables;
• Q4 2026: Commission implementation-roadmap milestone for the delegated act addressing CRA presumption-of-conformity treatment of EUCC;
• 11 December 2026: Article 35(2) target by which Member States must strive to ensure a sufficient number of notified bodies in the Union;
• 30 October 2027: requested ESO adoption date for further horizontal Annex I product-property standardisation;
• 11 December 2027: general application of the CRA; and
• 11 June 2028: end of validity of the specified transitional cybersecurity type-examination certificates and approval decisions under Article 69(1), unless they expire earlier or the relevant Union legislation provides otherwise.²⁰⁸

The standardisation and conformity-ecosystem dates are not all equivalent to statutory application dates. The Commission’s implementation roadmap itself describes the first standardisation outputs as Q3 2026 deliverables, the EUCC delegated act as a Q4 2026 milestone, and sufficient conformity-assessment-body notification as a December 2026 implementation milestone.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    NOW[8 Aug 2026<br/>current implementation review]:::product

    H1[/30 Aug 2026<br/>initial horizontal standards<br/>requested ESO adoption/]:::overlay
    REPORT[11 Sep 2026<br/>Article 14 applies<br/>SRP planned operational]:::product
    V1[/30 Oct 2026<br/>vertical standards<br/>requested ESO adoption/]:::overlay
    EUCC[/Q4 2026<br/>EUCC CRA delegated-act<br/>roadmap milestone/]:::overlay
    NB[/"11 Dec 2026<br/>Article 35(2) target<br/>for sufficient notified bodies"/]:::overlay
    H2[/30 Oct 2027<br/>further horizontal standard<br/>requested ESO adoption/]:::overlay
    FULL[11 Dec 2027<br/>general CRA application]:::product
    TRANSITION[11 Jun 2028<br/>specified transitional<br/>certificate endpoint]:::product

    NOW --> H1
    H1 --> REPORT
    REPORT --> V1
    V1 --> EUCC
    EUCC --> NB
    NB --> H2
    H2 --> FULL
    FULL --> TRANSITION

    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef overlay fill:#fff0cf,stroke:#9a6500,stroke-width:1.5px,color:#4d3500;

Figure 17: The CRA compliance horizon combines binding application dates with evolving standards, reporting infrastructure, certification, and conformity-assessment capacity.

The dates in Figure 17 should therefore function as review triggers, not as assumptions frozen into the compliance programme.

For each external implementation dependency, the organisation should know:

• the authoritative monitoring source;
• the responsible owner;
• what decision depends on it;
• the latest date by which the dependency must be resolved;
• what evidence will establish that resolution; and
• what fallback is available if the expected standard, body, certification route, platform feature, or interpretation is delayed or changes.

The CRA’s incomplete implementation ecosystem does not suspend the Regulation and does not justify waiting for perfect certainty. It changes the nature of preparation.

A defensible programme should be able to distinguish what is already legally fixed, what remains an interpretation, what is technically uncertain, what depends on future institutional infrastructure, and what the organisation itself must make operational.

The relevant management principle is therefore:

uncertainty should be controlled as a dependency, not hidden inside a claim of compliance.

Conclusion: from product features to lifecycle accountability

The Cyber Resilience Act changes the way cybersecurity is represented in Union product law. The regulated object remains the product with digital elements, but conformity cannot be reduced to a certificate, a test report, a software release, or the presence of CE marking at one point in time. The CRA connects market placement to cybersecurity risk assessment, applicable essential cybersecurity requirements, conformity assessment, component due diligence, vulnerability handling, support, security updates, reporting, corrective action, and continuing conformity.²⁰⁹

The central change is therefore not that the CRA mandates one new technical control. It changes the allocation and duration of responsibility.

A manufacturer must be able to explain what product it is placing on the market, why the applicable cybersecurity requirements are satisfied, which assumptions and dependencies its assessment relies upon, how vulnerabilities will be handled, how long support will continue, and whether later changes remain within the existing conformity case. Importers and distributors occupy narrower but substantive market-gate and post-market roles. Integrators can become manufacturers when their conduct creates a new product or triggers the CRA’s modification rules. Customers ordinarily remain users, but still need enough product, support, update, and integration information to determine whether a legally conforming product is suitable for their deployment.

The controlled product state developed in this article is not a CRA term and should not be presented as one. It is an internal assurance abstraction for maintaining the relationships that the Regulation makes consequential: product boundary, hardware and software state, security-relevant configuration, intended purpose, dependencies, economic-operator roles, conformity evidence, and lifecycle status.

The Commission’s 2026 guidance reinforces the importance of preserving those relationships. Its treatment of standalone-software placement, product variants, remote data processing, component dependencies, product families, substantial modification, support periods, and vulnerability reporting repeatedly turns on whether the technical and legal facts still correspond to the product being assessed.²¹⁰ The guidance is non-binding, but its practical significance lies precisely in making those boundary conditions explicit.

The resulting compliance logic is recurrent rather than linear. A manufacturer begins by defining the product and its intended purpose. That product determines the relevant scope, classification, cybersecurity risk assessment, and conformity route. The assessment informs architecture, component requirements, secure defaults, update mechanisms, testing, vulnerability-handling processes, and technical documentation. Conformity assessment then supports the EU declaration of conformity and CE marking. Market placement does not terminate the process: vulnerabilities, security updates, support commitments, Article 14 events, dependency changes, and product modifications can require new decisions about the continuing validity of the evidence.

Figure 18 summarises that relationship.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    STATE[Product identity<br/>and legal boundary]:::product
    ROLES[Legal roles and<br/>responsibilities]:::product
    RISK[Cybersecurity<br/>risk assessment]:::product
    DESIGN[Security requirements<br/>components and implementation]:::product
    VERIFY[Verification and<br/>conformity assessment]:::product
    MARKET[EU declaration, CE marking<br/>and market placement]:::product
    LIFE[Support, security updates<br/>vulnerability handling and reporting]:::product

    CHANGE{New vulnerability, dependency<br/>product change or other<br/>relevant information?}:::test
    IMPACT{Does existing evidence<br/>remain applicable?}:::test
    REASSESS[Reassess affected risk<br/>design, evidence or conformity]:::product
    CORRECT{{Correct, restrict<br/>withdraw or recall<br/>where legally required}}:::enforcement

    MFR([Manufacturer]):::entity
    IMP([Importer]):::entity
    INT([Integrator]):::entity
    USER([Customer or operator]):::entity
    NB([Notified body]):::entity
    CSIRT([Coordinating CSIRT<br/>and ENISA]):::entity
    MSA([Market-surveillance<br/>authority]):::entity

    STATE --> ROLES
    ROLES --> RISK
    RISK --> DESIGN
    DESIGN --> VERIFY
    VERIFY --> MARKET
    MARKET --> LIFE
    LIFE --> CHANGE

    CHANGE -- No relevant change --> LIFE
    CHANGE -- Review required --> IMPACT
    IMPACT -- Yes --> LIFE
    IMPACT -- No --> REASSESS
    REASSESS --> RISK
    REASSESS -. unresolved non-conformity .-> CORRECT

    MFR --> STATE
    MFR --> RISK
    MFR --> LIFE

    IMP -. Article 19<br/>pre-market gate .-> MARKET
    INT -. product boundary<br/>integration and change .-> DESIGN
    USER -. deployment suitability<br/>and lifecycle operability .-> LIFE

    NB -. conformity assessment<br/>where applicable .-> VERIFY
    CSIRT -. Article 14<br/>reporting .-> LIFE
    MSA -. surveillance<br/>and enforcement .-> CORRECT

    classDef entity fill:#dbeaf7,stroke:#285f8f,stroke-width:1.5px,color:#102a43;
    classDef product fill:#dff3e8,stroke:#287a57,stroke-width:2px,color:#153b2b;
    classDef test fill:#ffffff,stroke:#4f5962,stroke-width:1.5px,color:#252a2e;
    classDef enforcement fill:#f8dddd,stroke:#9b2f2f,stroke-width:2px,color:#501717;

Figure 18: CRA accountability is recurrent: product identity, legal roles, cybersecurity risk, conformity evidence, support, vulnerabilities, and security-relevant change must remain aligned over time.

The allocation of responsibility within that lifecycle remains role-specific.

For the manufacturer, the critical capability is maintaining a defensible relationship between the product placed on the market and the risk assessment, architecture, component decisions, technical documentation, conformity evidence, support commitment, vulnerability-handling processes, security updates, reporting processes, and later changes that apply to it.²¹¹ Outsourcing individual engineering or operational functions does not transfer those manufacturer obligations.

For the importer, the key control is the Article 19 market gate. It must verify the matters assigned to it before placing a product bearing the name or trademark of a person established outside the Union on the Union market and retain the capacity required for post-market cooperation, corrective action, declaration retention, and access to technical documentation.²¹² It does not become a second manufacturer merely by carrying out those checks.

For an integrator, the important capability is legal and technical boundary control. Because integrator is not a separate CRA economic-operator category, the organisation must determine whether a particular activity remains internal use, constitutes distribution or import, creates a new product for which it is the manufacturer, or substantially modifies an already placed product.²¹³ The answer depends on the actual product and market activity rather than the commercial title used in the contract.

For a customer or operator, the CRA does not ordinarily create a second conformity-assessment obligation. The relevant assurance problem is whether the identifiable product, intended-use assumptions, support horizon, update mechanism, security instructions, remote dependencies, and supplier capabilities are compatible with the intended deployment.²¹⁴ Procurement assurance complements the manufacturer’s statutory conformity case; it does not replace it.

These distinctions expose a final conceptual boundary that matters throughout the article: legal conformity, internal assurance, and actual security are not synonyms.

Legal conformity asks whether the applicable CRA requirements have been satisfied for the relevant product and manufacturer processes.

Internal assurance asks whether an organisation has sufficient, correctly bounded evidence to justify a release, import, integration, procurement, deployment, continued-use, remediation, or retirement decision.

Actual security concerns how the product behaves against the vulnerabilities, adversaries, configurations, failures, and dependencies that exist in practice.

The three are related but none proves the others.

A product can have completed its applicable conformity procedure and later acquire a newly disclosed vulnerability. A valid component certificate can coexist with an insecure downstream configuration. An accurate SBOM can identify a dependency without establishing whether vulnerable functionality is reachable. A risk assessment can become incomplete as the threat environment changes. A remote service can alter behaviour without a new local executable. A support commitment can exist on paper while the operational ability to produce and distribute a secure update fails.

The CRA does not solve this epistemic problem by requiring proof of permanent invulnerability. Instead, it imposes a combination of initial product-security requirements and lifecycle processes intended to make changing cybersecurity conditions governable: risk assessment, vulnerability handling, updates, support, reporting, continuing conformity, and corrective action.²¹⁵

The corresponding organisational capability is reconstructability. When a vulnerability, incident, dependency failure, product change, conformity question, or market-surveillance request arises, a mature organisation should be able to reconstruct from controlled evidence:

• which exact product, version, or configuration is affected;
• what its CRA product boundary is;
• which legal entity occupies each relevant role;
• what intended purpose and risk assumptions apply;
• which components and remote dependencies matter;
• which risk assessment covers the product;
• which conformity procedure and evidence apply;
• what support state remains in force;
• what vulnerability, update, or reporting obligations have been triggered;
• which users or customers are affected;
• what changed; and
• why the resulting release, remediation, continued-use, withdrawal, migration, or retirement decision is defensible.

Reconstructability is not an additional CRA requirement and does not replace any legal test. It is the governance property that allows those tests, obligations, and evidence to remain connected as the product changes.

That is the CRA’s deeper transition. Cybersecurity can no longer be represented adequately as a collection of features attached to a product at release, nor can compliance be represented adequately as a collection of documents produced immediately before CE marking.

For products with digital elements, cybersecurity has become a question of lifecycle accountability: knowing what the product is, who is legally responsible for it, which risks and requirements govern it, what evidence supports its conformity, how long that evidence remains applicable, and what must happen when reality changes.

See also cybersecurity longforms

Operational Technology in the Crosshairs: What the 2025–2026 Attacks Reveal About Industrial Cyber Risk

From exposed PLCs and composable trust failures to an IEC 62443-aligned architecture for constraining operational authority, bounding compromise, preserving safe operation, and restoring trusted control

VEX Standards from First Principles

From software inventories and SBOM evidence to defensible, product-specific vulnerability-exploitability decisions, interoperable VEX exchange, lifecycle governance, and Cyber Resilience Act compliance across CISA, CSAF, CycloneDX, SPDX, and OpenVEX

The December 2025 Cyberattack on Poland’s Energy Sector

A detailed reconstruction of the incident, the malware, and the wider significance for energy and OT security

See also regulation and compliance longforms

Operational Technology in the Crosshairs: What the 2025–2026 Attacks Reveal About Industrial Cyber Risk

From exposed PLCs and composable trust failures to an IEC 62443-aligned architecture for constraining operational authority, bounding compromise, preserving safe operation, and restoring trusted control

VEX Standards from First Principles

From software inventories and SBOM evidence to defensible, product-specific vulnerability-exploitability decisions, interoperable VEX exchange, lifecycle governance, and Cyber Resilience Act compliance across CISA, CSAF, CycloneDX, SPDX, and OpenVEX

The EU Digital Battery Passport: Who Is Affected, What Must Be Done, and When

A practical guide to product scope, organisational responsibilities, data obligations, and the February 2027 deadline

See also posts

Photovoltaic Cybersecurity Is an Authority-Architecture Problem

What the 2026 NTC findings imply for procurement, IEC 62443 design, hardening, and commissioning

Data Is Not the New Oil

What Google's bid for Spirit Airlines' corporate archive reveals about enterprise data in the AI era

When the User Becomes the Exploit

TerminalFix, WeWorm, and why security must survive the failure of its first boundary

Guerra profonda: recensione tecnica e guida all'approfondimento

Sovranità digitale, guerra algoritmica, AI e conflittualità ibrida nel libro di Arturo Di Corinto

Programming Authority Is the Real PLC Security Boundary

Why network reachability, authentication, and controller programming must be treated as separate security states.

A CVE Is Not an Article 14 Report: What Actually Makes a Vulnerability Reportable?

How to distinguish identifiers, severity scores, exploitation signals, product evidence, and the CRA reporting threshold

Footnotes

1. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

2. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 1.1–1.2. European Commission. Official publication

3. European Parliament and Council of the European Union. (2019). Regulation (EU) 2019/1020 on market surveillance and compliance of products. Official Journal of the European Union. Official text

4. European Parliament and Council of the European Union. (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union. Official Journal of the European Union. Official text

5. European Parliament and Council of the European Union. (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. Official Journal of the European Union. Official text

6. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

7. European Parliament and Council of the European Union. (2023). Regulation (EU) 2023/1230 on machinery. Official Journal of the European Union. Official text

8. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

9. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

10. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence. Official Journal of the European Union. Official text

11. European Parliament and Council of the European Union. (2024). Directive (EU) 2024/2853 on liability for defective products and repealing Council Directive 85/374/EEC. Official Journal of the European Union. Official text See also: European Parliament and Council of the European Union. (2026). Corrigendum to Directive (EU) 2024/2853, correcting Article 2(1). Official Journal of the European Union, L 2026/90364. Official corrigendum

12. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 53–58: market surveillance, access to documentation, evaluation, corrective action, and significant cybersecurity risk. Official Journal of the European Union. Official text

13. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 53–58: market surveillance, access to documentation, evaluation, corrective action, and significant cybersecurity risk. Official Journal of the European Union. Official text

14. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

15. European Commission. (2026). C(2026) 5252 final: Communication to the Commission approving the content of the draft Communication — Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), together with the Annex, Section 1.2. European Commission. Official publication

16. European Commission. (2026). C(2026) 5252 final: Communication to the Commission approving the content of the draft Communication — Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), together with the Annex, Section 1.2. European Commission. Official publication

17. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

18. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

19. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

20. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

21. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.1, points 10–16. European Commission. Official publication

22. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.1, points 10–16. European Commission. Official publication

23. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.1, points 10–16. European Commission. Official publication

24. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 2.2–2.4, points 17–25. European Commission. Official publication

25. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 2.2–2.4, points 17–25. European Commission. Official publication

26. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 2.2–2.4, points 17–25. European Commission. Official publication

27. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 2.2–2.4, points 17–25. European Commission. Official publication

28. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

29. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

30. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

31. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 2.2–2.4, points 17–25. European Commission. Official publication

32. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.5, points 26–28. European Commission. Official publication

33. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

34. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.6, points 29–32. European Commission. Official publication

35. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.6, points 29–32. European Commission. Official publication

36. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.7, points 33–39. European Commission. Official publication

37. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.7, points 33–39. European Commission. Official publication

38. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 8.1–8.2, points 184–208. European Commission. Official publication

39. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 8.1–8.2, points 184–208. European Commission. Official publication

40. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 8.1–8.2, points 184–208. European Commission. Official publication

41. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 8.1–8.2, points 184–208. European Commission. Official publication

42. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 8.3. European Commission. Official publication

43. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 8.3. European Commission. Official publication

44. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 8.3. European Commission. Official publication

45. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 8.3. European Commission. Official publication

46. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

47. European Commission. (2025). Commission Delegated Regulation (EU) 2025/1535 supplementing Regulation (EU) 2024/2847 with regard to an exclusion for certain products with digital elements falling within Regulation (EU) No 168/2013. Official Journal of the European Union. Official text

48. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

49. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

50. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.2. European Commission. Official publication

51. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements, Article 3(12)–(17). Official Journal of the European Union. Official text

52. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements, Article 3(12)–(17). Official Journal of the European Union. Official text

53. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 13–14 and Annex I. Official Journal of the European Union. Official text

54. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 18: Authorised representatives. Official Journal of the European Union. Official text

55. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 19: Obligations of importers. Official Journal of the European Union. Official text

56. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 19: Obligations of importers. Official Journal of the European Union. Official text

57. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 19: Obligations of importers. Official Journal of the European Union. Official text

58. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 20: Obligations of distributors. Official Journal of the European Union. Official text

59. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 20: Obligations of distributors. Official Journal of the European Union. Official text

60. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 21–22: Cases in which manufacturer obligations apply to other persons. Official Journal of the European Union. Official text

61. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.4.1, point 120 and Example 51. European Commission. Official publication

62. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.4.1, point 120 and Example 51. European Commission. Official publication

63. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.4.1, points 117–121. European Commission. Official publication

64. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.4.1, points 117–121. European Commission. Official publication

65. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

66. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

67. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

68. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

69. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

70. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

71. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

72. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

73. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

74. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

75. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

76. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

77. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

78. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

79. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

80. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

81. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

82. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

83. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

84. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

85. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 7, 8 and 32 and Annexes III and IV. Official Journal of the European Union. Official text

86. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 6.1, points 136–140. European Commission. Official publication

87. European Commission. (2025). Commission Implementing Regulation (EU) 2025/2392 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847. Official Journal of the European Union. Official text

88. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 6.1, points 136–140. European Commission. Official publication

89. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 6.1–6.2, points 140–152. European Commission. Official publication

90. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 6.1, points 141–144. European Commission. Official publication

91. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 6.1, points 141–144. European Commission. Official publication

92. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 6.1, point 145 and Example 61. European Commission. Official publication

93. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 32: Conformity assessment procedures for products with digital elements. Official Journal of the European Union. Official text

94. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 32(5). Official Journal of the European Union. Official text

95. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 32: Conformity assessment procedures for products with digital elements. Official Journal of the European Union. Official text

96. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 6.2, points 147–152. European Commission. Official publication

97. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 6.1–6.2, points 140–152. European Commission. Official publication

98. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Annex VIII, Part I: Internal control based on module A. Official Journal of the European Union. Official text

99. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Annex VIII, Parts II and III: EU-type examination and conformity to EU type based on internal production control. Official Journal of the European Union. Official text

100. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Annex VIII, Part IV: Conformity based on full quality assurance. Official Journal of the European Union. Official text

101. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 27: Presumption of conformity. Official Journal of the European Union. Official text

102. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 6.3, points 153–154 and following. European Commission. Official publication

103. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 28–30: EU declaration of conformity and CE marking. Official Journal of the European Union. Official text

104. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

105. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

106. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.3: Risk assessment and due diligence in relation to external dependencies and integrated components. European Commission. Official publication

107. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

108. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.2.1, points 222–229: reporting vulnerabilities in integrated components upstream and sharing security fixes. European Commission. Official publication

109. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 3.1: Determining if free and open-source software is under one’s responsibility. European Commission. Official publication

110. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 3.1: Determining if free and open-source software is under one’s responsibility. European Commission. Official publication

111. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 3.2: Determining if free and open-source software is placed on the EU market, including Sections 3.2.1–3.2.7. European Commission. Official publication

112. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 3.2: Determining if free and open-source software is placed on the EU market, including Sections 3.2.1–3.2.7. European Commission. Official publication

113. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 3.2: Determining if free and open-source software is placed on the EU market, including Sections 3.2.1–3.2.7. European Commission. Official publication

114. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 3.2: Determining if free and open-source software is placed on the EU market, including Sections 3.2.1–3.2.7. European Commission. Official publication

115. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 3.2: Determining if free and open-source software is placed on the EU market, including Sections 3.2.1–3.2.7. European Commission. Official publication

116. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 3.2.7 and 3.4: Integration by other manufacturers, contributors, and downstream uses. European Commission. Official publication

117. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 3.3–3.3.1: Open-source software stewards, sustained support, and viability. European Commission. Official publication

118. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 3.3–3.3.1: Open-source software stewards, sustained support, and viability. European Commission. Official publication

119. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.4.1, point 120 and Example 51. European Commission. Official publication

120. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

121. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 4.3 and 5.1: Software updates as substantial modifications and consequences for the support period. European Commission. Official publication

122. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 4.3 and 5.1: Software updates as substantial modifications and consequences for the support period. European Commission. Official publication

123. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.1: Physical repairs. European Commission. Official publication

124. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

125. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.2. European Commission. Official publication

126. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.4.1, points 117–121. European Commission. Official publication

127. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 2.1, points 10–16. European Commission. Official publication

128. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.4.1, points 117–121. European Commission. Official publication

129. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 4.3 and 5.1: Software updates as substantial modifications and consequences for the support period. European Commission. Official publication

130. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 13(15)–(20) and Annex II: Product identification, manufacturer contact, vulnerability contact, user information, support-period disclosure, and declaration of conformity. Official Journal of the European Union. Official text

131. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 31 and Annex VII: Content of the technical documentation. Official Journal of the European Union. Official text

132. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 13(15)–(20) and Annex II: Product identification, manufacturer contact, vulnerability contact, user information, support-period disclosure, and declaration of conformity. Official Journal of the European Union. Official text

133. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 13(15)–(20) and Annex II: Product identification, manufacturer contact, vulnerability contact, user information, support-period disclosure, and declaration of conformity. Official Journal of the European Union. Official text

134. European Commission. (2026). FAQs on the Cyber Resilience Act, version 1.3, Section 6.6: What is the technical documentation? European Commission. Commission-services FAQs (non-authoritative)

135. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 13(19): Support-period information to users. Official Journal of the European Union. Official text

136. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 5, points 125–128. European Commission. Official publication

137. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Annex II, point 8(f): Information for products intended for integration into other products with digital elements. Official Journal of the European Union. Official text

138. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.3, points 167–169. European Commission. Official publication

139. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 13(12)–(14): Technical documentation, conformity assessment, declaration, CE marking, and continuing conformity. Official Journal of the European Union. Official text

140. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 31 and Annex VII: Content of the technical documentation. Official Journal of the European Union. Official text

141. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 13(14): Continuing conformity for products forming part of a series. Official Journal of the European Union. Official text

142. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 19(1)–(4): Pre-market obligations of importers. Official Journal of the European Union. Official text

143. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 19(6)–(8): Document retention, authority cooperation, and manufacturer cessation. Official Journal of the European Union. Official text

144. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

145. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

146. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 211–216: Awareness and reporting obligations. European Commission. Official publication

147. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 211–216: Awareness and reporting obligations. European Commission. Official publication

148. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

149. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

150. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

151. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, point 218: Reporting vulnerabilities originating in integrated components. European Commission. Official publication

152. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 210 and 217: Reporting for earlier and unsupported products and transition into Article 14. European Commission. Official publication

153. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 210 and 217: Reporting for earlier and unsupported products and transition into Article 14. European Commission. Official publication

154. European Commission. (2026). Cyber Resilience Act — Reporting obligations. Shaping Europe’s digital future. Official implementation page

155. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

156. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

157. European Commission. (2026). Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 supplementing Regulation (EU) 2024/2847 by specifying the terms and conditions for applying the cybersecurity-related grounds in relation to delaying the dissemination of notifications. Official Journal of the European Union. Official text

158. European Commission. (2026). Cyber Resilience Act — Reporting obligations. Shaping Europe’s digital future. Official implementation page

159. European Union Agency for Cybersecurity. (2026). Single Reporting Platform (SRP). ENISA. Official guidance and FAQs

160. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

161. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1, points 211–216: Awareness and reporting obligations. European Commission. Official publication

162. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

163. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 9.1: Information to users following reportable vulnerabilities and incidents. European Commission. Official publication

164. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

165. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 53–58: market surveillance, access to documentation, evaluation, corrective action, and significant cybersecurity risk. Official Journal of the European Union. Official text

166. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 53–58: market surveillance, access to documentation, evaluation, corrective action, and significant cybersecurity risk. Official Journal of the European Union. Official text

167. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 53–58: market surveillance, access to documentation, evaluation, corrective action, and significant cybersecurity risk. Official Journal of the European Union. Official text

168. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

169. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

170. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

171. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

172. European Parliament and Council of the European Union. (2024). Directive (EU) 2024/2853 on liability for defective products and repealing Council Directive 85/374/EEC. Official Journal of the European Union. Official text See also: European Parliament and Council of the European Union. (2026). Corrigendum to Directive (EU) 2024/2853, correcting Article 2(1). Official Journal of the European Union, L 2026/90364. Official corrigendum

173. European Parliament and Council of the European Union. (2024). Directive (EU) 2024/2853 on liability for defective products and repealing Council Directive 85/374/EEC. Official Journal of the European Union. Official text See also: European Parliament and Council of the European Union. (2026). Corrigendum to Directive (EU) 2024/2853, correcting Article 2(1). Official Journal of the European Union, L 2026/90364. Official corrigendum

174. European Parliament and Council of the European Union. (2024). Directive (EU) 2024/2853 on liability for defective products and repealing Council Directive 85/374/EEC. Official Journal of the European Union. Official text See also: European Parliament and Council of the European Union. (2026). Corrigendum to Directive (EU) 2024/2853, correcting Article 2(1). Official Journal of the European Union, L 2026/90364. Official corrigendum

175. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

176. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

177. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

178. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 13 and 31 and Annex VII: Cybersecurity risk assessment, manufacturer obligations, technical documentation, and lifecycle updating. Official Journal of the European Union. Official text

179. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 13 and 31 and Annex VII: Cybersecurity risk assessment, manufacturer obligations, technical documentation, and lifecycle updating. Official Journal of the European Union. Official text

180. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.3, points 170–173. European Commission. Official publication

181. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.3, points 169–173. European Commission. Official publication

182. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.4, points 174–177. European Commission. Official publication

183. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.4, points 174–177. European Commission. Official publication

184. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.4, points 174–177. European Commission. Official publication

185. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.3, points 170–173. European Commission. Official publication

186. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.3, points 170–173. European Commission. Official publication

187. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.3, points 169–173. European Commission. Official publication

188. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.3, points 169–173. European Commission. Official publication

189. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Sections 4.4 and 7.4: Reuse of unaffected evidence after modification and across security-equivalent product variants. European Commission. Official publication

190. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.4, points 174–177. European Commission. Official publication

191. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 31(1)–(2): Technical documentation and continuing updates. Official Journal of the European Union. Official text

192. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 7.4, points 174–177. European Commission. Official publication

193. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex. European Commission. Official publication

194. European Commission. (2026). C(2026) 5252 final: Communication to the Commission approving the content of the draft Communication — Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), together with the Annex, Section 1.2. European Commission. Official publication

195. European Commission. (2026). Cyber Resilience Act — Implementation. Shaping Europe’s digital future. Official implementation roadmap

196. European Commission. (2026). Cyber Resilience Act implementation — Frequently asked questions, version 1.3. European Commission. Commission-services FAQs (non-authoritative)

197. European Commission. (2026). Cyber Resilience Act — Standardisation. Shaping Europe’s digital future. Official implementation page

198. European Commission. (2025). Commission Implementing Decision C(2025) 618 final, Annex I: Standardisation request to CEN, CENELEC and ETSI as regards products with digital elements in support of Regulation (EU) 2024/2847. European Commission. Official decision

199. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

200. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

201. European Commission. (2026). Cyber Resilience Act — Conformity assessment. Shaping Europe’s digital future. Official implementation page

202. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

203. European Commission. (2026). Cyber Resilience Act — Implementation. Shaping Europe’s digital future. Official implementation roadmap

204. European Commission. (2026). Cyber Resilience Act — Conformity assessment. Shaping Europe’s digital future. Official implementation page

205. European Commission. (2026). Cyber Resilience Act — Implementation. Shaping Europe’s digital future. Official implementation roadmap

206. European Commission. (2026). Cyber Resilience Act — Reporting obligations. Shaping Europe’s digital future. Official implementation page

207. European Union Agency for Cybersecurity. (2026). SME CRA Survey Report. ENISA. Official report

208. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

209. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text

210. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex. European Commission. Official publication

211. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Articles 13–14 and Annex I. Official Journal of the European Union. Official text

212. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 19: Obligations of importers. Official Journal of the European Union. Official text

213. European Commission. (2026). Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, Section 4.4.1, point 120 and Example 51. European Commission. Official publication

214. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847, Article 13(15)–(20) and Annex II: Product identification, manufacturer contact, vulnerability contact, user information, support-period disclosure, and declaration of conformity. Official Journal of the European Union. Official text

215. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union. Official text