The EU Commission adopted the final Cyber Resilience Act guidance this week. I compared all 81 pages against the March draft. Here's what changed.

I work in CRA compliance (disclosure: I co-wrote the linked analysis for our company blog), and I spent the last day comparing the adopted guidance C(2026) 5252 final paragraph by paragraph against the consultation draft from March. Sharing the findings most relevant for security teams, since most coverage so far just announces that the guidance exists.

The stuff that actually matters for practitioners:

• Reporting obligations (Art. 14) start 11 September 2026 and cover products placed on the market before the CRA fully applies, and even products past their support period. This was the prevailing legal reading before, but the guidance now says it explicitly. Monitoring + reporting yes, patching obligations for EOL products no.
• A CVE in one of your dependencies is not reportable by itself. The final guidance added a VEX-style exemption: no Art. 14 report if the vulnerability isn't exploitable in your product (e.g. vulnerable code not reachable) or hasn't been exploited. Scanner findings, pentest results and researcher reports without active exploitation are also not reportable. The trigger is verified knowledge of active exploitation, and the clock starts at verification, not when the email lands, but you need timestamps proving you verified promptly.
• The explicit reference to MITRE's CVE List was deleted from the final version. Only the European EUVD is still named. Make of that what you will given the CVE funding situation.
• AI-powered vulnerability findings now legally constitute "awareness". If your AI scanner finds something exploitable pre-release, you know about it in the legal sense. Interesting incentive design.
• "Effective and regular tests and reviews" ≠ fixed re-test calendar. New section 9.2.3: it's an event-driven review process triggered by new threats/vulns. If a review finds no new input, no additional tests needed. Auditors can't demand a fixed cycle, but you need a documented review mechanism for the whole support period.
• Big one for legacy fleets: substantial modification of a pre-2027 product no longer requires bringing the entire product into full compliance. Only the modified parts, unless the change negatively affects the security of the whole product. The March draft demanded full compliance, which would have actively discouraged shipping updates to old products.
• SaaS/browser-only web apps are officially out of scope (NIS2 territory instead). Browser extensions and locally executed Electron-style apps are in.

Worth knowing: the guidance is non-binding. Several of the most generous positions (partial compliance, no support-period reset) go beyond what the regulation's text actually says, so a market surveillance authority could disagree. Document your reliance.

Full breakdown with paragraph references: https://kunnus.tech/en/blog/cra-commission-guidance-what-is-new

Original source (EU Commission announcement + adopted guidance): https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation

Curious how others are handling the September deadline, especially the verification-before-the-clock-starts part. Are you treating researcher reports as potential incidents (compromised build pipeline = reportable even without exploitation) or triaging them purely as vulns?