New — published 27 July 2026

EU Commission Guidance on the EU CRA

The European Commission's official interpretation at a glance — published 27 July 2026 (C(2026) 5252 final)

Document published: 27 July 2026 · Summary last reviewed by Kunnus: 28 July 2026

84

pages

9

chapters

67

practical examples

Not

legally binding

Download the original guidance as PDFEuropean Commission — C(2026) 5252 final, 27 July 2026, 84 pages (English)

What is the EU Commission guidance on the Cyber Resilience Act?

On 27 July 2026, the European Commission published its guidance on the application of the Cyber Resilience Act (C(2026) 5252 final). Article 26(1) of the EU CRA requires the Commission to publish this guidance — with a particular focus on facilitating compliance for small and medium-sized enterprises. It follows consultation of the Expert Group on Cybersecurity of Products with Digital Elements and a public consultation (March–April 2026).

The document clarifies the questions most disputed in practice: When is standalone software 'placed on the market'? When does open source fall within scope? When is a software update a substantial modification? How is the support period determined? And what counts as remote data processing? This page summarises every chapter — linked to the affected CRA articles, recitals and annexes in our knowledge base.

1

Chapter 1: Introduction

Section 1.1 – 1.2

Introduction: legal framework and purpose of the guidance

Chapter 1 situates the document: the CRA is built on the EU's New Legislative Framework; market surveillance and enforcement lie with national authorities. The guidance fulfils the mandate of Article 26(1) — with a particular focus on SMEs —, is not legally binding and does not replace a case-by-case assessment. Only the Court of Justice of the European Union can give an authoritative interpretation of the CRA.

Key takeaways

  • Mandatory topics under Art. 26(2) — and exactly what the document covers: scope (in particular remote data processing and FOSS), support periods, interplay with other EU legislation, and the concept of substantial modification.
  • The guidance complements the Commission's FAQs of 3 December 2025; it follows consultation of the Expert Group on Cybersecurity of Products with Digital Elements and a public consultation (3 March – 13 April 2026).
  • It addresses economic operators AND authorities: market surveillance authorities, notifying authorities and notified bodies are also meant to rely on it for harmonised EU-wide enforcement.
  • The numerous examples are illustrative only — they never replace an assessment of the specific individual case.
  • Further guidance is explicitly envisaged, for example on the CRA's interplay with the AI Act (Regulation 2024/1689) and DORA (Regulation 2022/2554).
  • Background: the CRA follows the New Legislative Framework (Regulation 765/2008, Decision 768/2008/EC); market surveillance follows Regulation 2019/1020. The Commission plans to modernise the NLF via the 'European Product Act'.

In practice

Use the guidance as a basis for argument with auditors, notified bodies and market surveillance — cite the specific section and paragraph number. But do not rely blindly on the examples: always document your own case-by-case assessment, as the guidance is not legally binding. And keep an eye on the announced follow-up guidance (AI Act, DORA) if your products are affected there too.

Linked CRA provisions

Art. 26
2

Chapter 2: Scope

Section 2.1

Placing standalone software on the market

Standalone software is placed on the market once its manufacturing phase is complete and it is first offered for distribution or use on the EU market. All copies of the same version are considered placed on the market at the same time — regardless of when individual users download them.

Key takeaways

  • The moment of first offering counts for all copies of a version — later downloads are merely instances of 'making available' the same products.
  • Iterations that are not substantial modifications do not shift the date of placing on the market; only a substantial modification counts as a new placing on the market (see Chapter 4 of the guidance).
  • Variants that differ in included components, configurations or enabled functionalities (e.g. builds per operating system, differing feature bundles) are distinct products.

Example from the guidance

Version 1.0.0 is first offered via the website on 1 January 2028. Customer 1 buys the same day, customer 2 on 15 January. Both copies are considered placed on the market on 1 January 2028 (Example 1 of the guidance).

In practice

Record the date each software version is first offered — it determines when CRA obligations start for all copies of that version. Also keep a list of your variants (builds per operating system, feature bundles): each variant is a separate product with its own date.

Linked CRA provisions

Art. 2Art. 3Recital 41
Section 2.2

Software as a product — web apps and websites

Software is a product with digital elements only where it is supplied to the user and executes on the user's system. Web applications accessed exclusively through a browser and purely informational websites are not themselves products — they fall within scope only as remote data processing where they support a function of a product.

Key takeaways

  • Locally installed applications are products — including browser extensions and desktop apps built with web technologies but supplied for local execution.
  • Web apps and progressive web apps accessed exclusively through a browser are not products with digital elements (recitals 11 and 12).
  • A locally installed client plus the data processing at a distance it relies on for its functions together constitute the product.

