Does the Cyber Resilience Act apply to your product?

If you make hardware, write software, or import either of those into the European Union, you have probably already heard the words "Cyber Resilience Act" thrown around in vendor emails, trade press, and procurement questionnaires. What is harder is getting a clean, defensible answer to one apparently simple question: does the CRA apply to my product, and if it does, what exactly do I have to do? This walks the product-side question; the entity-side companion is Does NIS2 apply to your EU project? .

The reason it is not a one-line answer is that Regulation (EU) 2024/2847 — the formal name of the Cyber Resilience Act (CRA) — is built around five layers of logic that interact:

1. A product test, not an entity test. Unlike the NIS2 Directive, the CRA does not ask whether your company is a particular kind of entity. It asks whether each product with digital elements (PDE) you place on the Union market is in scope (Art. 2(1) ). You can be a "manufacturer" of one product, an "importer" of another, and out of scope entirely for a third.
2. Role-based obligations. Whether you are a manufacturer, authorised representative, importer or distributor changes the duties that apply to you, with the manufacturer carrying the bulk and importers/distributors playing a verification role (Arts. 13, 18, 19, 20 ).
3. A layered classification system. Default products, Important products (split into Class I and Class II) and Critical products each follow a different conformity assessment route (Annexes III and IV ; Art. 32 ).
4. Interaction with sectoral law. Medical devices, motor vehicles, civil aviation and marine equipment are carved out because their own sectoral regimes already address cybersecurity (Art. 2(2)–(4) ; Recitals 25, 27).
5. Special treatment for free and open-source software (FOSS). Non-commercial FOSS is out; "open-source software stewards" face a light-touch regime; commercial FOSS distributors are full manufacturers (Art. 24 ; Recitals 17–19).

Get any one of these layers wrong and you can either overspend on compliance for a product that is exempt, or — far more painfully — under-prepare for a product that needs notified-body assessment and find yourself unable to CE-mark it in time for the 11 December 2027 deadline (Art. 71 ).

The decision tree

flowchart TD
    A[Start: Is your product placed on the EU market in the course of commercial activity?] --> B{Is it a 'product with digital elements'?
i.e. SW/HW + direct or indirect data connection
Art. 3 1}
    B -- No --> X1[Out of scope]
    B -- Yes --> C{Does an Article 2 exclusion apply?
MDR/IVDR, motor vehicles, aviation,
marine, defence/national security,
classified info, qualifying spare parts}
    C -- Yes --> X2[Out of scope of CRA
follow sectoral rules]
    C -- No --> D{Is it FOSS supplied outside of
commercial activity?
Recitals 15-18}
    D -- Yes, non-commercial FOSS --> X3[Out of scope
Steward regime may apply Art. 24]
    D -- No / Commercial --> E{What is your role?
Manufacturer / Authorised Rep /
Importer / Distributor
Art. 3 13-20}
    E --> F{Classify the product:
Default, Important Class I,
Important Class II, or Critical?
Annexes III & IV}
    F -- Default ~90% of PDEs --> G[Self-assessment Module A
possible. Annex VIII]
    F -- Important Class I --> H[Self-assessment IF harmonised
standards/common specs/EU cert
applied; else third-party]
    F -- Important Class II --> I[Third-party conformity
assessment MANDATORY
Module B+C or H]
    F -- Critical Annex IV --> J[European cybersecurity
certification 'substantial'
when mandated by delegated act]
    G --> K[Apply Annex I essential
requirements + vulnerability
handling; determine support
period ≥ 5y Art. 13 8]
    H --> K
    I --> K
    J --> K
    K --> L[Draw up EU DoC Annex V
+ technical docs Annex VII
+ affix CE marking Art. 30]
    L --> M[Stand up Article 14 reporting:
24h / 72h / 14d / 1 month
via ENISA Single Reporting Platform]

    classDef entry fill:#1e88e5,stroke:#0d47a1,color:#fff;
    classDef out fill:#e53935,stroke:#b71c1c,color:#fff;
    classDef high fill:#fb8c00,stroke:#e65100,color:#fff;
    classDef med fill:#fdd835,stroke:#f9a825,color:#000;
    classDef ops fill:#43a047,stroke:#1b5e20,color:#fff;

    class A entry;
    class X1,X2,X3 out;
    class I,J high;
    class F,H med;
    class G,K,L,M ops;

