The Commission’s Cyber Resilience Act guidance

Communication C(2026) 5252, published by the European Commission on 27 July 2026. This page reflects that text as read on 31 July 2026.

On 27 July 2026 the European Commission published its official guidance on applying the Cyber Resilience Act: Communication C(2026) 5252, about 84 pages, 67 worked examples, written explicitly for small and medium companies. The Commission publishes the PDF at ec.europa.eu/newsroom/dae/redirection/document/131456. It is not binding, but it is the Commission's own interpretation of the law. Market surveillance authorities will read it the same way you are about to (§6, §8).

This is a plain-language digest for people who build things. The § numbers refer to the numbered points of the guidance, so you can check every claim against the source.

What this page is not: the guidance itself, a substitute for reading it, or legal advice. Where this page and the Communication disagree, the Communication is right.

The Communication is a European Commission document, © European Union. It is summarised and reworded here, so changes have been made. Reuse of Commission documents is allowed under Commission Decision 2011/833/EU and the Creative Commons Attribution 4.0 International licence, on the condition this sentence discharges: name the source and say what changed.

Dates

• 11 September 2026. Reporting obligations start. If a vulnerability in your product is actively exploited, or a severe incident hits your product's security, you must notify your national CSIRT and ENISA within 24 hours of becoming aware (§209, §215).
• 11 December 2027. The full regulation applies: essential requirements, technical documentation, CE marking, conformity assessment.
• 11 June 2028. Existing EU type-examination certificates covering cybersecurity (for example under the Radio Equipment Directive delegated act) remain usable as CRA evidence until this date at the latest (§247, §249).

The September 2026 reporting duty applies to all in-scope products, including products you placed on the market before December 2027. It continues after your support period ends (§210). Products placed before December 2027 do not owe the full vulnerability-handling process of Annex I Part II, but they are inside the reporting regime.

Which products are in scope

• Software that runs on the user's machine is in scope. That includes desktop apps, mobile apps, browser extensions and apps built with web technologies but packaged for local install, so Electron and Tauri apps count (§20, Examples 3 and 4).
• A web app used only through the browser is not a product with digital elements. Pure SaaS accessed via browser and websites fall outside, unless they support the functioning of a product that is in scope (§21, Examples 5 and 6).
• Source code can be a product. If you licence source code to a customer, you placed a product on the market, even if they still have to compile it (§24, Example 7). Sharing code on a public repo, unfinished code and demo or tutorial code is generally not placing (§23).
• Hardware plus its companion app is one product. If the device needs the app or driver to fulfil its purpose, they are a single product even when the app ships through an app store later (§25, Examples 8 and 9). Their placing on the market happens together.
• "Data connection" means deliberately encoded digital information. A sensor that just switches an output on and off, without a sender encoding symbols and a receiver decoding them, is not connected in the CRA sense and is out of scope (§28).

When is your product "placed on the market"?

For standalone software, all copies of a version count as placed on the day you first offer that version, no matter when each customer downloads it (§13, §14, Example 1). Updates that are not substantial modifications do not move that date (§15, Example 2). But builds for different operating systems, or bundles with different feature sets, are distinct products, each with its own placing (§14).

Products designed before the CRA: no forced redesign

If your product was designed before the CRA applies and you keep selling it after December 2027, you do not have to redesign it. You have to run the cybersecurity risk assessment. If it shows your existing measures already address the risks, you rely on them (§33, §34). You do not have to recreate historical design or test documentation that never existed (§38, Example 12). You do still owe the full paperwork: conformity assessment, EU Declaration of Conformity, CE marking, technical documentation and the vulnerability-handling process (§35, §39).

Open source: when charging puts you in scope

What matters is whether access to the software is conditioned on payment, not how the project is financed.

• Charging for binaries: placed on the market, you are a manufacturer (§51).
• A paid edition or enterprise version with support or optimisation included: placed, even if a functionally equivalent free version exists (§57, Example 17).
• Free community version next to a paid version: the community version is not placed. If you are a legal person, you are its "steward" with lighter obligations; if you are an individual, it is fully out of scope (§52, §53).
• Donations: fine, even if they exceed your costs. A donation link is not an intention to profit (§61, Example 20). It flips only when donations become a de facto paywall: releases, updates, or binaries only for donors (§62, Examples 21 and 22).
• Paid consultancy or training around a freely downloadable tool: not placing (§56, Example 18). An individual charging enough to cover costs and reasonable living expenses: still not placing (§58).
• Corporate sponsorship or paid feature development does not put the maintainer in scope (§63 to §65, Example 23).
• Contributors are out. Submitting a merged pull request creates no CRA obligations; responsibility sits with whoever controls releases and governance (§49, Example 13).
• If you integrate FOSS into your commercial product, the component's compliance is not your problem, but due diligence on it is. You must report vulnerabilities you find upstream and share your fixes with the maintainer (§86, §88, §222).

