The Cyber Resilience Act (CRA) can affect organizations in any industry that make products with digital elements available in the EU. Applicability depends on the product and the organization’s role in bringing it to market, not on a fixed list of regulated industries.
Commercial software, connected hardware, IoT devices, industrial systems, network products, and integrated cloud functionality may all be covered. Companies based outside the EU can also be affected when their products enter the European market.
From September 11, 2026, CRA reporting obligations apply to actively exploited vulnerabilities and severe security incidents. Most other CRA requirements apply from December 11, 2027.
Is your product within the scope of the CRA?
A product is likely to require further CRA assessment when:
- It contains software or connected hardware.
- It connects directly or indirectly to a device or network.
- The organization acts as its manufacturer, importer, or distributor.
- It is not covered by a specific CRA exclusion.
- It is made available on the EU market through commercial activity.
The definition can also include remote data-processing functionality developed for a product when the product cannot perform one of its functions without it. This means an integrated cloud backend may be part of the regulated product, even though a standalone cloud service may not be.
Software developed exclusively for internal use and never made available on the EU market may fall outside the product scope. That conclusion depends on how the software is developed, transferred, licensed, and used.
Which industries are affected by the CRA?
Software and technology
Commercial operating systems, applications, developer tools, security products, on-premises platforms, and downloadable software can qualify as products with digital elements.
Standalone SaaS is not automatically covered. However, cloud functionality that is integral to a covered product may be included as a remote data-processing solution. Cloud providers may also face separate obligations under NIS2, DORA, or other legislation.
Consumer electronics and IoT
Smart-home systems, routers, cameras, wearables, connected appliances, toys, and their supporting software are typical products with digital elements. Manufacturers must consider both the device software and the components and services necessary for the product to function.
Manufacturing and industrial technology
Connected machinery, robotics, industrial control systems, sensors, operational technology, and related software may fall within scope. CRA requirements operate alongside standards such as IEC 62443 and IEC 61508 rather than replacing them.
Financial services and fintech
Financial services are not broadly exempt from the CRA. Commercial fintech products, payment software, authentication products, and software supplied to financial institutions may be covered.
DORA primarily governs the operational resilience of financial entities and their ICT relationships. The CRA governs products with digital elements. A company or product ecosystem may therefore need to consider both.
Healthcare and life sciences
General healthcare applications, administrative platforms, wellness products, and connected technology outside the medical-device regime may fall under the CRA.
Medical devices and in vitro diagnostic medical devices covered by designated EU legislation are excluded because they are already governed by sector-specific product safety, lifecycle, and conformity requirements.
Automotive and mobility
Vehicles in categories M, N, and O, along with systems and components designed exclusively for them, are excluded where Regulation (EU) 2019/2144 applies.
Commission Delegated Regulation (EU) 2025/1535 extends this exclusion to products covered by Regulation (EU) No 168/2013, including L-category vehicles such as motorcycles and mopeds.
This does not exempt the entire automotive industry. Aftermarket products, charging technology, fleet software, mobility platforms, and components sold outside the regulated vehicle supply chain may still require CRA assessment.
Telecommunications and network infrastructure
Firewalls, VPN products, routers, switches, operating systems, network-management software, and other infrastructure products may fall within scope. Some may be classified as important or critical products and face stricter conformity-assessment requirements.
Energy and utilities
Smart meters, connected monitoring equipment, control systems, and software products used in energy infrastructure may be covered when made available on the EU market. Operators may also have separate obligations under NIS2 and sector-specific rules.
AI software and AI-enabled products
AI functionality does not remove a product from CRA scope. AI software or an AI-enabled device may be covered when it qualifies as a product with digital elements.
The CRA also does not distinguish between human-written and AI-generated code. The manufacturer remains responsible for the security of the complete product.
What is exempt from the Cyber Resilience Act?
CRA exemptions generally apply to particular products, not entire organizations or industries.
How does the CRA treat open-source software?
Free and open-source software developed or supplied outside commercial activity is excluded from full CRA manufacturer obligations. This protects individual contributors and non-commercial development from disproportionate requirements.
However, the CRA introduces the legal category of an open-source software steward. These are legal persons, other than manufacturers, that provide sustained support for FOSS intended for commercial activities.
Under Article 24, stewards face a lighter set of obligations. These include establishing and documenting a cybersecurity policy, supporting effective vulnerability handling, cooperating with market-surveillance authorities, and reporting actively exploited vulnerabilities where required.
A company that monetizes a version of FOSS may be treated as a manufacturer for that commercial version. Manufacturers that integrate open-source components into their products also remain responsible for assessing and managing the resulting product risk.
Not every covered product follows the same conformity route
Most products with digital elements fall into the default category and may qualify for manufacturer self-assessment.
Products listed as important Class I, important Class II, or critical face additional requirements. Depending on their classification and the use of recognized standards, these can include third-party conformity assessment. Classification depends on product function and cybersecurity risk, not simply on industry.
How SonarQube helps streamline CRA compliance across industries
Every industry has different products and regulatory overlaps, but the engineering challenge is similar: organizations must apply security standards consistently, understand their software components, remediate vulnerabilities, and produce evidence that controls are operating.
SonarQube brings these CRA-supporting controls into normal development workflows.
Centralize standards and release controls
Quality profiles define the security, reliability, and maintainability rules applied to each project. Quality gates define the conditions code must meet before it progresses.
This allows organizations to apply common standards across teams, repositories, products, and human or AI contributors instead of relying on project-specific manual checks.
Support secure-by-default development
SonarQube uses SAST, Advanced SAST, secrets detection, and Infrastructure as Code analysis to identify vulnerabilities, exposed credentials, weak cryptography, permissive privileges, and insecure configurations.
Feedback can be delivered in the IDE, pull request, and CI/CD workflow so issues are addressed before release. Quality gates can be connected to merge controls to prevent changes that fail defined standards from progressing.
Identify vulnerabilities across code and components
SonarQube analyzes first-party code while Advanced Security adds visibility into third-party open-source components.
Software Composition Analysis identifies direct and transitive dependencies from project manifests and lockfiles, matches components against updated vulnerability intelligence, and continues reassessing existing dependencies as new risks are disclosed.
Establish component transparency
Advanced Security records dependency names, versions, scopes, licenses, package managers, and dependency paths. Project, application, and portfolio views help teams identify where components are used across the software estate.
Organizations can export CycloneDX or SPDX SBOMs at release time and retain them with the appropriate product records.
Bring remediation into engineering workflows
SonarQube provides issue context and dependency upgrade guidance to help teams act on identified risks.
The SonarQube Remediation Agent can address eligible backlog issues at scale, while Gitar supports remediation within active pull requests. Updated code is then independently reanalyzed before it passes the quality gate.
Produce code-level evidence and reporting
Analysis results, quality-gate outcomes, issue histories, dependency-risk records, remediation activity, security reports, and available audit logs can support CRA documentation and evidence processes.
SonarQube also provides CRA-focused security reporting. These outputs support compliance work but do not perform conformity assessments, submit statutory notifications, or certify that a product is compliant.
Govern AI-generated and agent-modified code
AI can significantly increase the volume and speed of software change, but it does not change the manufacturer’s CRA responsibilities.
Sonar Vortex brings relevant context and verification into agentic development as code is created. SonarQube then applies independent analysis and centralized quality gates to the complete change before merge.
This gives human-written, AI-generated, and agent-modified code the same governed path from creation through verification, remediation, and release.
Make CRA controls part of normal development
CRA readiness should not depend on collecting screenshots and reconstructing development activity before an audit. Code verification, component visibility, remediation, and evidence generation need to operate continuously within engineering workflows.
By centralizing these controls, SonarQube helps organizations strengthen the technical foundation of CRA compliance regardless of their industry, product portfolio, or mix of human and AI development.
Sources: European Commission CRA summary, CRA legal text, 2026 Commission implementation guidance, Commission Delegated Regulation (EU) 2025/1535, and SonarQube CRA capability mapping.