Step 1 — is the product a "product with digital elements"?

The CRA only applies if your product is a "product with digital elements" (PDE) — the gateway test below settles whether you are in scope at all. Under Article 3(1) of the CRA, a PDE is "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately." Article 2(1) restricts the CRA to PDEs "made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network" (Regulation (EU) 2024/2847, Art. 2(1) ).

Three things flow from that definition:

• Hardware and software both count. Embedded firmware, mobile apps, desktop software, IoT devices, industrial controllers — all PDEs (EC summary, Glossary ).
• Components placed separately on the market are PDEs too. A microprocessor sold to integrators is a PDE in its own right, not just the finished product it ends up in (Recital 9).
• Remote data processing solutions designed and developed by, or under the responsibility of, the manufacturer are pulled into the product's scope when the absence of that processing would prevent the product from performing one of its functions (Art. 3(2); Recitals 11–12). Cloud-enabled functionality of a smart-home device is in. Generic SaaS/PaaS/IaaS sold to third parties is governed by NIS2 instead — see Does NIS2 apply to your EU project? .

Use this check:

• My product is hardware or software (or a component of either).
• In normal use or reasonably foreseeable use it makes a logical or physical data connection — directly or indirectly — to another device or network.
• If it relies on a back-end/cloud component that I designed (or had designed on my behalf), I have included that back-end in my scope analysis.

If all three boxes tick: continue to Step 2. A purely analogue product with no programmable digital elements and no connectivity is not a PDE.

Step 2 — does an exclusion apply?

Even if the product is technically a PDE, Article 2 carves out several categories. Walk this list carefully — if your product falls under another EU regime that already addresses cybersecurity, the CRA may step aside.

Sectoral exclusions (Art. 2(2)–(4)):

• Medical devices and IVDs covered by Regulation (EU) 2017/745 (MDR) or Regulation (EU) 2017/746 (IVDR) — out (Art. 2(2); Recital 25).
• Motor vehicles, their systems and components to which Regulation (EU) 2019/2144 on vehicle type-approval applies — out, because UN Regulation No 155 on cybersecurity management systems already does the heavy lifting (Art. 2(3); Recital 27).
• Civil aviation products certified under Regulation (EU) 2018/1139 — out (Art. 2(3); Recital 27).
• Marine equipment within the scope of Directive 2014/90/EU — out (Art. 2(4)).
• Spare parts that are intended to replace identical components in a product already placed on the market, and that are produced according to the same specifications as the part they replace — out (Art. 2(5); Recital 29).

Security and defence exclusions (Art. 2(6)–(7)):

• Products developed or modified exclusively for national security or defence purposes.
• Products specifically designed to process classified information (Recital 26).
• Products developed or modified by a public administration entity exclusively for its own use (Recital 16).

Free and open-source software (Art. 2(8) and Recitals 17–19): FOSS supplied outside the course of a commercial activity is out of scope. See Step 9 for the detailed FOSS analysis — it is a section in its own right.

A practical note on radio equipment. Where your product is a radio device, the cybersecurity-related essential requirements of Article 3(3)(d), (e) and (f) of the Radio Equipment Directive 2014/53/EU, as activated by Commission Delegated Regulation (EU) 2022/30 , already apply. Recital 30 of the CRA confirms that the CRA's essential cybersecurity requirements cover the same ground as RED 2022/30 and that the Commission intends to amend or repeal RED 2022/30 so it ceases to apply to products subject to the CRA during the transition. In the meantime, treat them as overlapping rather than alternative.

If no exclusion applies: continue to Step 3.

Step 3 — who are you? Identify your role under the CRA

Your obligations turn on whether you are a manufacturer, authorised representative, importer or distributor. The definitions come from Article 3:

A few important consequences:

