The list of everyday devices compromised by cyberattackers seems to grow longer every day, from fish tanks to toasters , baby monitors to smart toilet cameras.
Each of the incidents above provoked public alarm: common-or-garden objects filling people's homes, cars, and workplaces, all of which were connected to the internet and thus vulnerable. At times, the unease was visceral: parents demanded answers about nursery cameras; consumers discovered that day-to-day objects in their homes had become potential attack surfaces.
Regulators took notice and, characteristically, the European Union legislated, adopting the Cyber Resilience Act (CRA) in October 2024.
On 27 July 2026, to fill in the needed details for the legislation, the European Commission published detailed guidance on the CRA.
This guidance "addresses the questions stakeholders have been asking most" including clarifying the:
- scope of the CRA;
- treatment of open-source;
- nature of 'substantial modifications';
- length of support periods; and
- extent of reporting obligations.
This formal guidance runs to more than 80 pages of worked examples, flowcharts, and interpretive analysis.
With mandatory vulnerability reporting starting 11 September 2026 and full application from 11 December 2027, the window for compliance preparation under the CRA and this guidance is narrowing fast.
What is the CRA?
The CRA is aimed at bolstering cybersecurity across the EU by introducing stringent security requirements for digital products and ensuring that smart devices are secure throughout their lifecycle. For more details, see our article here: EU adopts Cyber Resilience Act to enhance digital security.
As we noted at the time, "the adoption of the CRA marks a significant step forward in the EU's efforts to create a secure digital environment. By setting high cybersecurity standards for digital products, the EU is not only protecting its citizens but also setting a global benchmark for digital security."
Timeline
Mandatory reporting obligations under the CRA begin on 11 September 2026, with full application of the CRA following on 11 December 2027.
Scope of the CRA
The CRA captures any product with a data connection to a device or network. The guidance notes that the CRA:
"can cover a range of products with digital elements, including: (i) standalone software, such as apps and computer programs, whether digitally or physically distributed; (ii) hardware with embedded software (e.g. Internet-of-Things devices, laptops, tablets); (iii) standalone hardware (e.g. integrated circuits, motherboards); and (iv) any combination of hardware and software supplied separately but intended to operate together."
The guidance goes on to note, however, that "software that executes remotely and is merely accessed by the user is not, on that basis alone, a product with digital elements." As for websites, while they may "to a limited extent technically run and execute on the user's device ... websites are not themselves to be considered as products with digital elements". They only fall within the scope of the CRA "where they support the functionality of a product with digital elements, i.e. to the extent that they qualify as remote data processing."
Source code licensed commercially is within scope, but code shared on public repositories without commercial intent generally is not.
Treatment of open source
Free and open-source software (FOSS) triggers CRA obligations only where it is supplied in the course of a commercial activity, eg, by charging a price, monetising through a platform, or requiring personal data processing "for reasons other than exclusively for improving the security, compatibility or interoperability of the software". Voluntary donations do not cross the line unless, eg, they are de facto conditions for accessing the software or its updates.
Manufacturers integrating any FOSS component must exercise due diligence, report vulnerabilities upstream and share security fixes.
Nature of 'substantial modifications'
A modification is substantial where it affects compliance with the essential cybersecurity requirements or shifts the product's intended purpose beyond its original risk assessment. Routine repairs and identical spare parts typically do not trigger it, "for instance if the intended purpose and functionalities are not changed and the level of risk remains unaffected." "However, an upgrade of a product with digital elements by the manufacturer might lead to changes in the design and development of that product" and therefore amount to a substantial modification. Case-by-case assessments should therefore be performed.
For software, the guidance recognises that "software development is iterative in nature, with software products with digital elements already placed on the market being frequently and continuously updated." The test asks whether an update introduces new threat vectors, enables new attack scenarios, materially alters the risk profile or "changes the potential impact of previously identified attack scenarios." On security patches, the guidance notes that "a security update that does not modify that product's intended purpose and does not introduce new cybersecurity risks should therefore not be considered a substantial modification, even where that update may introduce significant technical changes." Again, case-by-case assessments should therefore be performed.
Length of support periods
The five-year minimum support period is a floor (and not a default), "unless the product with digital elements is expected to be in use for less than five years, in which case the support period shall correspond to the expected use time." Products expected to remain in use longer must have correspondingly longer periods, determined by reasonable user expectations and the product's nature.
For iteratively released software, manufacturers may discontinue remediation for earlier versions once users can upgrade free of charge without additional costs. The guidance goes into detail on how "additional costs" should be interpreted. They refer "to burdens that go beyond what can normally be expected in the context of software updates, such as mandatory purchases of new hardware, infrastructure replacement or fundamental changes to the operating environment."
Extent of reporting obligations
The guidance notes that:
"the structure of the reporting obligations requires manufacturers to update their notifications progressively, as their internal investigations advance and their knowledge of the actively exploited vulnerability or incident becomes more detailed."
From 11 September 2026, manufacturers must notify their national computer security incident response team (CSIRT) and the European Union Agency for Cybersecurity (ENISA) of actively exploited vulnerabilities and severe security incidents without undue delay and in any event within 24 hours, with substantive updates to be given without undue delay and in any event within 72 hours. A complete report "needs to be submitted within 14 days after a corrective or mitigating measure is available for actively exploited vulnerabilities, or within one month after the 72-hour notification for severe incidents."
These duties apply even to products placed on the market before 11 December 2027 (the date when the CRA applies generally), and persist after the support period expires. In particular, vulnerabilities originating from third-party components must also be reported where exploitable in the manufacturer's product. The "becoming aware" trigger is aligned with NIS 2 and GDPR breach notification standards.
What this means in practice
Any company placing products on the EU market – regardless of where it is established, including the UK – is within scope, creating a regulatory framework that exporters must build into their strategies.
The guidance is not legally binding, but market surveillance authorities across the 27 Member States will take their cue from it. Organisations that have not yet mapped their product portfolios against the CRA's scope, classified their products by risk, and reviewed their supply chain contracts for CRA-compatible obligations are running behind.
If you're interested in learning more about the CRA and its requirements, contact one of the team who will be happy to help. And if you'd like to know about the equivalent UK requirements, see our article here.
