The European Commission's final Cyber Resilience Act (CRA) guidance changes how you determine whether your IoT product or software requires new compliance work. You're facing a decision that affects your security support obligations, incident reporting timelines, and product lifecycle planning.
This isn't theoretical. Starting September 11, 2026, you must report severe security incidents. By December 11, 2027, your products must meet the CRA's security design and maintenance requirements. Between now and then, you need to classify your products correctly and understand when modifications trigger compliance resets.
The Decision You Are Facing
Your team needs to answer three interconnected questions:
- Does your product fall within the CRA's scope?
- If yes, when do product modifications create new compliance obligations?
- How do modifications affect your security support period?
Get these wrong and you'll either waste resources on unnecessary compliance work or face enforcement action for missing obligations.
Key Factors That Affect Your Choice
Where the software executes determines scope. The final guidance removes all references to "remote access" and adds explicit language: software must be "provided to a user, obtained by that user and operated on, or as part of, an electronic information system on the user's side."
The nature of your modification determines whether you're creating a new product under CRA terms. The commission distinguishes between updates that maintain your existing risk profile and those that fundamentally change it.
Your product's expected use time determines support period calculations. Hardware durability, typical replacement cycles, and the modification's impact on operational lifetime all matter.
Your organizational role in open-source projects determines manufacturer status. Having commit access doesn't make you responsible unless you control releases, roadmaps, or governance decisions.
Path A: Your Product Is Out of Scope
Choose this path if:
Your software executes remotely and users only access it through a browser. Web apps that run server-side fall here. The guidance now states clearly: "Software that executes remotely and is merely accessed by the user is not, on that basis alone, a product with digital elements."
Websites themselves aren't covered unless they support the functionality of a covered product through remote data processing. Your marketing site? Not covered. Your cloud-based SaaS dashboard that users access via browser? Not covered.
What this means for you:
You don't need to comply with CRA security design requirements, vulnerability handling processes, or the December 11, 2027 compliance deadline. You still face other regulations like the General Data Protection Regulation (GDPR) and NIS2 Directive, but the CRA's product-specific obligations don't apply.
Watch out for:
Browser extensions and locally-run applications built with web technologies are covered, even if they use web tech stacks. If your "web app" downloads components that execute client-side, you're back in scope.
Path B: Your Modification Doesn't Trigger New Compliance
Choose this path if:
You're introducing new functionality that was already included in your mandatory risk assessment, or the new features "do not, in themselves, alter the cybersecurity risk profile of the product."
Security updates always follow this path, even when they "may introduce significant technical changes." The guidance explicitly confirms that patches reducing cybersecurity risk aren't substantial modifications, regardless of how much code changes.
What this means for you:
You continue operating under your existing compliance framework. Your support period doesn't reset. You don't need to redo conformity assessments or update your CE marking documentation.
Example scenario:
Consider a smart thermostat manufacturer adding new scheduling algorithms and energy optimization features. If your original risk assessment covered "user-configurable automation features" and the new algorithms don't introduce new attack surfaces or data handling requirements, you're making a non-substantial modification.
Document this decision:
Maintain clear records showing why the modification doesn't alter your risk profile. When supervisory authorities review your compliance, they'll want evidence that you considered the question seriously.
Path C: Your Modification Creates a New Product
Choose this path if:
Your modification introduces functionality that wasn't contemplated in your original risk assessment and changes the cybersecurity risk profile. You're adding new connectivity protocols, expanding data collection, or enabling features that create new threat vectors.
What this means for you:
You're effectively creating a new product under CRA terms. You need to conduct a fresh risk assessment, update your technical documentation, and potentially go through conformity assessment again depending on your product classification.
But here's the critical clarification: A substantial modification "does not automatically result in the support period being reset, or even extended."
Support period decision tree:
If the modification doesn't affect factors that determined your product's expected use time, continue your original support period. The guidance gives the example of a robot vacuum cleaner gaining new cleaning modes and navigation features. The software changes substantially, but the hardware still wears out on the same timeline.
If the modification extends operational lifetime beyond what you previously forecast, recalculate the support period to reflect the new expected use time. This applies when you're adding capabilities that make users keep the product longer.
Physical repairs and refurbishments don't trigger support period recalculations.
Version support and charging:
You can provide security updates for older versions on a paid basis or under commercial arrangements. The CRA doesn't require free updates for versions users choose not to upgrade from, as long as you're offering the latest version without additional cost.
Open-Source Role Clarification
If you contribute to FOSS projects without controlling releases, roadmaps, or governance, you're not a manufacturer under the CRA. The guidance now provides explicit examples confirming that commit access alone doesn't create liability.
For open-source software stewards providing sustained support, you can exit that role by ceasing systematic support. When you do, communicate the status change clearly to avoid confusion about ongoing obligations.
Summary: Your Decision Matrix
| Your Situation | CRA Scope | Compliance Reset | Support Period Impact |
|---|---|---|---|
| Web app accessed via browser only | Out of scope | N/A | N/A |
| Browser extension or local app | In scope | Depends on modification | Depends on modification |
| Security update (any technical scope) | In scope | No reset needed | No change |
| New features within original risk assessment | In scope | No reset needed | No change unless use time extends |
| New features changing risk profile | In scope | Full compliance reset | Recalculate if operational lifetime extends |
| FOSS contributor without governance role | Out of scope | N/A | N/A |
| FOSS steward providing sustained support | In scope | Depends on modification | Can exit steward role by ending support |
The commission's final guidance provides the clarity you need to make these decisions defensibly. Your next step is reviewing your product portfolio against these criteria before the September 11, 2026 incident reporting requirement takes effect.