• A distributor who rebrands or substantially modifies a product becomes the manufacturer for CRA purposes (Recital 38; Art. 22 deems certain operators to be treated as manufacturers).
• An online marketplace that only intermediates does not itself become an economic operator; but the same legal entity that sells products through its marketplace can simultaneously be a manufacturer or distributor for those products (Recital 78).
• Where the manufacturer is outside the EU and there is no importer, a written-mandate authorised representative is the right structure for clarity (Art. 18; see "Tips for non-EU manufacturers" below).

Tick your role(s):

• Manufacturer (incl. anyone marketing a product under their own brand, even if a contract manufacturer made it).
• Authorised representative (with a written mandate from a non-EU manufacturer).
• Importer (EU-established, placing a non-EU-branded product on the market for the first time).
• Distributor (further down the chain, not affecting product properties).

Step 4 — classify the product: Default, Important (Class I/II) or Critical

Product classification under the CRA drives which conformity assessment route you must follow, so it is the single decision that most shapes the workload of getting to market. The CRA splits PDEs into four buckets based on cybersecurity risk:

Default products (the residual category)

Everything not listed in Annex III or IV is "default." The European Commission estimates this covers around 90% of all PDEs — household appliances, mobile apps, computer games, smart speakers, memory chips and the like (EC summary ).

→ Self-assessment is allowed via the internal control procedure (Module A) in Annex VIII.

Important products — Class I (Annex III, Part I)

These are PDEs whose core functionality matches a category in Annex III, Part I of the Regulation. The list (paraphrased from the final text of Annex III ) includes:

• Identity management systems and privileged access management (PAM) software and hardware, including authentication and access control readers, including biometric readers
• Standalone and embedded browsers
• Password managers
• Software that searches for, removes or quarantines malicious software
• Products with the function of a virtual private network (VPN)
• Network management systems
• Security information and event management (SIEM) systems
• Boot managers
• Public key infrastructure and digital certificate issuers
• Physical and virtual network interfaces
• Operating systems
• Routers, modems intended for connection to the internet, and switches (not covered by Class II)
• Microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities
• Smart home general-purpose virtual assistants
• Smart home products with security functionalities, including smart door locks, baby monitoring systems and alarm systems
• Internet-connected toys (with social interactive features or location tracking)
• Personal wearable products to be worn on the human body that have a health monitoring purpose (where MDR/IVDR does not apply) and personal wearable products intended for use by children

→ Self-assessment (Module A) is permitted only if the manufacturer applies relevant harmonised standards, common specifications, or a designated European cybersecurity certification scheme covering the essential requirements. Otherwise, third-party conformity assessment is required (Art. 32(2); Recital 91).

Important products — Class II (Annex III, Part II)

A smaller, higher-risk list:

• Hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments
• Firewalls, intrusion detection and intrusion prevention systems
• Tamper-resistant microprocessors and microcontrollers

→ Third-party conformity assessment is mandatory in all cases (Art. 32(3)). Manufacturers may choose between Module B+C (EU type-examination followed by conformity to type) or Module H (full quality assurance), both detailed in Annex VIII (Recital 91).

Critical products (Annex IV)

The final Annex IV lists:

• Hardware Devices with Security Boxes
• Smart meter gateways within smart metering systems and other devices for advanced security purposes, including for secure cryptoprocessing
• Smartcards or similar devices, including secure elements

→ The Commission may, by delegated act, require manufacturers of categories of critical PDEs to obtain a European cybersecurity certificate at assurance level "substantial" or higher under a scheme adopted pursuant to Regulation (EU) 2019/881 (the Cybersecurity Act). Until such a delegated act is adopted, critical products follow the same conformity assessment procedures as Class II important products (Art. 8; Recitals 46–48).

Two practical points:

• Classification follows core functionality, not embedded features. A smartphone is not reclassified as a "password manager" just because it ships with one; an app that embeds a browser engine is not a "browser product" (Commission Implementing Regulation (EU) 2025/2392, Recitals 3–5 ).
• The technical descriptions of every Annex III and IV category were fixed by Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 — the authoritative reference if you are arguing edge cases with a notified body.

Tick your classification:

• Default (residual)
• Important Class I (Annex III, Part I)
• Important Class II (Annex III, Part II)
• Critical (Annex IV)

Step 5 — confirm the essential cybersecurity requirements (Annex I)

