EU issues CRA guidance (Part 2 – from the Commission)
On 27th July 2026, the European Commission issued for the first time official guidance on how the CRA should be “interpreted and implemented”.
While some of the advice simply confirms what should be evident from the regulation, there is valuable clarification of items previously considered open to interpretation. For better or worse the guidance is long (82 pages) and detailed. I will try to pick out important and useful information, focusing on what is a) unexpected or previously considered ambiguous, b) pertinent to embedded/IoT products in the “default” class and c) most likely to impact product design and development (as opposed to the compliance process).
What “Products with Digital Elements” are in scope?
The original interpretation here was based on Article 2(1) – “logical or physical data connection to a device or network”. Taking this literally, a wired “smart” thermostat signalling heating/cooling demand via dedicated on/off signals would be arguably in scope. In other words, all connected devices were originally potentially in-scope, irrespective of the type of connection. The guidance offers clarification of this point, by defining a data connection as follows: “For a data connection to exist, the binary states must be deliberately encoded as information by a source and must be capable of being decoded as information at the destination”. Without going down the rabbit-hole of semantics, it’s reasonable to conclude that newly added concept of encoding means that the wired thermostat, or anything transmitting or receiving simple on/off states, or perhaps an analogue I/O is out of scope. As soon as data is encoded into datagrams, you’re in scope. Therefore, it’s unlikely that wireless communication could ever be out of scope.
Risk-based compliance
The guidance makes clear, in section 7.1, that while a traditional risk-assessment might focus on internal criteria, the cybersecurity risk assessment for CRA purposes must be against an “appropriate level of cybersecurity based on the risks, taking into account its intended purpose and reasonably foreseeable use”. The prEN 40000-1-2 draft standard goes further and introduces the concept of “societal impact”. An important reminder of the act’s application to legacy products is delivered here: “Considerations relating solely to cost or commercial feasibility do not constitute sufficient grounds for leaving such risks untreated”. This underlines the risk-assessment approach I always recommend, which should start with a high-level, outward-looking “what is the worst-case failure” approach, rather than an inward-looking analysis based on envisaged specific technical threats.
Remote Data Processing
One of the most common sources of confusion, and perhaps genuine ambiguity in assessing CRA scope has been the question of remote data processing. What if some data is stored or processed not in the device, but in the cloud, or in another connected system? Is that system then part of the “product with digital elements” to be certified? The guidance provides extensive, helpful clarification, including examples. Each case should be assessed against the guidance, but in simple terms, if the external service is essential to at least one aspect of the device’s operation, and the external service is within the manufacturer’s control, then that service should be included as if it were part of the device – essentially it becomes a single “complex system”. If it is outside of the manufacturer’s control, then that aspect falls out of scope as part of the PDE, and instead into the “due diligence” category.
It is further clarified that the capability to connect to an external network (including cellular) does not render the manufacturer liable for due diligence with respect to that network.
Complex and Legacy Systems
Complex systems, where multiple devices and/or software components form a single product have their own section. One key takeaway here is that it is recognized that these systems may include legacy sub-systems which introduce insecure elements. Section 2.6 (32) introduces a concept of “alternative or compensatory risk mitigation measures” where “specific essential cybersecurity requirements are not applicable or cannot be fulfilled”. An example is given where an existing unencrypted data connection might be used. The idea of compensatory measures is of special interest for legacy products, and although the guidance doesn’t give a lot of ground in this regard, this sort of terminology tends to further the line of thought which contends that a risk-based approach can argue that essential requirements can be omitted as long as the risk-assessment justifies and/or where compensatory measures are offered. An important small-print footnote to this paragraph removes any doubt by confirming that this compensatory measures principle applies to all products, not just “complex systems”.
Products designed pre-CRA
Section 2.6 of the guidance is specifically aimed at the tortured souls tasked with the job of deciding what to do with products already shipping – deciding if and how they should be redesigned to comply with the CRA. The section constantly both gives and takes away e.g.: “compliance with this Regulation does not necessarily require that the product be redesigned” but then “provided that the manufacturer can demonstrate … that the product … complies with the cybersecurity essential requirements”. The key section here is 2.7(38) which begins: “However, the application of such requirements needs to be interpreted in light of the cybersecurity risk profile of the product”. Once again, this suggests a degree of latitude as long as it is permitted and justified by the risk-assessment. The section goes on to remind that in all cases, vulnerability handling processes must be in place.
FOSS loophole closed?
There is also a long section about Free and Open-Source Software (FOSS). Recall that the CRA instead of forcing compliance on the originators or “stewards” of such software, effectively permits that the liability for compliance flows down to the first entity in the supply chain to “place on the market” something containing the software. Board vendors have been hoping to avoid accepting this liability by making the BSP for their board a FOSS component, so that their customer – the manufacturer at the end of the chain is forced to provide “due diligence” as part of their compliance when they incorporate it in the end-product. The guidance advances the interpretation that if the board can’t function as intended without the BSP, then the BSP is considered to be placed on the market alongside (and at the same time as) the board, even if the vendor claims it to be free and open-source.
I’ll leave further dissection of that point for another post.
Conclusion
The guidance mainly serves to confirm the supremacy of the cybersecurity risk assessment. If the product with digital elements – in its intended purpose and reasonably foreseeable use – meets the requirements imposed by the risk assessment, by implementing “adequate measures to address the applicable essential requirements” (of CRA Annex I Part I), then it can be compliant. It’s becoming clear that it’s perhaps just possible to not have to implement every single essential requirement if it is deemed by the risk assessment to not reduce risk; or which cannot be implemented for technical reasons yet can be offset by compensatory measures. Remember however that vulnerability monitoring, handling and disclosure is compulsory in all cases as per CRA Annex I Part II.
You can download the guidance – C(2026) 5252 – Annex – Commission guidance on the application of the Cyber Resilience Act (CRA) here