In practice

Sort your portfolio into three buckets: (1) runs locally on the user's device (app, desktop client, browser extension) → a product under the CRA; (2) browser-only web app or informational website → not a product; (3) a back-end supporting a product function → assess as remote data processing (Chapter 8 of the guidance).

Section 2.3

Computer code — source code and machine code

Both machine code and source code are 'software' within the meaning of Article 3(4). What matters is whether the supply occurs in the course of a commercial activity: openly shared FOSS code, unfinished code during development, and demo or tutorial code are not considered placed on the market — source code licensed commercially to customers is.

Key takeaways

  • Supplying source code to customers as a product places it on the market — even where the customer must adapt and compile it first (Example 7).
  • The licensor is not responsible for CRA compliance of the customer's downstream adaptations.
  • Unfinished software (alpha, beta, release candidates) may be made available under Article 4(3) for the time necessary for testing and feedback.

In practice

Review your licence and supply contracts: where do you provide customers with source code for remuneration? You bear full manufacturer obligations for that code — but not for what the customer builds from it. Demo code, tutorials and beta versions for testing remain out of scope.

Linked CRA provisions

Art. 3Art. 4
Section 2.4

Hardware and software forming one product

Whether software forms part of a product is determined not by how it is delivered, but by whether it is necessary for the product to perform its intended functions. Separately obtained drivers and companion apps (e.g. from an app store) together with the hardware constitute a single product with digital elements.

Key takeaways

  • Network printer + downloadable drivers = one product, because the printer cannot fulfil its purpose without the drivers (Example 8).
  • Fitness wearable + companion app = one product, because they are designed to operate together (Example 9).
  • The software is placed on the market at the same point in time as the hardware units.

In practice

Assign every companion app and driver to its hardware product: they belong in that product's risk assessment, SBOM, technical documentation and conformity assessment — not in one of their own. The delivery channel (app store, download link) is irrelevant.

Linked CRA provisions

Art. 3
Section 2.5

Data connection — distinguishing mere electronics

The CRA's scope is anchored in a data connection, not the mere presence of electronics. A data connection requires binary states to be deliberately encoded as information by a sender and capable of being decoded as data by a receiver. Electrical signals that merely trigger or power a function do not bring a product within scope.

Key takeaways

  • Merely switching an output on and off (0/1) is not a data connection where those states are not intended to represent data.
  • Required: a sender deliberately generating digital symbols according to a defined scheme, and a receiver capable of interpreting them as data.
  • The boundary separates products that participate in digital communication (and are exposed to cyber risks) from products merely using electrical signals.

In practice

Ask a single question per product: does it deliberately send or receive encoded data (protocol, bus, radio, serial interface)? Only then is it within CRA scope. Products that merely switch signals or carry power can be documented out of scope on that basis.

Linked CRA provisions

Art. 2Art. 3
Section 2.6

Complex systems and interoperability constraints

Complex systems with long development cycles, legacy components and interoperability constraints are not excluded from the CRA — but those constraints feed into the risk-based approach. Where specific essential requirements cannot (fully) be met (see recital 55), manufacturers must document the constraints, assess the risks and implement compensatory measures.

Key takeaways

  • A less secure legacy protocol may be implemented where necessary for interoperability, provided the risks are mitigated by other means; where the product supports both protocols, the secure one must be the default (Example 10).
  • Constraints, risks and mitigations must be transparently described in the technical documentation (Art. 31, Annex VII) and user information (Annex II).
  • Constraints must be periodically reassessed during the support period; where they can be lifted, the product should be updated accordingly.
  • Components purchased before the CRA applies may be integrated where the risk assessment identifies no specific risks and the product as a whole meets the requirements (Example 11).

In practice

Create a constraint dossier for every requirement you cannot (fully) meet: why it is not implementable (e.g. interoperability constraints), what risk arises, which compensatory measure applies — and schedule the reassessment. This is exactly the documentation market surveillance will want to see.

Section 2.7

Products designed before the CRA applies — no forced redesign

Products designed before 11 December 2027 but placed on the market after that date do not necessarily require redesign. The manufacturer carries out a current risk assessment; where it shows that existing measures address the risks, compliance can rest on those measures. Historical design and test documentation need not be recreated.

Key takeaways

  • The conformity assessment procedure, EU declaration of conformity and CE marking remain mandatory in any case.
  • No obligation to provide test results covering the original design phase; tests can be grouped across product families (Section 7.4 of the guidance).
  • Vulnerability handling (Annex I Part II), keeping the risk assessment updated (Art. 13(3)) and user information (Art. 13(18)) apply without restriction.

Example from the guidance