Once you know you are in scope, Annex I is the heart of the obligations. It is split into two parts.

Annex I, Part I — product properties

Manufacturers must ensure that the PDE is designed, developed and produced so that it:

• Is delivered without known exploitable vulnerabilities
• Is delivered with a secure-by-default configuration, including the ability to reset to the original state
• Ensures that vulnerabilities can be addressed through security updates, including, where applicable, automatic updates that are clearly notified to users
• Provides protection from unauthorised access by appropriate control mechanisms (authentication, identity or access management)
• Protects the confidentiality of stored, transmitted or otherwise processed data (e.g. via state-of-the-art encryption)
• Protects the integrity of stored, transmitted or processed data and of programs and configuration
• Processes only the data that is adequate, relevant and limited to what is necessary (data minimisation)
• Protects the availability of essential and basic functions, including against denial-of-service attacks
• Minimises its own negative impact on the availability of services provided by other devices/networks
• Is designed to limit attack surfaces, including external interfaces
• Is designed to reduce the impact of an incident through appropriate exploitation mitigation mechanisms
• Provides security-related information by recording and monitoring relevant internal activity (with logs accessible to the user where appropriate)
• Provides the possibility for users to securely and easily remove all data and settings and, where applicable, transfer them to other products

Annex I, Part II — vulnerability handling

For the duration of the support period, manufacturers must:

• Identify and document vulnerabilities and components in the product, including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies
• Address and remediate vulnerabilities without delay, including by providing security updates
• Apply effective and regular tests and reviews of the security of the product
• Once a security update is available, publicly disclose information about fixed vulnerabilities (description, impact, severity, remediation steps)
• Put in place and enforce a coordinated vulnerability disclosure (CVD) policy
• Take measures to facilitate the sharing of information about potential vulnerabilities, including by providing a contact address for reporting
• Ensure that security updates are disseminated free of charge, with advisories alongside, in a timely manner

For industrial products with digital elements (PLCs, RTUs, HMIs, industrial switches, SCADA components), IEC 62443-4-1 and 4-2 are the most defensible practical evidence path for Annex I. The product-side standards IEC 62443-4-1 (secure development lifecycle) and 4-2 (component technical requirements) are designed to demonstrate exactly the secure-by-design, vulnerability-handling and update-management obligations Annex I imposes. ISASecure SDLA and CSA third-party certificates against those parts of 62443 are the kind of evidence a notified body or market surveillance authority can read directly into the Annex I structure. The system-level standards IEC 62443-3-2 and 3-3 extend the same evidence model to integrated control systems, and the management-side standards covered in IEC 62443-2-x round out the operational discipline required for the support-period vulnerability handling above.

Manufacturer tick-list:

• I have a documented cybersecurity risk assessment that justifies which Annex I, Part I requirements apply and how each is met (Art. 13(2); Recital 54). Where a requirement does not apply, the justification is in the technical documentation (Recital 55).
• I produce an SBOM for each product in a commonly used machine-readable format covering at least top-level dependencies (Annex I, Part II; Recital 77).
• I publish a coordinated vulnerability disclosure policy and operate a single point of contact (Art. 13(18); Recital 63).
• Security updates are distinguished from functionality updates where technically feasible (Recital 57) and are provided free of charge (Annex I, Part II).

Step 6 — determine the support period (Article 13(8))

Under Article 13(8), the manufacturer must determine a support period that "reflects the time during which the product with digital elements is expected to be in use." That support period:

• Must be at least five years, unless the product's expected lifetime is shorter — in which case the support period equals that lifetime (Art. 13(8); Recital 60 )
• Must take into account reasonable user expectations, the nature of the product, and other relevant Union law on product lifetimes (Recital 59)
• Must be transparently communicated to users at the time of purchase, including the end-date (month and year) of the support period (Art. 13(19); EC summary )
• Should be longer for products with naturally longer lifetimes — operating systems, routers, motherboards, microprocessors, industrial control systems — where five years would be inadequate (Recital 60)

ADCO (the Administrative Cooperation Group of market surveillance authorities) is empowered to publish statistics and guidance on appropriate support periods by category, and the Commission may adopt delegated acts setting minimum support periods for specific categories (Recital 62).

