Repairs and spare parts
A repair that keeps the product inside the intended use already assessed is not a substantial modification, so swapping in better-performing RAM changes nothing. Article 2(6) then exempts spare parts that replace an identical component, and the guidance applies that whether the host product was placed on the market before or after the CRA started to apply. Identical is judged on cybersecurity properties rather than part numbers. A replacement built on a different chipset can still be identical where the protocols and security mechanisms are unchanged, while a newer chip with a different cryptographic implementation and a different secure boot mechanism is not identical and is a product with digital elements in its own right. The exemption applies at either level, so replacing a controller's processor and replacing the whole controller are treated the same way. The counter-example the Commission dropped between draft and final still marks the boundary, because a repair that changes how core functions execute, in a way the original risk assessment never considered, is a substantial modification.
Updates, substantial modification, and the support period
An update is a substantial modification when it takes the product beyond the intended purpose that was assessed, or when it introduces a cybersecurity risk that affects the essential requirements. A monitoring dashboard that gains the ability to control machines crosses that line, and so does a personal information tool that starts making automated decisions about content. Size is no defence. A remember-me feature that stores authentication tokens, or diagnostics logging that writes sensitive data in the clear, both qualify. What was already assessed does not qualify, so shipping group chat that the original assessment covered, or switching on control features that shipped disabled but assessed, changes nothing. Security updates are generally not substantial modifications, including fixes for a buffer overflow or an authentication bypass, hardening of configuration, and deprecating an algorithm the risk assessment already anticipated. A security motive is not a free pass though. Replacing local encryption with a remote service, or introducing a dependency on a third-party key management service, both qualify. On support periods, Article 13(10) lets a manufacturer remediate only the latest version where upgrades are free and need no new hardware, with testing and configuration effort not counted as an additional cost. A substantial modification does not stretch the support period by itself. It moves only when the Article 13(8) criteria genuinely change, as when a new computing platform makes users reasonably expect a longer working life.
Two questions decide a substantial modification. Does the update take the product beyond the assessed intended purpose, and does it introduce a risk that touches the essential requirements. Everything else, including most security updates, stays outside.
Core functionality, conformity, and treating risk
Classification follows core functionality as set out in Annex I to Implementing Regulation (EU) 2025/2392. A platform that manages hardware, schedules processes and exposes system interfaces has the core functionality of an operating system, while a smartphone that merely integrates one does not. Exceeding a category takes you out of it, so SOAR software is generally not a SIEM, and falling short does the same, so a log collector with dashboards and no correlation is generally not a SIEM either. Modules sold as separate subscriptions are separate products, each classified on its own core functionality. Extra functions do not change the route. An antivirus with disk cleaning, or a router with a firewall component, still uses internal control across the whole product, though presumption of conformity attaches only to the functions the harmonised standard actually covers and widens as the standard does. On risk, the guidance accepts treatment by limiting the intended purpose, as with an industrial sensor restricted to trusted environments and the limitation stated in the user information. It also accepts relying on mature operating system cryptography instead of rolling your own. Interoperability with an older protocol is allowed where the risks are mitigated, though the secure protocol is implemented and on by default. Components bought before the CRA applied can be integrated as long as the finished product meets the essential requirements, and a design that predates the regulation needs no redesign and no recreated historical paperwork where a current risk assessment shows it already complies.