On 27 July 2026 the European Commission adopted its guidance on the application of the Cyber Resilience Act (Regulation (EU) 2024/2847, "EU CRA") as C(2026) 5252 final. We compared the final version paragraph by paragraph against the consultation draft of 3 March 2026 and read both against the text of the Regulation. The picture is more nuanced than the first headlines suggest. Much of what is being celebrated as relief was already implicit in the EU CRA and is merely spelled out for the first time. Other parts are genuine interpretation, some of it bold, that the text of the Regulation does not explicitly support. And in a few places the guidance creates new grey areas while closing old ones.
A chapter-by-chapter summary of the entire document, linked to the affected articles, recitals and annexes, is available in our EU Commission guidance overview, together with the original PDF.
What the guidance is, and what it is not
The guidance is based on Article 26(1) EU CRA, which requires the Commission to publish guidelines to assist economic operators, with particular attention to microenterprises and SMEs. Article 26(2) prescribes the minimum topics: scope (in particular remote data processing and open source), the support period, the interplay with other EU legislation, and the concept of substantial modification. These topics form the backbone of the document.
Two things should be kept in mind throughout. The guidance is legally non-binding. It binds neither market surveillance authorities nor courts, and the authoritative interpretation of the EU CRA rests solely with the CJEU. Wherever the guidance stretches the text of the Regulation, there is a residual risk that authorities or courts will take a different view. Beyond that, the Commission inserted a new caveat into the final version: the numerous examples "are not intended to replace a case-by-case assessment" (para. 8). This is more than boilerplate. It is the Commission's insurance against schematic reliance on precisely those examples it added under pressure from the consultation.
A reminder of the timeline the guidance itself repeats several times: the notification provisions (Chapter IV) have applied since 11 June 2026, the reporting obligations of Article 14 kick in on 11 September 2026 (Article 71(2) EU CRA), and the Regulation applies in full from 11 December 2027.
The consultation and where the criticism came from
Four fields of criticism dominated the consultation (3 March to 13 April 2026) and the surrounding expert debate, and knowing them helps to understand the final version.
The first was the software boundary. The draft largely left open the question that matters most in practice: when is software a "product with digital elements" and when is it a mere service? Law firms and industry associations were unanimous in criticising the legal uncertainty around SaaS, web apps and hybrid models.
The second was the open source economy. The community, organised among others in the Open Regulatory Compliance Working Group of the Eclipse Foundation, had already achieved during the legislative process that the harshest clauses were dropped and that the "open source steward" (Article 24 EU CRA) was created as a separate, milder category of obligations. What troubled it about the draft guidance were the vague criteria for donations, support services and steward status, along with the concern that manufacturers might offload their due diligence obligations under Article 13(5) EU CRA onto unpaid maintainers.
The third was legacy products. The draft demanded full compliance of the entire product upon any substantial modification. For manufacturers of long-lived capital goods with large installed bases, that rule would in practice have deterred updates altogether.
The fourth was the RDPS scope. The financial sector in particular feared that entire backend landscapes, from core banking systems to settlement and clearing, would slide into the conformity assessment scope of an app via the concept of the "remote data processing solution".
Over long stretches, the final version reads like a direct answer to these four points.
1. Scope: the SaaS boundary is a clarification, not an innovation
The new section 2.2 is the most important addition to the document, but it needs to be put in its proper place. That pure SaaS does not fall under the EU CRA was already in the law: Article 3(1) defines the product with digital elements as a software or hardware product, and recital 12 makes clear that cloud solutions are covered only insofar as they constitute remote data processing of a product within the meaning of Article 3(2). Otherwise NIS2 applies. What is new is that the guidance turns this into a workable criterion. A software product must be provided to a user and executed on the user's side. Web apps and PWAs that run exclusively in the browser, and websites, are "not, on that basis alone" products. Browser extensions and locally executed web technology apps such as Electron applications clearly are.
The old grey area becomes smaller, but it does not disappear. It shifts. (Why SaaS providers are not off the hook despite the scope exclusion, given NIS2, local clients and customer contracts, is something we covered in Cyber Resilience Act and SaaS. The final guidance now officially confirms the delineation taken there.) As soon as a local client exists, the server-side processing potentially becomes part of the product as remote data processing. The architectural choice between a PWA and a native client thus becomes a compliance choice, and vendors will start making it with the EU CRA in mind. That steering effect was hardly what the legislator intended.
A genuine innovation without a clear basis in the Regulation is the variants rule in para. 14. Builds for different operating systems or bundles with differing feature sets are "distinct products", each with its own placing on the market, its own documentation and its own support period. The EU CRA itself does not know the concept of a variant, so the guidance creates a new question here. Is a build with different compiler flags a variant? A regionalised feature set? A module of the same binary unlocked via licence key? The line between copy and variant will produce friction with market surveillance authorities. It also sits uneasily next to the product family logic in section 7.4 of the guidance, which allows joint risk assessments and a joint declaration of conformity precisely for variants with identical security properties.
Two corrections went in the manufacturers' favour. The draft's USB stick construction for physically distributed software was deleted, and the yardstick for complex systems was lowered from retrofitting towards the "state of the art" to reaching an "appropriate" level. The latter wording is closer to the risk-based approach of Article 13(1) in conjunction with Annex I Part I point 1 than the draft was.
2. Open source: the community delivered, and was heard
Chapter 3 is the clearest example of the consultation having had effect. Almost every change addresses a documented concern of the ecosystem.
The FOSS definition no longer hinges on an "open development process". The draft had relied on recital 18, according to which FOSS is "developed, maintained and distributed openly". The final version drops this borrowing and relies solely on the legal definition in Article 3(48): a FOSS licence granting the four freedoms plus public availability of the source code, upstream or downstream. This is remarkable because the guidance deliberately departs from the wording of a recital to reach a practicable result. Software developed internally and published only upon release can now qualify as FOSS.
On donations, the guidance follows through on what recital 15 foreshadows, namely that donations without the intention of making a profit are not a commercial activity. The draft's vague criterion of an "intention to systematically generate profit through the organisation of donations" has been deleted. What remains are objectively verifiable features: conditioning of access, and contractual benefits beyond ordinary community perks. For donation-funded projects on GitHub Sponsors or Open Collective this is a significant gain in legal certainty.
The open core model is expressly recognised for the first time. What is placed on the market is only the commercial extension, not the free base, and the corrected operating system example clarifies that only the paid edition counts as placed on the market. Perhaps the most important new statement of the chapter answers the offloading concern head-on: non-commercial maintainers owe integrators nothing. No SBOMs, no questionnaires, no attestations. The due diligence of Article 13(5) is and remains an obligation of the integrating manufacturer, not of the upstream project. Article 25 on voluntary security attestations flanks this, and the guidance makes clear that voluntary must not turn into de facto mandatory.
On stewards (Article 24 EU CRA), the final version adds three refinements. Platform hosting alone no longer automatically triggers steward status ("may include" instead of "includes"). The incident reporting obligation of Article 24(3) is narrowed to infrastructure-related incidents. And, of real practical significance for relicensing scenarios, an entity that later monetises a project it stewarded becomes a manufacturer only from that point onwards, with no retroactive obligations for earlier versions from its steward era.
One new grey area appears in return. The clarification that apps financed through advertising, commissions or subscriptions are "monetised" raises fresh line-drawing questions for the many FOSS projects with mixed funding models. At what point does a project with an optional subscription offering tip into the manufacturer role?
3. Substantial modifications: the boldest interpretation in the document
This chapter contains the most consequential change of position, and at the same time the legally most vulnerable spot in the guidance. By way of background: under Article 3(30) EU CRA, a substantial modification is a change after the placing on the market that affects compliance or modifies the intended purpose. Recital 39 and the logic of the New Legislative Framework suggest that a substantially modified product counts as a new product and must meet the requirements when placed on the market again. The draft said exactly that ("comply with the CRA in its entirety"), and that was also the prevailing reading until now, which we ourselves still relayed this spring in our Friday Facts on legacy products and substantial modifications.
The final version reverses this for legacy products in para. 124. A substantial modification carried out by the original manufacturer on a product placed on the market before 11 December 2027 does not require bringing the entire product into full EU CRA compliance, unless the modification negatively affects the cybersecurity of the product as a whole. The obligations are then limited to the substantially modified parts. The anchor is the rationale of Article 22(2), which however expressly provides this partial logic only for third parties modifying someone else's products. Extending it to the original manufacturer is a teleological development that the text of the Regulation does not contain. In practical terms it is the right call, since the draft's rule would have deterred manufacturers from shipping security-relevant updates to installed fleets and thereby undermined the very objective of the Regulation. Legally it remains exposed. A market surveillance authority relying on recital 39 is not bound by non-binding guidance. Manufacturers should therefore document the partial compliance route rigorously, in particular the assessment that the modification does not negatively affect the product as a whole.
The expanded safe harbours for updates deserve attention as well. That security updates do not constitute a substantial modification is stated by the EU CRA itself, in Article 3(30) read with recital 39, so this part is mere confirmation. What is new: even unanticipated new functionalities are harmless as long as they do not worsen the risk profile, only adverse effects count, and the reference point is the current risk assessment rather than the original one. Since the risk assessment must be kept up to date under Article 13(3) anyway, this last point is phrased inconspicuously but carries real weight. A manufacturer who maintains its risk assessment with discipline legitimately shifts the yardstick against which future updates are measured.
On spare parts, the guidance reads the wording of Article 2(6) ("spare parts made available to replace identical components") functionally. Identical is what does not change the security-relevant characteristics, so a replacement module with a different chipset and updated firmware can still be "identical". This stretches the term noticeably, is owed to the realities of component obsolescence, and reverses the answer the draft had given in the very same example. It comes at a price, though: a new procedural hurdle without an express basis in the Regulation. The exemption applies only where the repair purpose is evident from the supply context, and "supporting evidence" must be kept available for market surveillance authorities. What exactly counts as sufficient evidence, whether order processes, after-sales channels or case-by-case documentation, the guidance leaves open. That is the next grey area.
4. Support period: a creative solution with residual risk
Article 13(8) EU CRA requires a support period that reflects the expected use time, and no less than five years unless the expected use time is shorter. Since every substantial modification counts as a new placing on the market, the draft left an obvious follow-up question unanswered: does the five-year clock restart with every substantially modified release? Taken to its logical conclusion, that would have meant perpetual support obligations for continuously developed products.
The new section 5.1 resolves this. A substantial modification triggers a reassessment against the criteria of Article 13(8) but does not automatically result in a reset or extension. Where the factors determining the use time remain unaffected, for instance after a backend re-architecture while the hardware determines the product's lifetime, the remaining expected use time applies, expressly even where it is less than five years. Only where the determining factors change, say through revitalising hardware modifications or a rewrite of the core software, is the support period recalculated.
The same caveat applies as above: practically convincing, dogmatically not compelled. The wording of Article 13(8) ties the five-year floor to the placing on the market of the product, and the substantially modified product is, on the system's own logic, a newly placed product. The remaining-use-time reading is an interpretation in the manufacturers' favour that the guidance carries but the text of the Regulation does not expressly cover.
The relationship to paid support was also clarified, and here the guidance merely tracks the law. Annex I Part II point 8 requires free security updates only within the product's update mechanics, and Article 13(10) governs the case of diverging versions. The guidance concludes that paid extended support for earlier versions is permissible as long as the free upgrade route remains open, which puts commercial LTS models on solid ground. Worth noting: the concrete eight-year figure in the draft's smartphone example was replaced by "X years". The Commission visibly does not want to set industry benchmarks and instead refers, for the first time, to future ADCO guidance as a source of orientation. That in itself is a new unknown, because the actual concretisation of support periods is delegated to a body whose pronouncements are even less formalised than the guidance.
5. Important and critical products: where the screws are tightened
Chapter 6 is the counterweight to the reliefs. The concept of core functionality, decisive for classification under Articles 7 and 8 in conjunction with Annexes III and IV, is objectivised. What counts are the actual technical features, "not the way in which the product is described or marketed". The draft had made the manufacturer's own statements in instructions for use and marketing the primary yardstick, a gateway for declassification on paper that the final version closes. A consistent addition follows: functionalities that merely complement or enhance the core functionality do not take the product out of the category. Feature stuffing as a classification strategy is off the table.
The sharpest practical innovation is the module rule. Where modules of a suite are also marketed separately, by purchase, licence or subscription, they are standalone products and must be classified individually. The new example shows what that means. The SIEM module of a security suite lands in Class I, the intrusion detection module in Class II with mandatory third-party assessment under Article 32(3), and the analytics module in the default category. The distribution model thus becomes directly compliance-relevant, which creates both a new grey area and a steering incentive. A vendor that offers modules only in a bundle classifies at suite level. Whether market surveillance authorities will treat pure bundling strategies as circumvention is open, but the anti-circumvention logic of the guidance hands them the arguments.
On the relief side, the presumption of conformity under Article 27 arises partially, for the risks covered by a harmonised standard, rather than only upon full coverage as the draft suggested. This matches established New Legislative Framework doctrine as set out in the Blue Guide, so it is less a change of course than the correction of an error.
6. Remote data processing: a narrowing with an open flank
Article 3(2) EU CRA defines remote data processing as data processing at a distance for which the software is designed and developed by the manufacturer or under its responsibility, and the absence of which would prevent the product from performing one of its functions. The draft operationalised this via data segregation. The final version replaces that with a clear two-tier model: RDPS comprises only the software modules with which the product directly interacts, plus their interfaces. Downstream systems, in the banking example expressly account management, ledger, settlement and clearing, are not RDPS.
This is the clarification the financial sector had demanded, and it is dogmatically more honest than the draft. The guidance openly concedes that the availability of these backends "may be necessary for a function to be completed", which means that on the pure wording of Article 3(2) they could well be caught. The direct-interaction criterion is not in the text of the Regulation. It is a teleological narrowing that makes the conformity assessment scope manageable, urgently needed in practice, but not the only possible reading of the law.
One change pulls in the opposite direction. The draft accepted contract-developed software as RDPS "under the responsibility of the manufacturer" only where the technology is owned, not licensed, by the manufacturer. That sentence has been deleted without replacement. What matters now is solely that the software was built by or on behalf of the manufacturer, based on its designs and specifications, so contractual constructions with the development service provider no longer shield against the qualification. The final version also recognises the shared responsibility model of cloud providers as a contribution to fulfilment. In substance this tracks what Article 13(5) due diligence, applied on a risk basis, permits anyway, but it is named expressly for the first time.
7. Reporting obligations: confirmation of the prevailing reading, with valuable new exemptions
Chapter 9 was expanded the most. Its core statement is no surprise but a consistent follow-through on what the expert community had long agreed upon: the reporting obligations of Article 14 EU CRA (early warning within 24 hours, notification within 72 hours, final report, each to ENISA and the CSIRT via the single reporting platform of Article 16) apply from 11 September 2026 to all products in scope, expressly including legacy products placed on the market before 11 December 2027, and they continue beyond the end of the support period.
A look at the law shows why this was never seriously in dispute. Article 71(2) orders the early application of Article 14, and unlike the vulnerability handling obligations of Annex I Part II, which Article 13(8) ties to the support period, Article 14 contains no temporal limitation. That the guidance now puts this in black and white is simply consistent. We had already advanced this reading in April in our Friday Facts on legacy products. The value lies in the express confirmation: anyone who was still arguing the opposite position internally has now definitively lost that line of defence. The consequence stands. Reporting monitoring is needed for discontinued products too, but without any patching obligation, since the guidance clarifies in mirror image that no obligations under Annex I Part II apply to legacy and post-support products.
What the reporting obligation means operationally from 11 September 2026, from deadlines and mandatory fields per reporting stage to the moment of awareness, the process map and a preparation checklist, is something we dissected clause by clause in our guide EU CRA reporting obligations: the only article you need to read before 11 September 2026. The separation described there between the receipt of a lead and verified awareness matches the line of the final guidance exactly. On the sanction risks, and infringements of Article 14 sit in the highest fine bracket, see our overview of EU CRA penalties for non-compliance.
The obligation is cushioned in three ways, and here the consultation was visibly effective. There is no retroactivity: active exploitations already known before the cut-off date need not be reported after the fact. There is a VEX-style exemption for vulnerabilities in third-party components that are not exploitable in one's own product, for instance because the vulnerable code is not reachable. This is a massive relief against the CVE flood in dependency trees, one the draft did not contain, and it is practically unusable without a current SBOM and sound vulnerability management, because the exploitability analysis presupposes knowing one's components. And OSS maintainers get protection in upstream reporting under Article 13(6): reporting should run via the maintainer's CVD channels, duplicate reports of already-known vulnerabilities are not required, and fix sharing was softened from "required" to "should".
Two details deserve attention. The Commission deleted the explicit reference to the CVE List maintained by MITRE, and the only database still named is the European EUVD. Against the backdrop of the debates about the funding of the US CVE system, that reads as a signal of digital sovereignty. The guidance also records for the first time that AI-powered vulnerability findings constitute awareness, which is relevant for the "known exploitable vulnerability" under Article 3(41) and the obligations before placing on the market. This is consistent, but it creates an awkward incentive: whoever tests aggressively with AI scanners produces awareness, and with it obligations, that a more reticent competitor does not have. The new flexibility on release decisions, where the risks of withholding a release may be weighed, and the event-driven rather than calendar-driven testing regime of the new section 9.2.3 only partially offset this.
Taking stock: three categories of changes
Anyone assessing the final guidance should keep three categories apart.
The first is tracking the law or the prevailing reading, important but not new: the SaaS boundary (Article 3(1), recital 12), the donation criteria (recital 15), the harmlessness of security updates (Article 3(30)), the early application of the reporting obligations to legacy products (Article 71(2), never seriously disputed among practitioners), the permissibility of paid extended support (Article 13(10), Annex I Part II point 8), and the partial presumption of conformity (Article 27, NLF doctrine).
The second is genuine, at times bold interpretation, practically valuable and legally exposed because the text of the Regulation does not expressly carry it: partial compliance upon substantial modifications by the original manufacturer (extending the rationale of Article 22(2) beyond its scope of application), the non-reset of the support period including going below the five-year floor, the functional reading of "identical" for spare parts (Article 2(6)), and the direct-interaction criterion for RDPS (a narrowing of Article 3(2)). One can rely on these positions, but one should know that a non-binding guidance carries them rather than the statutory text, and set up one's documentation accordingly.
The third is new grey areas, questions the guidance raises that did not exist before. What is a "variant" (para. 14)? Where does "merely complement or enhance" end under the anti-circumvention rule? Does bundling separately marketable modules make classification steerable, and at what point does that become circumvention? What "supporting evidence" suffices for spare parts? How does one prove the "confirmed awareness" of an upstream maintainer in order to dispense with a duplicate report? And how much concretisation can one expect from the ADCO, to which the guidance delegates support period practice?
What to do now
Five items belong on every EU CRA agenda for the third quarter of 2026. Review the product portfolio against section 2.2 and the variants rule: what is a product, what is a service, what counts as a standalone variant? Classify separately marketed modules individually and take a deliberate decision on the distribution structure, because unplanned third-party assessment obligations lurk here. Build an Article 14 reporting process by 11 September 2026 that includes legacy and post-support products and operationalises the VEX exemption through exploitability analysis; the concrete step-by-step preparation including a checklist is in our reporting obligations guide, and the placement within the overall timeline in the EU CRA roadmap 2026/2027. Align update and change processes with the partial compliance logic and the continuously maintained risk assessment as the reference point, with robust documentation, precisely because the guidance goes beyond the statutory text here. And set up spare parts distribution with a documented repair purpose.
One overarching guardrail remains. The guidance is orientation, not a free pass. It binds no authority and no court, and its most generous passages are at the same time its most contestable. Whoever relies on it should do so expressly and with documentation. In a dispute, that makes it at least a strong argument for defensible, good-faith conduct.
This article is based on a complete paragraph-by-paragraph comparison of the consultation draft of 3 March 2026 with the version C(2026) 5252 final adopted on 27 July 2026, as well as the text of Regulation (EU) 2024/2847. It does not constitute legal advice. Get in touch if you would like to assess the implications for your product portfolio.
Further reading on the Kunnus blog
- EU CRA Reporting Obligations: The Only Article You Need to Read Before 11 September 2026
- CRA Friday Facts: When the CRA Hits Legacy Devices Too
- Cyber Resilience Act and SaaS
- Vulnerability Management under the EU CRA
- How to Create an SBOM: The Practical Guide
- EU CRA Countdown: Compliance Roadmap 2026–2027
- EU CRA Penalties for Non-Compliance
Sources and further links
- EU Commission guidance C(2026) 5252 final, original PDF and our chapter-by-chapter overview
- European Commission: Cyber Resilience Act policy page
- "Have your say" consultation portal with stakeholder feedback
- ORC Working Group (Eclipse Foundation): Open Source Software Stewards and the CRA
- GitHub Blog: What the EU's new software legislation means for developers