Tick-list:

• I have set a support period of at least five years, or a shorter justified lifetime, and have documented the rationale.
• The end-date is shown to the buyer at point of purchase and in the accompanying user information (Annex II).
• Vulnerability handling under Annex I, Part II is resourced for the full support period.

Step 7 — reporting obligations under Article 14

Article 14 is the obligation that bites first — it applies from 11 September 2026, more than a year before the rest of the regulation, and it applies to all PDEs on the market, including those placed before 11 December 2027 (Art. 69(3); EC summary ).

Manufacturers must notify, simultaneously, ENISA and the CSIRT designated as coordinator of:

Actively exploited vulnerabilities (Art. 14(2)–(3))

• Early warning — within 24 hours of the manufacturer becoming aware
• Vulnerability notification — within 72 hours, with available information including, where applicable, corrective or mitigating measures
• Final report — no later than 14 days after a corrective or mitigating measure is available

Severe incidents impacting product security (Art. 14(4)–(5))

• Early warning — within 24 hours
• Incident notification — within 72 hours
• Final report — within one month of the 72-hour submission

Notifications are submitted via the CRA Single Reporting Platform, established and operated by ENISA (Art. 16; EC summary ).

Manufacturers must also inform affected users without undue delay of severe incidents, and where applicable of any corrective measures users can deploy (Art. 14(8); Recital 67).

Tick-list:

• I know which Member State CSIRT is my coordinator (typically the CSIRT of the Member State of main establishment).
• I have an incident-response process that can detect, triage and report within 24 hours.
• My SBOM tooling can pinpoint affected products quickly when a new CVE drops.
• I have a comms template ready for user-facing notifications.

Note on micro and small enterprises. Manufacturers that qualify as microenterprises or small enterprises cannot be fined for missing the 24-hour deadline specifically (Art. 64(10)(a); EC summary ). Other obligations still apply.

Step 8 — conformity assessment, declaration and CE marking

Once the essential requirements are met, the manufacturer must run the correct conformity assessment procedure (Art. 32 and Annex VIII), draw up the EU Declaration of Conformity (Annex V), keep the technical documentation (Annex VII), and affix the CE marking (Art. 30).

The procedures from Annex VIII are based on the standard New Legislative Framework modules from Decision No 768/2008/EC :

Documentation tick-list:

• Technical documentation prepared in line with Annex VII: product description, design and manufacture, applied requirements, risk assessment, list of harmonised standards/common specifications applied, test reports, conformity assessment reports, SBOM, vulnerability handling procedures. Kept for at least 10 years after the product is placed on the market or for the duration of the support period if longer (Art. 31).
• EU Declaration of Conformity drawn up per Annex V (or simplified DoC per Annex VI), listing the CRA and any other Union harmonisation legislation that applies.
• CE marking affixed visibly, legibly and indelibly to the product, its packaging, or the accompanying documentation in the case of software, per Art. 30.
• Information and instructions to the user per Annex II accompany the product, in a language easily understood by users in the Member State concerned.

Free and open-source software twist. Manufacturers of important Class I or Class II products that qualify as FOSS may use the internal control procedure (Module A), provided they make the technical documentation publicly available (Art. 32(7); EC summary ).

Step 9 — importer- and distributor-specific obligations

Importer obligations (Article 19)

If you are an EU-established business placing a non-EU-branded PDE on the Union market for the first time, Article 19 lands squarely on you. You must:

• Only place compliant products on the market — products meeting Annex I essential requirements and where the manufacturer has fulfilled Art. 13 obligations (Art. 19(1)).
• Verify before placing the product on the market that:
  • The manufacturer has carried out the appropriate conformity assessment procedure;
  • The manufacturer has drawn up the technical documentation;
  • The product bears the CE marking;
  • The product is accompanied by the EU Declaration of Conformity and the information and instructions required by Annex II in a language easily understood by users in the Member State where the product is placed.
