The European Commission's final Cyber Resilience Act (CRA) guidance, released in July 2026, introduced changes that caught many compliance teams off guard. These revisions clarify what triggers compliance obligations, who's responsible for open-source components, and when modifications reset your security support clock. Yet misconceptions persist in vendor calls and planning sessions.
These myths arise because the CRA introduces unfamiliar compliance mechanics. Unlike the General Data Protection Regulation's processor-controller model or ISO/IEC 27001's control-based approach, the CRA ties obligations to product characteristics and lifecycle events. This is new territory for teams used to organizational certifications rather than product-specific conformity assessments.
Here's what you need to correct before Dec. 11, 2027, when full compliance becomes mandatory.
Myth 1: Any Software Update Could Trigger New Compliance Work
Reality: Security updates never qualify as substantial modifications under the CRA, even when they introduce significant technical changes. The final guidance states that updates aimed at reducing cybersecurity risk don't restart compliance obligations, regardless of their complexity.
Your patch management shouldn't require legal review at every sprint. If you're fixing a vulnerability in your IoT device firmware or pushing a critical security fix to your browser extension, you're maintaining the existing product's security posture, which is expected during your support period.
The substantial modification trigger applies when you introduce new functionalities not covered in your original risk assessment that alter the product's cybersecurity risk profile. Adding two-factor authentication to a product that previously had none is a security improvement, not a substantial modification. However, adding a new AI-powered analytics module that processes user data in unassessed ways requires evaluation.
Myth 2: Web Applications Fall Under CRA Scope
Reality: The final guidance specifies that software must be "operated on, or as part of, an electronic information system on the user's side" to qualify as a product with digital elements.
This narrows the scope from the draft. Your SaaS dashboard that runs entirely on your infrastructure and is accessed through a browser isn't covered. Your browser extension that executes locally is covered. Your Electron-based desktop application built with web technologies is covered.
The commission clarifies that software executing remotely and merely accessed by the user isn't a product with digital elements. Websites that execute some code on the user's device aren't products under the CRA unless they support the functionality of an actual product with digital elements.
This distinction should reshape your compliance prioritization. If you're supporting both a locally-installed IoT management application and a web-based monitoring portal, focus your compliance resources on the installed application first.
Myth 3: Substantial Modifications Always Reset Your Support Period
Reality: The final guidance states that substantial modifications don't automatically reset or extend the support period. The key factor is whether the modification affects what originally determined the product's expected use time.
For example, a robot vacuum cleaner receiving new cleaning modes through a software update qualifies as a substantial modification. However, this doesn't extend the vacuum's operational lifetime. The hardware components still have the same durability, so the support period continues based on the original expected use time.
You only recalculate the support period when a substantial modification extends the product's operational lifetime beyond what you initially foresaw. Document your original expected use time analysis thoroughly. When questions arise about whether a modification extends that timeline, reference the specific factors that informed your original calculation.
Myth 4: Open-Source Contributors Face Compliance Liability
Reality: FOSS project contributors aren't responsible for CRA compliance unless they control releases, roadmaps, or governance decisions. The final guidance provides explicit examples, clarifying that commit access alone doesn't create liability.
This addresses a concern that nearly derailed the CRA's development. Individual contributors to open-source projects you incorporate into your commercial IoT products aren't responsible for conformity assessments. The obligations fall on you as the manufacturer or on open-source software stewards who provide systematic, sustained support for FOSS meant for commercial integration.
The guidance also clarifies an exit path for stewards: "Where an entity ceases to provide systematic support on a sustained basis for a specific FOSS, it may no longer meet the definition of steward and may therefore no longer be subject to the corresponding obligations." If you're a foundation evaluating whether to continue supporting a particular project, you can step back from that steward role by clearly communicating the change in status.
Myth 5: You Can't Charge for Security Updates to Older Versions
Reality: While users must be able to upgrade to the latest version without additional cost, manufacturers can choose to address vulnerabilities in earlier versions on a paid basis or under other commercial arrangements.
The final guidance includes this clarification in a footnote, but it has significant implications for your support model. You're required to provide security updates for the current version throughout the support period at no additional charge. But if customers want to stay on an older version for compatibility or operational reasons, you can offer extended security support as a paid service.
This aligns with established enterprise software practices while maintaining the CRA's consumer protection intent. Ensure your documentation clearly distinguishes between the free security support period for current versions and any commercial arrangements for legacy version support.
What to Do Instead
Start with a product inventory that distinguishes between locally-executed software and remotely-accessed services. Your compliance scope just narrowed significantly if you've been treating all software offerings equally.
Document your risk assessments with enough breadth to cover foreseeable feature additions. When you can show that new functionality was already within the assessed risk profile, you avoid the substantial modification trigger.
Calculate expected use time based on specific, documented factors: hardware component durability, typical industry replacement cycles, and technological obsolescence patterns. You'll need this foundation when evaluating whether modifications extend that timeline.
Review your open-source dependencies and identify which components come from stewards versus individual contributors. Your due diligence requirements differ substantially between these categories.
Mark Sept. 11, 2026, for incident reporting readiness. That obligation starts 15 months before full compliance, giving you a hard deadline to establish your severe security incident detection and reporting processes.
