The EU Cyber Resilience Act, known as CRA, is one of the broadest pieces of software regulation in the world. Unlike NIS2 or DORA, which target operators of critical services, CRA applies to almost every product with digital elements placed on the EU market. That means most software companies, most hardware companies that ship firmware, and many open source projects with commercial backing. Full enforcement is approaching, and the requirements are substantial. This guide explains what vendors need to do now.
What Is Actually Covered
CRA covers products with digital elements that can connect, directly or indirectly, to a device or network. Practically that includes operating systems, browsers, IoT devices, mobile applications, antivirus software, password managers, smart home devices, industrial control systems, and most modern software products. There are limited exclusions for products already covered by sector specific regulation such as medical devices, motor vehicles, civil aviation, and certain defense products.
If your product is sold or made available in the EU and has digital elements, assume it is in scope.
Classes of Products
CRA defines three classes with progressively heavier requirements:
- ▸Default class covers most products and requires manufacturer self assessment
- ▸Important class one covers products with elevated risk such as password managers, network management tools, and identity providers
- ▸Important class two covers products with the highest risk including firewalls, security information and event management, and certain industrial systems
Critical products such as smart meters and certain hardware security modules face additional third party conformity assessment requirements. Most software vendors will fall into the default or important class one.
The Core Obligations
Manufacturers must:
- ▸Design for security with risk based decisions documented across the product lifecycle
- ▸Conduct conformity assessment appropriate to the product class
- ▸Provide cybersecurity documentation to end users including vulnerability disclosure policies
- ▸Maintain support periods of at least five years for most products with free security updates
- ▸Report exploited vulnerabilities to ENISA within 24 hours of awareness
- ▸Report severe incidents with similar timelines
- ▸Conduct vulnerability handling through a coordinated disclosure process
- ▸Provide a software bill of materials for component identification
These are not vague aspirations. They are specific obligations with specific evidence requirements.
Vulnerability Disclosure and Handling
CRA mandates a coordinated vulnerability disclosure process that includes:
- ▸A public security contact with clearly defined scope and process
- ▸Acknowledgment timelines for reports received
- ▸Internal triage and response processes
- ▸Fix development prioritized by risk
- ▸Public disclosure coordinated with affected parties
- ▸Continuous monitoring of components and dependencies
Vendors that have not built this capability find it surprisingly difficult to bootstrap. It requires legal, engineering, communications, and customer success alignment.
Software Bill of Materials
CRA elevates the software bill of materials from best practice to legal expectation. A useful SBOM includes:
- ▸Direct and transitive dependencies with versions
- ▸Licensing information for compliance review
- ▸Component supplier identification
- ▸Known vulnerability associations through CVE references
- ▸Cryptographic component identification where applicable
- ▸Update mechanisms that show how components are maintained
The point is not the document. The point is that the manufacturer can answer questions about every piece of software in the product. Tools like CycloneDX and SPDX have become standard formats.
Lifecycle Support Obligations
CRA expects manufacturers to provide security updates for as long as products are reasonably expected to be in use, with a minimum of five years for many categories. This is a significant economic obligation. For some products, especially low margin consumer goods, it changes the business model. For B2B products, it is closer to what enterprise customers already expect, but it must now be documented and contracted.
Plan for the cost of long term support before the product ships, not after.
Open Source Considerations
Open source projects backed by commercial entities face complex obligations. Pure community projects with no commercial backing have more limited responsibilities. The line is not always clear. Vendors that build on open source need to assess whether their use creates manufacturer obligations. Many open source foundations are developing CRA conformity tooling and processes that can ease this burden.
If your product depends heavily on open source, engage with upstream projects to understand their CRA posture.
Conformity Assessment
For default class products, manufacturers conduct internal conformity assessment and affix CE marking. For important class products, more rigorous procedures apply, potentially including third party assessment for higher risk categories. Documentation must be maintained for at least ten years and made available to market surveillance authorities on request.
Conformity assessment is not a single point in time event. It is a continuous discipline that needs to be embedded in development practices.
Penalties That Have Teeth
CRA penalties include fines up to 15 million euros or 2.5 percent of global annual turnover, whichever is higher, for the most serious violations. National authorities can also order product withdrawals from the market. The economic consequences of non compliance are substantial enough that they should be a board level concern.
What to Do This Quarter
For most software vendors, a practical CRA preparation plan includes:
- ▸Classify products to understand which class each falls into
- ▸Establish vulnerability disclosure policies and processes
- ▸Generate SBOMs for all shipped products
- ▸Document the support lifecycle including security update commitments
- ▸Build incident reporting playbooks that meet 24 hour requirements
- ▸Update contracts with components and language about CRA obligations
- ▸Train engineering on secure development practices and CRA requirements
The vendors that complete this preparation early will turn it into a competitive advantage. The vendors that delay will find themselves scrambling under enforcement timelines that do not flex.
The Bigger Picture
CRA is part of a broader European push to make digital products as reliable and safe as physical ones. The era when software could ship without accountability for security outcomes is ending. Vendors that embrace this shift will build products that customers trust and competitors cannot easily match. Vendors that resist will discover that the cost of compliance is far smaller than the cost of fines, withdrawals, and reputational damage. The choice is becoming clear.