Software updates: which ones re-trigger conformity assessment

A substantial modification makes the updated software a newly placed product. The guidance gives this test (§110). Ask whether the update:

• introduces new threat vectors (new interfaces, channels, execution environments, dependencies),
• enables new attack scenarios,
• makes existing attack scenarios more likely,
• or makes their impact worse.

If the answer is no on all four and your original risk assessment still holds, it is not substantial (§111).

• Security updates are generally not substantial modifications, even large ones, as long as they do not change the product's purpose or add new risk (§108, Examples 46 to 48).
• Features you already foresaw in your risk assessment are not substantial when you later ship them (§106, Examples 42 and 43).
• Small features can be substantial. The guidance's own example: adding a "remember me" persistent login that stores tokens locally introduces token-theft risk you never assessed. That makes it a substantial modification (§107, Example 44). Scale of the diff is irrelevant; change in risk is everything.
• When you do ship a substantial modification, you re-assess only the modified parts and reuse existing documentation and tests for the rest (§123).

Support period: five years is the minimum

You set the support period from the product's expected use time. Five years is the minimum unless genuinely shorter use is demonstrable. Products expected to live longer must get more (§126). You must state the end date, at least month and year, at the time of purchase (§127). For fast-moving software there is a real concession: you may patch only the latest version, provided users can upgrade to it free of charge and without buying new hardware or rebuilding their environment (§129 to §131, Example 53). A substantial modification does not reset the support clock unless it changes what determined the product's lifetime in the first place (§133, §134).

Reporting: what actually counts as a reportable vulnerability

• A CVE in your dependency tree is not a reportable event. You report a vulnerability only when it is actively exploited in your product. A vulnerability in a third-party component that is unreachable in your build, or simply has not been exploited in your product, is not subject to mandatory reporting. You may report it voluntarily. You must still fix it under your vulnerability-handling process and you must tell the component's maintainer (§218).
• The clock starts at "becoming aware", which the guidance defines as having a reasonable degree of certainty after an initial assessment, aligned with how NIS2 and GDPR practice already read it (§212, §213). Then: early warning within 24 hours, fuller notification within 72 hours, final report within 14 days after a fix exists (for vulnerabilities) or one month after the 72-hour notification (for incidents) (§215).
• No retroactive reporting. Exploitation you already knew about before 11 September 2026 does not have to be reported. But a vulnerability you knew about that only starts being exploited after that date becomes reportable then (§217).
• "Known exploitable vulnerabilities" at release: known means listed in public databases like the EU vulnerability database, or reported to you directly, or prominently covered in media (§233, §234). Whether you can still ship with one open is a risk decision you must be able to defend. The guidance explicitly lets you weigh the risk of delaying a release that also fixes other problems (§237).
• Informing users is risk-based: you may limit technical detail to affected customers while a fix is pending, with broader disclosure once it is addressed (§220, §221).

Classification: core functionality decides the category

Whether you fall in the "important" or "critical" categories (with heavier conformity assessment) depends on your product's core functionality, the thing without which it cannot meet its purpose (§139). Integrating an important component does not make your product important: a smartphone does not become an operating system by containing one (§141, Example 58). But if you also sell that module separately, the module is its own product and classifies on its own (§145, Example 61). And you cannot market your way out: describing your SIEM as a "log viewer" while the technical documentation says otherwise is exactly what §143 forbids.

Cloud backends: the two question test

Your product's "remote data processing solutions" are part of the product. The guidance reduces it to two cumulative questions (§202). Would its absence prevent a function of the product from working? Was the software designed and developed by you or to your specification? Both yes: it is part of your product and your conformity assessment. Function yes but third-party software (a SaaS you merely integrate): treat it as a component, assess the integration risk, exercise due diligence (§200, §201). Telemetry collected purely for statistics or future development: neither (§192). Backend systems your product never talks to directly are out, even when a function depends on them downstream; you mitigate at product level instead (§205, banking example in 8.3.1).

What to check for your product

• Decide whether you are in scope at all (the browser test in §20 and §21 settles most software cases).
• List which of your shipped products fall under the September 2026 reporting duty. Remember §210: everything in scope, including legacy.
• Put a "becoming aware" procedure on paper: who assesses a report and when the 24-hour clock starts (§213).
• Check your dependency alerts against §218 before wiring them to a reporting workflow. Exploited in your product is the bar, not present in your SBOM.
• Write down your support period and its end date. It goes on the product page (§127).