A microcontroller designed before the CRA applies may continue to be placed on the market without redesign where a current risk assessment shows that existing security measures address the identified risks (Example 12).

In practice

Do not plan a redesign for legacy designs unless the risk assessment demands one: a current risk assessment plus evidence that existing measures cover the risks is sufficient. You need not recreate historical design and test documentation — but the declaration of conformity and CE marking remain mandatory.

Linked CRA provisions

Art. 13Art. 32Annex IAnnex VII
3

Chapter 3: Free and open-source software

Section 3.1 – 3.2

Open source: when is FOSS 'placed on the market'?

What matters is monetisation by the person responsible (the maintainer), not how development was financed: charging for binaries, monetising other services through the software, requiring personal-data processing, or paid editions bundled with support benefits mean placing on the market. Voluntary donations, optional consultancy and third-party sponsoring do not, on their own, trigger CRA scope.

Key takeaways

  • The FOSS definition (Art. 3(48)) cumulatively requires a FOSS licence granting the full set of rights AND openly shared source code — code shared only with paying customers is not FOSS.
  • Responsibility lies with whoever controls releases, roadmap and distribution; contributors without that control are not subject to the CRA, even with commit access (Example 13).
  • A community version and a paid (open-core) version are two distinct products — the free version remains off-market.
  • Optional paid services (consulting, training, deployment help) are harmless; paid access to a version bundled with technical support is monetisation (Examples 17/18).
  • Donations only become critical where they are de facto a condition of access — e.g. releases or security fixes only for donors (Examples 21/22); cost recovery including reasonable living expenses is permissible.
  • Third-party financing (grants, bug bounties, paid feature development) does not make FOSS commercial (recital 18, Example 23).

In practice

Go through your open-source projects one by one and answer two questions: do we control releases and distribution? And do we monetise this specific version (price, monetisation through the software, mandatory data processing, paid edition with support)? Only two yeses make you a manufacturer. A donation link, sponsoring and optional consultancy change nothing.

Section 3.3

Open-source software stewards — graduated obligations

Stewards are legal persons that systematically support FOSS intended for commercial activities without placing it on the market (Art. 3(14), Art. 24). The guidance grades the reporting obligations by type of support: purely non-technical support, hosting the infrastructure, or active engineering contributions.

Key takeaways

  • The role applies per FOSS project: the same organisation can be steward for product A and manufacturer for product B (e.g. community vs. paid edition).
  • Non-technical support only (branding, governance, events, donations): no obligation to report actively exploited vulnerabilities — but share information with maintainers and consider voluntary reporting under Art. 15.
  • Infrastructure steward (repos, version control, signing keys): notify ENISA/CSIRTs of severe incidents affecting product security (Art. 14(3)) and inform users where appropriate.
  • Engineering steward (developers, releases, vulnerability handling): report actively exploited vulnerabilities (Art. 14(1)) and inform users (Art. 14(8)).
  • Not-for-profit entities whose earnings serve not-for-profit objectives do not place their FOSS on the market even where it is monetised — steward obligations apply (Example 24: browser funded via search-engine partnerships).

In practice

Clarify per FOSS project what kind of support you provide — governance/branding only, infrastructure (repos, signing keys), or active engineering. That directly determines which reporting and information duties under Article 24 apply to you. The same organisation can be steward for project A and manufacturer for project B.

Linked CRA provisions

Art. 14Art. 15Art. 24Recital 19
Section 3.4 – 3.5

Contributors, integration and the FOSS scenarios

Manufacturers integrating FOSS components into their own products do not become responsible for those components' individual CRA compliance — not even by contributing code to their maintenance. The due diligence obligation (Art. 13(5)) and upstream obligations (Art. 13(6)) apply. Eight scenarios (Examples 27–34) walk through the typical constellations of developers, foundations and integrating manufacturers.

Key takeaways

  • Individual developer with a donation link: no CRA obligations; integrating manufacturers owe due diligence (Examples 27, 34).
  • FOSS intended for integration by other manufacturers and not monetised is not placed on the market — its publisher may be a steward (Examples 25/26, 29).
  • A FOSS component's CRA status is unaffected by manufacturers integrating it into monetised products.
  • Package repositories likewise bear no CRA obligations (Example 34).

In practice

Keep a list of all integrated FOSS components with version, source and maintainer contact. That is the working basis for your due diligence (Art. 13(5)) and for upstream reporting including fix sharing (Art. 13(6)) — you are not, however, responsible for the component's own compliance.

Linked CRA provisions

Art. 13Recital 18
4

Chapter 4: Substantial modifications and spare parts

Section 4.1 – 4.2

Physical repairs and spare parts

