The CRA Gets Its Instruction Manual: What the Commission Guidance Means for You

The Cyber Resilience Act has had its text since late 2024. What it lacked was an instruction manual. On March 3, 2026, the European Commission published exactly that: draft Communication Ares(2026)2319816 — roughly 70 pages of practical guidance on how to interpret the regulation.

This is the Article 26 guidance the industry has been waiting for. Here is what it says and what it means for you.

Introduction

Draft Communication Ares(2026)2319816, dated March 3, 2026, is the European Commission's first comprehensive guidance document on the Cyber Resilience Act. At roughly 70 pages, it covers the questions that have kept compliance teams up at night: What counts as "remote data processing"? Do legacy products need full redesigns? When does a software update become a new product?

This article distils the nine most consequential rulings into practical guidance for manufacturers, importers, and distributors of products with digital elements.

1. SaaS and Cloud: The RDPS Test

The Commission introduces a strict three-question test to determine whether a cloud or SaaS component qualifies as "remote data processing solutions" (RDPS) and therefore falls within the product's conformity scope.

flowchart TD
    A["Does the solution process data
'at a distance'?"] -->|No| B["Not RDPS"]
    A -->|Yes| C["Would the product lose a core function
without this solution?"]
    C -->|No| D["Not RDPS
(treat as component,
do due diligence per Art 13(5))"]
    C -->|Yes| E["Designed by or under the
responsibility of the manufacturer?"]
    E -->|No| F["Not RDPS
(third-party SaaS = component,
do due diligence per Art 13(5))"]
    E -->|Yes| G["RDPS: within the product's
conformity assessment scope"]

The guidance illustrates this with five concrete scenarios: a banking app, a smart thermostat, an e-Reader, an industrial robot, and a cellular network device.

2. Legacy Products

Products already on the EU market before December 2027 do not need to be redesigned from scratch. But they are not exempt either.

The Commission clarifies three things:

No historical reconstruction required. You do not need to recreate development documentation from years ago. What matters is a present-day cybersecurity risk assessment demonstrating the product meets essential requirements based on its intended purpose.

Product families can be grouped. If multiple legacy products share the same architecture and risk profile, you can perform a single risk assessment covering the family rather than assessing each SKU individually.

Full conformity still applies. Legacy products still need CE marking, a Declaration of Conformity, and active vulnerability handling going forward. The relief is on documentation history, not on the obligations themselves.

For a detailed walkthrough of the conformity assessment process, see our Conformity Assessment Decision Guide. For support period planning on legacy products, see Support Period Planning.

3. Software and "Infinite Copies"

When is software "placed on the market"? The Commission confirms: once. The initial digital distribution constitutes placement. Subsequent minor updates (e.g., v1.0.0 to v1.0.1) do not reset the regulatory clock.

This applies specifically to standalone software distributed digitally. Hardware products with embedded software follow standard physical-goods placement rules.

4. When Updates Become "Substantial Modifications"

This section is the most actionable part of the entire guidance. The Commission provides concrete examples distinguishing routine updates from changes that trigger a new conformity assessment.

The Commission suggests four questions every manufacturer should ask before releasing an update:

1. Does the update introduce new threat vectors?
2. Does it enable new attack scenarios?
3. Does it change the likelihood of existing attack scenarios?
4. Does it change the impact of existing attack scenarios?

If the answer to any of these is yes, the update likely constitutes a substantial modification requiring a new conformity assessment.

For more on product classification and how it interacts with modifications, see our Product Classification Guide.

5. Open Source Rules

The guidance provides several important clarifications on how the CRA applies to open-source software:

• Publishing source code on public repositories does not constitute "placing on the market." The CRA applies at the point of commercial distribution, not at the point of code availability.
• Community edition vs. paid edition = different products. If you offer a free community version and a paid commercial version, only the paid version triggers manufacturer obligations.
• Donations alone do not make FOSS commercial — unless access to the software is conditioned on donating. Voluntary donations are explicitly excluded.
• Not-for-profit entities whose surplus goes entirely to not-for-profit objectives are exempt from manufacturer obligations, even if they monetize.
• Contributors without control over releases, roadmap, or governance are NOT considered manufacturers — even if they have commit access. Responsibility lies with whoever controls the release process.
• Open source steward obligations scale with the level of support provided. Non-technical stewardship carries lighter obligations than full commercial support.

For related guidance on coordinated vulnerability disclosure in open-source contexts, see our CVD Policy Template.

6. Support Period: Five Years Is a Floor

The Commission makes clear that the default five-year support period is a minimum, not a target. Products expected to remain in use for longer than five years must have proportionally longer support periods.

The guidance also clarifies the Article 13(10) path: manufacturers can stop patching older versions if users can upgrade free of charge to a supported version. "Additional costs" in this context means mandatory hardware purchases — routine testing, reconfiguration, or deployment effort on the user's part does not qualify.

For detailed planning strategies, see our Support Period Planning guide.

7. Risk Assessment: Internal Risk Appetite Is Irrelevant

The Commission is unambiguous: risk assessments under the CRA must be based on objective cybersecurity criteria, not on the manufacturer's internal risk appetite. Specifically:

• Commercial strategy and cost considerations do not factor into cybersecurity risk assessment.
• You cannot transfer cybersecurity risk to users through documentation, disclaimers, or terms of service.
• If identified risks cannot be addressed through technical or organisational measures, the product may need design changes before it can be placed on the market.

This is a significant statement. It means a manufacturer cannot knowingly ship a product with unmitigated cybersecurity risks simply because the business has "accepted" that risk.

For an overview of compliance cost implications, see our Compliance Cost Estimation guide.

8. Known Exploitable Vulnerabilities

The guidance clarifies what "known" means in the context of the CRA's requirement to ship products without known exploitable vulnerabilities:

• Listed in public databases: EU Vulnerability Database, CVE/MITRE, NVD.
• Disclosed via non-public channels: coordinated vulnerability disclosure programs, internal security testing, third-party penetration testing.
• Prominently reported in reliable media outlets: a major vulnerability covered by mainstream cybersecurity publications qualifies as "known."

Manufacturers get a limited investigation window to confirm whether a reported vulnerability actually applies to their product. But "investigation" is not a loophole — the clock runs from awareness, and delays will be scrutinised.

For practical guidance on vulnerability documentation, see our VEX Guide.

9. Reporting Obligations (September 2026)

The September 2026 reporting obligations are the first CRA deadline with real enforcement teeth. The guidance confirms the timeline structure:

• 24 hours: Early warning to ENISA after becoming aware of active exploitation
• 72 hours: Detailed notification with technical indicators
• 14 days: Final report for vulnerabilities / 30 days for incidents

"Aware" means reasonable certainty after an initial assessment — not full forensic confirmation. If you have credible evidence of active exploitation, the clock is ticking.

On user notification: the Commission confirms this should be risk-based and proportionate. There is no mandatory public disclosure requirement if disclosure would increase security risk.

For a full walkthrough of the reporting process, see our ENISA 24-Hour Reporting guide. For the complete compliance timeline, see our Implementation Timeline.

What This Means for You

This guidance does not change what the CRA requires. But it changes how much guesswork is involved. Manufacturers now have concrete tests (RDPS), concrete examples (substantial modifications), and concrete timelines (reporting) to work with.

Three immediate actions:

1. Run the RDPS test on every cloud service your product depends on. CRA Evidence automates this assessment as part of its product risk analysis.
2. Review your update process against the four substantial-modification questions. Build them into your release checklist.
3. Prepare for September 2026 reporting. Internal triage processes, escalation paths, and report templates need to be in place before the deadline.

The feedback period is open via the Better Regulation portal. If you have views on the guidance, now is the time.

For a step-by-step approach to CRA readiness, see our Startup Compliance Guide.

This article is based on draft Communication Ares(2026)2319816, dated March 3, 2026. This guidance has not yet been formally adopted by the European Commission and will be finalised once all EU language versions are available.