The (still-in-draft) Commission guidance on the Cyber Resilience Act assists economic operators (with a particular focus on microenterprises and SMEs) and market surveillance authorities in applying the CRA. It clarifies key provisions, regulatory boundaries, and practical compliance strategies without legally binding the actors.
Ref. Ares(2026)2319816 – 03/03/2026
Highlights from the Guidance
Below you’ll find an attempt to extract highlights from the Guide.
Scope and "Placing on the Market"
Digital distribution allows for a virtually infinite number of copies. Standalone software is considered “placed on the market” when its manufacturing phase is complete, and the version is first offered for distribution or use. Subsequent downloads of the identical version are repetitions of making it available, not new placements.
Software required for a hardware device to perform its intended functions (e.g., printer drivers or wearable companion apps) is part of a single product with digital elements, even if distributed via separate channels.
The CRA applies to compiled, uncompiled, or interpreted computer code shared as part of a commercial activity. Unfinished code (alphas/betas for testing) or sample tutorial code is excluded.
A product falls under the CRA if its capacity to exchange digital data involves sending or receiving deliberately encoded binary symbols.
Free and Open-Source Software (FOSS)
The CRA applies only to entities (“maintainers“) that publish FOSS and exercise primary control over development, releases, and governance. Individual contributors who submit code but do not control releases are excluded.
FOSS is considered placed on the market only if it is supplied in the course of commercial activity.
Commercial Indicators.
Direct monetization (charging a price), using the FOSS to monetize other services, or requiring personal data processing for reasons other than security or interoperability.
Non-Commercial Indicators.
Voluntary donations (that do not condition product access or act as a de facto price), commercial sponsorship/financing of a project, and strictly cost-recuperating support services packaged by natural persons.
Legal, not-for-profit entities that provide systematic, sustained support to ensure the viability of FOSS projects intended for commercial downstream integration are classified as “stewards.” They are subject to distinct, tailored cybersecurity obligations under CRA Article 24, based on the depth of their support (non-technical, infrastructural, or engineering).
Substantial Modifications and Spare Parts
Swapping worn or defective hardware components with equivalent or better-performing ones does not constitute a “substantial modification” unless it introduces unassessed risks or alters the product’s behavior in a way that conflicts with essential security requirements.
Identical components manufactured to the original specifications are fully exempt from the CRA. Non-identical replacements are treated as separate products under the CRA and require localized risk assessments.
Software updates are evaluated on a case-by-case basis:
Security updates or minor iterative features already factored into the original risk assessment are not substantial modifications.
Updates that introduce new threat vectors, enable new attack scenarios, modify the underlying trust model, or alter the product’s overarching intended purpose (e.g., turning a read-only dashboard into an operational device controller) constitute substantial modifications, treating the update as a completely new product placement requiring a new conformity assessment.
Support Periods
Manufacturers must formally define a support period for handling vulnerabilities. It must be at least five years unless the product’s expected lifecycle is demonstrably shorter. Longer lifecycles require proportionally longer support periods.
For rapidly changing software, manufacturers may remediate vulnerabilities only for the latest version, provided users can upgrade to it free of charge and without incurring disruptive hardware or environmental “additional costs.” See CRA Article 13 (10).
Important and Critical Products
See also the previous article CRA – assistance – Implementing Regulation.
Classification into Default, Important (Class I/II), or Critical tiers depends on whether the main features, without which the product cannot fulfill its purpose, align with the product categories in CRA Annex III or IV. Ancillary features or the mere integration of an important component (e.g., a smartphone incorporating an operating system) does not elevate the core classification of the entire product.
Conformity Assessments:
Default products permit self-assessment (Module A).
Important Class I products may rely on internal controls only if they use harmonized standards published in the OJEU that fully cover their core functional risks.
Important Class II and Critical products mandate strict third-party assessments.
Gaps between standard coverage and broader product scopes require distinct risk mitigations and lack a presumption of conformity for the unmapped features.
Risk Assessments & Remote Data Processing Solutions (RDPS)
Risk assessments must evaluate residual risks against objective regulatory thresholds rather than an organization’s internal risk appetite or commercial budgets. Shortcomings in product design cannot be offset by shifting responsibility to user instructions.
While manufacturers must secure product-level interactions against external environments, third-party integrated components require structured due diligence, including verification of supplier specifications, documentation, and functional testing.
Cloud, edge, or on-premises server software qualifies as a Remote Data Processing Solution (RDPS) if it is designed or developed by, or under the responsibility of, the manufacturer, and its absence prevents a product function (e.g., remote authentication or cloud-based computation). Traditional SaaS integrations (where the vendor designs the software) are treated as third-party components rather than as an RDPS.
Reporting Obligations and Interplay with Other Laws
The 24-hour early warning and 72-hour notification deadlines begin the moment a manufacturer, through a rapid initial assessment, reaches a “reasonable degree of certainty” that an incident has occurred or that a vulnerability is actively being exploited.
Manufacturers must report vulnerabilities found in integrated components to the original maintainers. If they create a custom patch (“security fix”) for a FOSS component, they must share it upstream in a verifiable, license-compatible format.
Components designed and constructed exclusively for automotive vehicles covered by Regulations (EU) 2019/2144 or No 168/2013 are exempt from the CRA. Furthermore, existing EU type-examination certificates issued under the Radio Equipment Directive (RED) or the Machinery Regulation remain partially valid under the CRA until 11 June 2028. However, manufacturers must still evaluate and address any remaining security gaps (such as vulnerability handling processes) to achieve full CRA compliance.
Wrap-up
Additional CRA assistance will be provided in the upcoming articles.