Repair, refurbishment and maintenance generally do not amount to a substantial modification as long as the intended purpose and level of risk remain unchanged. The spare-parts exemption (Art. 2(6)) applies only where the part is demonstrably supplied to repair an existing product; 'identical' is measured against security-relevant characteristics, not physical sameness.

Key takeaways

  • Replacing a defective part with a better-performing one is not in itself a substantial modification (Example 35: faster RAM in a server).
  • A new chipset using the same protocols and security mechanisms can be 'identical' (Example 38); a different cryptographic implementation or secure-boot mechanism cannot (Example 37).
  • The repair purpose must be apparent from the supply context (product identified in the order/offer, after-sales channel) — keep supporting evidence for market surveillance.
  • The exemption also covers replacing entire modules or sub-products within larger systems (Example 39: CPU unit or complete PLC).

In practice

For every spare part, document the repair context (product identified in the order/offer, supply via after-sales channel) and compare security-relevant characteristics — crypto, protocols, secure boot, access controls — rather than part numbers. Only then can you demonstrate the Art. 2(6) exemption to market surveillance.

Linked CRA provisions

Art. 2Recital 29Recital 42
Section 4.3

Software updates as substantial modifications

The yardstick is not the scale of the change but its effect on the risk profile: where an update alters the assessed intended purpose or introduces new risks not covered by the risk assessment, it is a substantial modification. Security updates generally are not. Four assessment criteria (para. 110) structure the case-by-case analysis.

Key takeaways

  • Features already anticipated and assessed in the original risk assessment do not trigger a substantial modification — nor does later activation of assessed, dormant functionality (Examples 42/43).
  • Even small features can be substantial: a 'remember me' login storing tokens locally introduces new risks (token theft, session hijacking — Example 44).
  • Security updates are substantial only exceptionally — e.g. where they fundamentally alter the intended purpose, data flows or dependency structure (Examples 49/50: local encryption becomes a cloud service; external key management replaces internal).
  • Assessment criteria (para. 110): new threat vectors, new attack scenarios, changed likelihood, changed impact of known scenarios.
  • Regardless of classification: the risk assessment and technical documentation must be kept continuously up to date (Art. 13(7), Art. 31(2)).

In practice

Anchor a fixed review question with a documented answer in your release process: does this update introduce new threat vectors or attack scenarios, or change the likelihood/impact of known ones? No, and covered by the risk assessment → no new placing on the market. Yes → update the risk assessment and check whether a new conformity assessment is due.

Linked CRA provisions

Art. 3Art. 13Recital 39
Section 4.4

Consequences of a substantial modification

A substantially modified product made available on the market counts as newly placed on the market. A third party carrying out a substantial modification becomes the manufacturer (Arts. 21/22) — but only for the modified part where the modification does not affect the product's cybersecurity as a whole. The original manufacturer may reuse documentation and tests for unchanged parts.

Key takeaways

  • Distinguish integration: assembling components into a new product of one's own makes the integrator a regular manufacturer of the whole product — not a substantial modifier of others' products (Example 51).
  • Legacy products: a substantial modification after 11 December 2027 of a product placed on the market before that date makes the modifier its manufacturer (Art. 69(2)) — with obligations limited to the modified parts as long as the product's overall cybersecurity is unaffected.
  • The original manufacturer's obligations for the original product (vulnerability handling, compliance of unchanged parts) continue to apply.
  • Conformity assessment focuses on the modified parts; existing tests and documentation may be reused for unchanged parts.

In practice

Separate two cases cleanly: if you substantially modify someone else's marketed product, you take on manufacturer obligations — but only for the modified part, as long as the product's overall cybersecurity is unaffected. If instead you assemble components into a product of your own, you are the regular manufacturer of the whole product. Existing tests and documentation for unchanged parts may be reused.

Linked CRA provisions

Art. 21Art. 22Art. 69Recital 41
5

Chapter 5: Support period

Section 5 – 5.1

Support period — determination, Art. 13(10) and substantial modifications

Five years is a floor, not a default: the support period reflects the expected use time, and products expected to be used longer need longer support. Article 13(10) allows manufacturers to address and remediate vulnerabilities only for the version last placed on the market, provided users can upgrade free of charge and without additional costs. A substantial modification does not automatically reset the support period.