• Indicate on the product, its packaging or in accompanying documents your name, registered trade name or registered trademark and a postal address, plus an email or digital contact point (Art. 19(3)).
• Not place the product on the market if you have reason to believe it does not conform with the CRA — and inform the manufacturer and the relevant market surveillance authorities (Art. 19(4)).
• Ensure storage and transport conditions while the product is under your responsibility do not jeopardise compliance with Annex I (Art. 19(5)).
• Inform the manufacturer and market surveillance authorities if you become aware of a vulnerability, and cooperate to remedy it (Art. 19(6)).
• Keep a copy of the EU Declaration of Conformity available to market surveillance authorities for 10 years after the product is placed on the market, or for the support period if longer (Art. 19(8)).
• Cooperate with market surveillance authorities on any reasoned request, in a language they can easily understand (Art. 19(9)).

Distributor obligations (Article 20)

Distributors must "act with due care" in relation to the CRA. In practice, Article 20 requires you to:

• Verify the product bears the CE marking before making it available on the market.
• Verify the manufacturer and importer have complied with their identification, contact-information and documentation obligations (name on product, accompanying instructions, support-period information).
• Ensure storage and transport conditions under your responsibility do not jeopardise compliance.
• Not make available any PDE you have reason to believe is non-compliant — and inform the manufacturer/importer and authorities.
• On becoming aware of a vulnerability, inform the manufacturer and cooperate to ensure that the manufacturer takes corrective action.
• On reasoned request, provide the market surveillance authority with all the information and documentation in your possession.

A distributor or importer who modifies the product or places it on the market under their own name effectively becomes the manufacturer for that product, with the full Article 13 stack of obligations (Art. 22).

Step 10 — market surveillance and penalties

Each Member State designates one or more market surveillance authorities (MSAs) to enforce the CRA — these may be the same authorities competent under NIS2 or under the Radio Equipment Directive (Recital 107). The procedural rules of Regulation (EU) 2019/1020 apply, supplemented by Chapter V of the CRA (EC summary, Chapter V ).

MSAs can:

• Require operators to bring a product into compliance, restrict availability, withdraw or recall it (Arts. 54–57).
• Carry out joint activities and "sweeps" across Member States (Recital 114).
• Escalate via a Union safeguard procedure when non-compliance has cross-border implications (Recital 110).

The financial penalties under Article 64 are deliberately set at GDPR-style levels:

Source: Regulation (EU) 2024/2847, Article 64

Two carve-outs to know:

• Microenterprises and small enterprises cannot be fined specifically for missing the 24-hour early-warning deadlines in Article 14 (Art. 64(10)(a)).
• Open-source software stewards are excluded from administrative fines for any CRA infringement (Art. 64(10)(b); EC summary ).

In addition to fines, MSAs may order withdrawal, recall, or a ban on making the product available — which for many manufacturers is the more painful consequence.

Step 11 — key dates and transitional provisions

The CRA's timeline is staged in Article 71 and the transitional provisions of Article 69:

Legacy products (Article 69(2)–(3)):

• Products placed on the market before 11 December 2027 are not retroactively subject to the bulk of CRA obligations — unless they undergo a substantial modification after that date, in which case they must be re-assessed (Art. 69(2); Recitals 38–39).
• Reporting obligations under Article 14 apply to all in-scope products on the EU market, including legacy products, from 11 September 2026 (Art. 69(3); EC summary ).

Substantial modification is defined functionally: a software or hardware change that modifies the intended purpose, changes the nature of the hazard or increases the cybersecurity risk, and was not foreseen in the original risk assessment (Recital 39). A security update that only reduces risk without changing intended purpose is not a substantial modification.

Free and open-source software: the special regime

The CRA's treatment of FOSS is the area where lawyers and engineers most commonly trip up. Three regimes coexist:

1. Out of scope: non-commercial FOSS

FOSS that is not "made available on the market" — i.e. not supplied for distribution or use in the course of a commercial activity — is out of scope (Art. 2(1) read with Recitals 15–18).

The Commission's recitals are explicit that:

• Mere financial support from manufacturers, or contributions to a FOSS project's development, does not by itself make the project a commercial activity (Recital 18).
• The presence of regular releases does not by itself make the activity commercial (Recital 18).
• FOSS by not-for-profits whose earnings (after costs) are used for not-for-profit objectives is not a commercial activity (Recital 18).
• Individuals contributing code to FOSS projects that are not under their responsibility are not within scope (Recital 18).
• The mere act of hosting code on a repository, package manager or collaboration platform is not "making available on the market" (Recital 20).

2. The "open-source software steward" regime (Article 24)

A new concept introduced by the CRA. An open-source software steward is a legal person, other than a manufacturer, that systematically provides sustained support for the development of specific FOSS products intended for commercial activities and ensures the viability of those products. Foundations and certain not-for-profit bodies that govern key FOSS projects typically fit here (EC summary ; Recital 19).

Stewards face a light-touch, tailored regime under Article 24:

• Have a documented cybersecurity policy promoting secure development and effective vulnerability handling
• Cooperate with market surveillance authorities and take corrective actions as needed
• Notify actively exploited vulnerabilities (to the extent of their involvement in development) and severe incidents (to the extent that they affect the systems used for development)

Stewards do not CE-mark products and are exempt from administrative fines under Article 64(10)(b).

3. Commercial activity around FOSS triggers full manufacturer obligations

If you monetise a FOSS product — by charging a price (other than to recover actual costs), by intentionally extracting value through bundled paid services, by requiring personal-data processing for purposes other than security or compatibility, or by integrating it into your own monetised PDE — then you are a manufacturer for that product and the full Article 13 stack applies (Recitals 15–19).

The Commission has committed in Recital 6 to issuing guidance specifically on how the CRA applies to FOSS, and the Open Regulatory Compliance Working Group hosted by the Eclipse Foundation is producing community-developed materials in parallel.

Practical tips for non-EU manufacturers

If you are headquartered outside the EU and your product reaches the Union market — whether you ship it directly, through a subsidiary or via a distributor — these are the points that catch out the unwary.

Appoint an authorised representative (Article 18)

Where there is no EU-established importer for your product, or where you simply want a clear point of legal contact in the Union, you can appoint an authorised representative by written mandate (Art. 18). The mandate must permit the representative to:

• Keep the EU Declaration of Conformity and technical documentation at the disposal of MSAs for 10 years (or the support period if longer)
• Cooperate with MSAs on any action to eliminate cybersecurity risks
• Terminate the mandate if the manufacturer acts contrary to its CRA obligations, and inform the MSAs

The CRA expressly contemplates that the authorised representative is not the manufacturer's deputy for product design — Annex I obligations remain with the manufacturer — but they are the formal Union interface.

Documentation in EU languages

Information and instructions to the user (Annex II) must be provided in a language easily understood by users in the Member State where the product is placed on the market. Importers and distributors are expressly required to verify this is the case before placing or making available the product (Arts. 19(2), 20). Plan translations early — they are a significant cost driver, especially for SMEs (Recital 94).

Single point of contact for vulnerability reporting

Article 13 requires manufacturers to designate a single point of contact for users to report vulnerabilities, and to make it easily accessible (Recital 63; Annex I, Part II). For non-EU manufacturers, this is often where the authorised representative comes into play. Automated tools alone are not sufficient — provide a phone number, email or contact form too.

Talk to your importers and distributors now

Importers will be asking, as of 11 December 2027, to see evidence of your conformity assessment, your EU DoC and your Annex VII technical file before they can lawfully place your product on the market (Art. 19). Build that evidence pack into your standard product launch process.

Interaction with other EU product legislation

The CRA does not live in isolation. Map your obligations across these neighbouring regimes:

• Radio Equipment Directive 2014/53/EU and Delegated Regulation (EU) 2022/30 — Cybersecurity essential requirements for certain radio equipment. The Commission has signalled that the CRA covers the same ground; expect Delegated Regulation 2022/30 to be amended or repealed in line with the CRA transition (Recital 30).
• NIS2 Directive (EU) 2022/2555 — Operator-side cybersecurity for essential and important entities. If your customers are NIS2-regulated, their supply chain security obligations (Art. 21(2)(d) NIS2) will flow contractual cybersecurity demands back to you. ICT product security at the operator side can require stricter requirements than the CRA's baseline (Recital 13). The entity-side walkthrough is in Does NIS2 apply to your EU project? .
• AI Act — Regulation (EU) 2024/1689 — For PDEs that are also high-risk AI systems, Article 15 of the AI Act's cybersecurity requirements are deemed satisfied where the CRA's essential requirements are met, with the conformity assessment under AI Act Article 43 applying as a rule (Recital 51).
• GDPR — Regulation (EU) 2016/679 — Where products process personal data, GDPR applies in parallel. Annex I, Part I includes data minimisation requirements that overlap with GDPR's data protection by design and by default (Recital 32).
• Machinery Regulation (EU) 2023/1230 — Connected machinery must satisfy both regimes. The Commission and European Standardisation Organisations are working to align harmonised standards across both (Recital 53).
• MDR/IVDR (Regulation 2017/745 and 2017/746 ) — Medical devices and IVDs are out of scope of the CRA, but the MDR/IVDR essential requirements already cover cybersecurity (Recital 25).
• Type-approval regimes (motor vehicles, aviation, marine) — As covered in Step 2.
• Product Liability Directive (EU) 2024/2853 — Strict liability for damages caused by a lack of safety, including security updates. CRA obligations effectively define the floor of what "safe" means for digital products (Recital 31).

Recent developments to watch in 2026

• Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 fixed the technical descriptions of the Annex III and Annex IV product categories, removing much of the early ambiguity over what counts as a "browser" or a "smart-home product with security functionality" (EUR-Lex ; EC summary ).
• Commission Delegated Regulation (EU) 2025/1535 of 29 July 2025 carved out certain L-category vehicles (under Regulation (EU) 168/2013) from CRA scope (EUR-Lex ).
• The Commission published a working CRA implementation FAQ in December 2025 (linked from the EC CRA summary page ).
• Harmonised standards are being produced under a standardisation request to CEN-CENELEC JTC 13 and ETSI, with the first deliverables expected to land in Q3 2026 ahead of the December 2027 application date. Watch the Official Journal for citations — until those references are published, manufacturers of Class I important products will not be able to rely on a presumption of conformity via standards alone (Recital 80).
• ENISA is building the CRA Single Reporting Platform that will be the single notification end-point for the Article 14 deadlines from 11 September 2026 (EC summary, Chapter II ).
• Manufacturers should also follow the NANDO database for the progressive notification of CRA notified bodies, which Member States are required to designate from 11 June 2026 onwards.

A consolidated checklist

Print this. Pin it on the wall.

• Step 1: Confirmed the product is a PDE (Art. 3(1)) — software/hardware with intended or reasonably foreseeable direct or indirect data connection.
• Step 2: Checked all Art. 2 exclusions (MDR/IVDR, motor vehicles, aviation, marine, defence, classified, qualifying spare parts).
• Step 3: Identified my role(s): manufacturer / authorised representative / importer / distributor (Art. 3(13)–(16)).
• Step 4: Classified the product against Annex III/IV using core functionality and Implementing Regulation (EU) 2025/2392.
• Step 5: Mapped Annex I, Parts I & II to the product, with a documented risk assessment.
• Step 6: Set a support period of at least 5 years (or justified shorter lifetime) per Art. 13(8); end-date visible to buyers.
• Step 7: Stood up the Article 14 reporting workflow (24h / 72h / 14d / 1 month) — ready by 11 September 2026.
• Step 8: Run the correct Annex VIII module; drawn up the Annex V DoC and Annex VII technical documentation; affixed CE marking per Art. 30.
• Step 9 (importers): All Art. 19 verification, identification and cooperation duties met. (Distributors: Art. 20 due-care duties met.)
• Step 10: Risk-rated penalty exposure under Art. 64 and modelled it against worldwide turnover.
• Step 11: Plotted Art. 71 dates into the product roadmap (11 June 2026, 11 September 2026, 11 December 2027); identified legacy SKUs and substantial-modification triggers.

If every box is ticked with the supporting evidence on file, you are CRA-ready — and you can prove it. And if your organisation (rather than only your product line) operates services that might fall under NIS2, work the entity-side checklist next: Does NIS2 apply to your EU project? .