Key takeaways

  • 'Additional costs' under Art. 13(10) means mandatory hardware purchases or infrastructure replacement — not normal update effort such as personnel time, testing or configuration adjustments.
  • Each substantially modified version needs its own declared support period under Art. 13(8) when placed on the market.
  • Where unchanged factors (e.g. hardware durability) continue to determine the expected use time, the original support period stands — even where the remainder is less than five years (Examples 54/55: robot vacuum, industrial machinery with re-architected cloud back-end).
  • Where the modification changes the use-time factors themselves (e.g. a new computing platform extends a PLC's life), the support period must be recalculated (Example 56).
  • Indicate the support end date at the time of purchase (at least month/year) and display an end-of-support notification where technically feasible (Art. 13(19)).
  • Manufacturers may voluntarily keep patching earlier versions — including on a paid basis; the CRA does not require free updates for them.

In practice

Derive the support period from the expected use time with documentation — a blanket '5 years' is attackable where your product is evidently used longer. State the end date in the purchase process (at least month/year). For software: check whether the Art. 13(10) rule lets you patch only the latest version — that requires free upgrades without forced hardware or infrastructure changes.

6

Chapter 6: Important and critical products

Section 6.1

Core functionality — the key to product classification

Whether a product is 'important' (Annex III) or 'critical' (Annex IV) is determined solely by its core functionality — the main features without which it could not meet its intended purpose. Ancillary functions and integrated components do not change the classification; every product has exactly one core functionality, to be clearly identified in the technical documentation.

Key takeaways

  • Integration is not classification: a smartphone integrating an operating system does not have the core functionality of an operating system (Example 58).
  • Substantially exceeding or falling short of a category takes a product out of it: SOAR software is not a SIEM (Example 59), simple log collection tools without correlation are not either (Example 60).
  • No gaming via marketing: inconsistencies between promotional material, instructions and technical documentation may not be used to escape the stricter regime.
  • Modules of a product that are also marketed separately are classified individually (Example 61: security suite with SIEM, IDS and analytics modules).
  • The technical descriptions of the categories are laid down in Implementing Regulation (EU) 2025/2392.

In practice

Write one sentence per product: 'Without function X the product cannot meet its purpose.' X is the core functionality — match only X against the categories in Annex III/IV (or Implementing Regulation 2025/2392), not your feature list. Make sure marketing material, instructions and technical documentation tell the same story.

Linked CRA provisions

Art. 7Art. 8Annex IIIAnnex IV
Section 6.2

Conformity assessment for important and critical products

Class II and critical products require third-party assessment. Important class I products may use the internal control procedure (module A) where a relevant harmonised standard is applied in full and covers at least all risks associated with the core functionality — risks beyond that scope must be addressed through additional, documented measures.

Key takeaways

  • FOSS exception: important class I/II products placed on the market as FOSS may follow the default-category procedures (Art. 32(5)).
  • Antivirus with extra features (disk cleaning, anti-tracking): self-assessment is possible where the standard covers the core functionality's risks and additional risks are addressed and documented (Example 62).
  • An integrated critical component does not force the whole product into that component's stricter regime — the product's own core functionality remains decisive (Example 63: router integrating a firewall component).
  • Non-compliance with Art. 32 can trigger administrative fines under Art. 64(3).

In practice

For class I products, first check whether a harmonised standard covers all risks of the core functionality — that determines whether you may self-assess (module A) or need a notified body. Risks from additional functions outside the standard must be closed with your own documented measures. FOSS products of classes I/II may always self-assess.

Section 6.3

Presumption of conformity — only as far as the standard reaches

Harmonised standards (as well as common specifications and EU cybersecurity certificates) grant a presumption of conformity only for the risks they cover. Additional functionalities outside the standard's scope do not benefit — the manufacturer must demonstrate their conformity separately. Full responsibility for assessing all product risks stays with the manufacturer.

Key takeaways

  • Where the standard covers all risks of the core functionality and there are no risk-bearing additional functionalities, the presumption covers the whole product.
  • Where the standard covers only part, the presumption is partial — e.g. for the core functionality and a disk-cleaning feature, but not for an anti-tracking feature (Examples 64/65).
  • Even with a standard applied, the full risk assessment under Art. 13(2) remains mandatory (Blue Guide, Section 4.1.2.2).

In practice

Maintain a coverage matrix: which of your product risks does the applied standard cover, and which not? The presumption of conformity applies only to the covered risks — for the gaps you need your own measures with evidence. The standard never replaces the full risk assessment under Art. 13(2).

Linked CRA provisions

Art. 27
7

Chapter 7: Risk assessment and component integration

Section 7.1 – 7.2

Risk assessment: no internal risk appetite, no risk transfer

Unlike organisational risk management, the manufacturer's own risk appetite does not count: residual risks must be measured against the product's 'appropriate level of cybersecurity'. Cost or commercial considerations do not justify leaving risks untreated — if necessary, design, functionality or intended purpose must change. Transferring risk to users or third parties is not a permissible compliance strategy.

Key takeaways

  • Permissible mitigations include restricting the intended purpose plus clear user information — e.g. an industrial sensor intended only for trusted environments (Example 66).
  • Manufacturers may rely on mature platform functions, e.g. the operating system's native encryption and key management instead of building their own (Example 67).
  • Annex I Part I point (1) ('appropriate level of cybersecurity') acts as a catch-all: fulfilled where all risks are addressed via the other essential requirements — otherwise additional product-level measures are needed.

In practice

Remove 'residual risk accepted for cost/business reasons' from your risk templates — that argument does not hold under the CRA. Permissible levers are: technical measures, restricting the intended purpose plus clear user information, relying on mature platform functions (e.g. OS encryption) — and, if necessary, changing the design or feature set.

Linked CRA provisions

Art. 13Annex I
Section 7.3

External dependencies vs. due diligence for components

Two complementary obligations: the risk assessment (Art. 13(2)) also covers external risks — back-ends, infrastructure, environment — to be mitigated through product-level measures; the CRA does not regulate how external infrastructure is operated. Due diligence (Art. 13(5)) concerns integrated third-party components: the manufacturer defines what the component must deliver and verifies it in a risk-based manner.

Key takeaways

  • Examples of product-level mitigation of external risks: cryptographic authentication of remote commands, integrity verification of configuration changes, secure fail states when external services become unavailable.
  • Due diligence evidence: the component manufacturer's technical specifications and security documentation, conformity/assurance documentation, and where appropriate the manufacturer's own tests.
  • Integrated third-party components belong in the risk assessment but are treated as externally supplied parts whose properties are verified upon integration (recital 34).

In practice

Split your risk list into two columns: external dependencies (third-party back-ends, networks, environment) → mitigate at product level, e.g. authenticated remote commands and secure fail states; integrated third-party components → define requirements and collect evidence (manufacturer documentation, certificates, your own tests). How the external provider runs its operations is not your CRA problem.

Linked CRA provisions

Art. 13Recital 34Annex I
Section 7.4

Product families — one risk assessment, one documentation set, one declaration

Variants sharing the same architecture, security-relevant design, intended purpose and risk exposure may share a single risk assessment, technical documentation set, conformity assessment procedure and EU declaration of conformity. The sole decisive factor is whether the differences between variants are relevant to cybersecurity.

Key takeaways

  • Irrelevant: colour, form factor, memory size and other non-security-relevant characteristics.
  • Relevant: differing communication interfaces, software stacks, update mechanisms or remote connectivity — such differences must be reflected in the risk assessment and documentation.
  • The shared declaration of conformity must clearly identify the covered variants; new variants introducing new risks require an update.

In practice

Group your product variants by security-relevant differences: everything sharing architecture, interfaces and risk profile can share one risk assessment, documentation set and EU declaration of conformity — colour, form factor and memory size do not separate variants. This drastically reduces per-variant effort; the declaration must simply identify the covered variants unambiguously.

Linked CRA provisions

Art. 13Art. 28Annex VII
8

Chapter 8: Remote data processing

Section 8.1

What counts as a remote data processing solution (RDPS)?

Remote data processing is part of the product where three criteria are cumulatively met: processing 'at a distance', functional necessity (without it the product could not perform one of its functions), and development by or under the responsibility of the manufacturer. The guidance turns this into two test questions with a decision flowchart.

Key takeaways

  • 'Who operates it' is irrelevant: on-premises or private-cloud solutions can qualify as RDPS just like public-cloud solutions.
  • 'Functions' means more than core functionality: onboarding, file sync, configuration, automated update distribution and identity/access management all count.
  • Telemetry purely for statistics or future product development is not RDPS — but the risks of such remote components still belong in the risk assessment.
  • IaaS/PaaS: where the manufacturer's own (or commissioned) software runs on third-party infrastructure, it can be RDPS; standard third-party SaaS is not RDPS but must be treated like a third-party component (mitigate risks + due diligence).
  • 'Under the manufacturer's responsibility' = tailor-made for the manufacturer to its designs/specifications — not merely licensing an existing service.
  • Internal systems (HR, CRM, CI/CD pipelines, update distribution to edge locations, pentest/red-team infrastructure) are not RDPS.
  • Websites only where they support a function: an authentication portal issuing tokens for the product can be RDPS — an informational website is not, even if the product links to it.

In practice

Answer two questions per cloud/back-end service: (1) would a product function fail without it (including onboarding, sync, updates, login)? (2) was the software developed by us or to our specifications? Two yeses → part of your product, belongs in the risk and conformity assessment. Only question 1 yes (e.g. standard SaaS) → treat as a third-party component: mitigate risks plus due diligence.

Section 8.2

RDPS in documentation, risk assessment and conformity assessment

RDPS must be covered in the product's risk assessment, technical documentation and conformity assessment — limited to the software modules responsible for the product's functionality and the interfaces those modules use. Downstream back-end systems the product does not directly interact with are not RDPS, but remain external dependencies whose risks must be mitigated at product level.

Key takeaways

  • An RDPS serving several products must be declared in each product's technical documentation — the RDPS documentation may be reused across conformity assessments.
  • Reusable assurance artefacts for third-party services: NIS 2 evidence (IR (EU) 2024/2690), DORA evidence, certificates under EU cybersecurity certification schemes, ISO/IEC 27001/27017.
  • Major changes to third-party services are not a substantial modification of the product — but manufacturers should secure information and security guarantees contractually (SLAs) and revise the risk assessment accordingly.

In practice

Create a central RDPS dossier — affected software modules, interfaces, providers used with evidence (ISO 27001/27017, NIS 2 or DORA evidence, EUCC certificates) — and reference it from every product's documentation. Anchor in provider SLAs that you are informed about major changes: they do not trigger a new conformity assessment, but they do require updating your risk assessment.

Section 8.3

Five RDPS use cases: banking app, thermostat, e-reader, robot, cellular network

Five worked cases illustrate the boundary: for a mobile banking app, the self-developed banking interface is RDPS, downstream ledger/account systems are not, and the third-party SaaS support chat is a third-party component. Smart thermostat and industrial robot: the manufacturer's own cloud software on third-party IaaS is RDPS. E-reader: third-party SaaS storage is not RDPS but must be treated as a component. The cellular network is a mere communication channel — no RDPS, no due diligence required.

Key takeaways

  • The CRA covers only the parts of the system the product directly interacts with — risks from systems behind them (e.g. a compromised ledger) must be mitigated at product level (strong back-end authentication, integrity protection, secure channels).
  • With third-party IaaS: document the RDPS and the IaaS reliance in the technical documentation; obtain e.g. NIS 2 evidence from the provider.
  • Network infrastructure (5G, ethernet, Wi-Fi, routers) is a communication enabler, not data processing whose absence would prevent a product function.

In practice

Map your own setup to the closest of the Commission's five use cases (banking app, smart thermostat, e-reader, industrial robot, cellular network) and adopt its logic: what interacts directly with the product and was developed by you is RDPS; systems behind it are external dependencies; pure network infrastructure is neither. In most cases this replaces an expensive bespoke legal opinion.

9

Chapter 9: Reporting, vulnerability handling and interplay with other legislation

Section 9.1

Reporting obligations: from 11 Sep 2026, 'becoming aware' and informing users

The Article 14 reporting obligations apply from 11 September 2026 to all products within the CRA's scope — including products placed on the market before 11 December 2027 and products past their support period. 'Becoming aware' means reaching a reasonable degree of certainty after an immediate initial assessment — from that moment the deadlines run (24h early warning, 72h notification, 14 days / 1 month final report).

Key takeaways

  • No retroactive reporting: active exploitation the manufacturer already knew about before 11 Sep 2026 is not reportable; where exploitation only becomes known afterwards, the obligation applies.
  • Third-party components: only an actively exploited vulnerability that is exploitable/exploited in the manufacturer's own product is reportable — otherwise voluntary reporting (Art. 15) plus upstream reporting to the component maintainer (Art. 13(6)).
  • 'Becoming aware' is deliberately aligned with the NIS 2 implementing regulation and the GDPR breach-notification guidelines.
  • Informing users (Art. 14(8)) is risk-based: no indiscriminate disclosure — for sensitive environments, detailed information may be limited to affected users; broader disclosure once fixed, and mandatory disclosure of fixed vulnerabilities under Annex I Part II point (4).
  • Unlike vulnerability handling, the reporting obligations continue to apply after the support period ends.

In practice

Define now who performs the initial assessment of suspected cases and how fast — the 24-hour clock starts at 'reasonable certainty'. The process must be in place by 11 September 2026 and also covers legacy products and products past their support period. Additionally define how you inform users in a risk-based way: affected customers first and targeted, broad disclosure once fixed.

Section 9.2

Vulnerability handling: upstream reporting, known vulnerabilities, testing

The guidance clarifies three obligations: reporting component vulnerabilities and sharing security fixes upstream (Art. 13(6)), the prohibition on placing products with known exploitable vulnerabilities on the market (Annex I Part I), and the 'effective and regular tests and reviews' (Annex I Part II point (3)) — which require input-driven review and adaptation rather than mechanical test repetition.

Key takeaways

  • Upstream reporting only for the version actually integrated, following the maintainer's CVD processes; no obligation where the vulnerability is already known (avoid duplicates: check databases/advisories) or the project no longer has a maintainer.
  • Only vulnerabilities in the component itself must be reported — not those arising from the manufacturer's own integration.
  • Share security fixes in machine-readable, licence-compatible form; the maintainer need not accept the fix, nor must the manufacturer adopt the maintainer's fix.
  • A vulnerability is 'known' when listed in relevant public databases (e.g. the European vulnerability database), disclosed via coordinated disclosure, found through the manufacturer's own testing (including AI-powered analysis), or prominently reported in reliable media — a short verification period is permissible.
  • Vulnerabilities discovered shortly before release: risk-based decision on whether to postpone the release — weighed against the risks of delay (e.g. where the release also fixes other vulnerabilities).

In practice

Add three building blocks to your vulnerability process: (1) a database/advisory check before every upstream report to avoid duplicates; (2) licence-compatible, machine-readable sharing of your own fixes with the maintainer; (3) a documented release decision for late-found vulnerabilities — weighing fix-before-release against the risks of delay.

Linked CRA provisions

Art. 13Art. 15Annex I
Section 9.3

Interplay with other EU law: vehicles, RED, Machinery Regulation

Vehicle components (Regulation (EU) 2019/2144, Regulation (EU) No 168/2013) are exempt from the CRA where they are exclusively designed, constructed and suitable for integration into such vehicles — generic components sold through open distribution channels fall within the CRA regardless of intended-use statements. EU type-examination certificates covering cybersecurity requirements (e.g. RED Delegated Act, Machinery Regulation) remain usable as evidence of conformity for the covered risks until 11 June 2028 at the latest.

Key takeaways

  • The objective conditions of supply are decisive: sale through general retail/online channels open to the public argues against the vehicle exemption; restricted B2B channels within the automotive supply chain support it.
  • Existing certificates (RED DA, Machinery Regulation Annex III 1.1.9/1.2.1) do not replace the CRA risk assessment — they only serve as evidence for the risks they cover.
  • CRA risks not covered by the certificate (e.g. vulnerability handling processes, data minimisation, attack surface reduction) must be addressed additionally.

In practice

Check your distribution channels: components also sold outside the automotive supply chain (retail, open online shop) fall under the CRA — regardless of what the datasheet says about intended use. Also inventory your RED/Machinery Regulation certificates: they count as CRA evidence only for the risks they cover and until 11 June 2028 at the latest — plan the gap closure now.

Linked CRA provisions

Art. 2Art. 69

Frequently asked questions about the EU Commission guidance

Is the EU Commission guidance on the Cyber Resilience Act legally binding?

No. The guidance (C(2026) 5252 final) reflects the European Commission's interpretation and is not binding on economic operators — only the Court of Justice of the EU can give an authoritative interpretation of the EU CRA. In practice, however, market surveillance authorities and notified bodies rely on it; anyone deviating from it should justify and document that well.

What does the Commission guidance on the EU CRA cover?

The core topics mandated by Article 26 EU CRA: scope (including placing software on the market and the data connection criterion), open-source software and stewards, substantial modifications and spare parts, the support period, important and critical products (core functionality), risk assessment and due diligence, remote data processing, and reporting obligations — illustrated with 67 worked examples.

Where can I download the EU Commission's CRA guidance?

The original PDF (84 pages, English) is available for download at the top of this page; only the Commission's document (C(2026) 5252 final of 27 July 2026) is authoritative. No official German language version exists yet — this page provides an unofficial German summary of every chapter.

Who is the guidance intended for?

For manufacturers, importers and distributors of products with digital elements — with a particular focus on small and medium-sized enterprises — as well as for market surveillance authorities, notifying authorities and notified bodies tasked with enforcing the EU CRA uniformly across Europe.

Will the Commission publish further CRA guidance?

Yes. The Commission explicitly envisages further guidance, for example on the EU CRA's interplay with the AI Act (Regulation 2024/1689) and DORA (Regulation 2022/2554). Also available are the Commission's FAQs of 3 December 2025, which this guidance complements and deepens.

CRA updates by email

Deadlines, official guidance, and myth-busting fact-checks on the Cyber Resilience Act — compact in our newsletter.

View newsletters

Legal notice

This page provides an editorial summary of the European Commission's guidance C(2026) 5252 final of 27 July 2026. The guidance is not legally binding on economic operators; an authoritative interpretation of the EU CRA may only be given by the Court of Justice of the European Union. The Commission's examples do not replace a case-by-case assessment. Only the Commission's original document is authoritative. The downloadable PDF is the unmodified original document of the European Commission (© European Union, reused in accordance with Decision 2011/833/EU).

Official EU Commission CRA page