The EU Cyber Resilience Act (CRA) became law in December 2024. For most organisations that develop and sell software or hardware products, it represents the most significant new product security regulatory obligation since GDPR. Unlike NIS2 — which governs how organisations protect their own infrastructure — the CRA governs the security of products you place on the EU market.
If your organisation develops software (SaaS, on-premise, embedded), manufactures connected hardware, or produces components that others embed in their products and those products are sold in the EU, the CRA applies to you. The penalties are substantial (up to €15 million or 2.5% of global annual turnover), and the personal liability provisions are real.
The Key Dates
June 11, 2026 (already passed): Conformity assessment bodies were required to be designated. Notifying authorities became operational.
September 11, 2026: Vulnerability reporting obligations take effect. Manufacturers must notify ENISA of actively exploited vulnerabilities and security incidents affecting their products within 24 hours (early warning) and 72 hours (full notification). This obligation applies regardless of the full December 2027 enforcement date.
December 11, 2027: All essential cybersecurity requirements and manufacturer obligations apply in full. Products placed on the EU market must carry a CE marking demonstrating CRA compliance.
The September 2026 reporting deadline is three months away. If you have not yet built a vulnerability notification process for the EU market, this should be your immediate priority.
Who Is In Scope
The CRA applies to “products with digital elements” — any software or hardware product with data processing capability that connects (directly or indirectly) to a network or another device. The scope is intentionally broad:
- Commercial software (on-premise and SaaS where the software itself is licensed)
- Firmware and embedded software in connected devices
- Operating systems, middleware, application software
- IoT devices, consumer electronics, industrial equipment
- Software components that are sold or transferred (not internal tools)
Notable exclusions: Open-source software made available without commercial support is largely exempt, though commercial entities that monetise open-source (via support contracts, hosted services) are in scope for those commercial activities. Medical devices under MDR and aviation equipment under EASA regulations have separate regimes, but CRA principles apply where those regimes don’t fully cover.
The Essential Requirements (What You Must Build)
Annex I of the CRA specifies security requirements that all in-scope products must meet at the time of placing on the market and throughout their lifetime. The requirements are principle-based rather than prescriptive, but the practical implications are clear:
No known exploitable vulnerabilities at time of release: Products may not contain known, unaddressed vulnerabilities of significance when placed on the market. This does not mean zero vulnerabilities — it means reasonable security hygiene applied before release.
Secure by default: Products must ship with a secure default configuration. This means no default passwords, no unnecessary open ports, no unnecessary services enabled, and appropriate access controls active from first use.
Data minimisation and protection: Products must only process the personal data necessary for their function, and must protect it appropriately in transit and at rest.
Confidentiality and integrity of data: Encryption of data in transit and at rest is an explicit requirement where applicable.
Vulnerability handling throughout the support lifetime: Manufacturers must maintain the ability to address vulnerabilities throughout the product’s expected lifetime and communicate the expected support period to users.
Software Bill of Materials (SBOM): Manufacturers must produce a machine-readable SBOM covering at least the top-level dependencies of every product, keep it current, and provide it to market surveillance authorities on request. The practical implication is that you need a mature dependency tracking process and tooling (Syft, CycloneDX, SPDX) across your product portfolio.
Product Categories and Conformity Assessment
The CRA distinguishes between:
Default products: The majority of in-scope products. These may self-certify conformity by following the essential requirements and conducting an internal assessment. Manufacturers prepare a Declaration of Conformity and technical documentation.
Important products (Class I): Products that pose higher cybersecurity risk due to their intended use in critical sectors or their central role in a system’s security. Examples include identity management software, password managers, VPN products, network intrusion detection systems, and software components used in critical infrastructure. Class I products require third-party involvement (internal assessment following harmonised standards, or third-party certification body assessment).
Critical products (Class II): The highest-risk category. Examples include hardware security modules, industrial automation systems for safety-critical applications, and smart meter gateways. Class II products require third-party conformity assessment.
For CISOs at software companies, the first question is: which category do our products fall into? Products that handle authentication, network security, or that are embedded in critical infrastructure are likely Class I. Products used in safety-critical industrial or medical contexts are likely Class II.
The Vulnerability Disclosure and Notification Process
This is the element that requires operational action before September 2026.
Under Article 14, manufacturers must report to ENISA:
- Within 24 hours of becoming aware of an actively exploited vulnerability: an early warning
- Within 72 hours: a vulnerability notification including any available information about the vulnerability
- No later than 14 days after a fix is available: a final report
Simultaneously, you must notify the relevant computer security incident response team (CSIRT) in the EU member state where the manufacturer is established.
The practical requirements:
- A process for identifying that a vulnerability in your product is being actively exploited in the wild
- An escalation path to responsible parties who can initiate the ENISA notification
- Relationships with your relevant national CSIRT
- A coordinated vulnerability disclosure (CVD) programme for receiving external vulnerability reports
If you do not have a CVD programme with a documented intake process, this is overdue. The security.txt RFC 9116 standard provides the baseline — publish a /.well-known/security.txt file with your disclosure contact information.
Penalties and Liability
The CRA’s penalty structure mirrors GDPR:
- Violation of essential security requirements (Annex I): up to €15 million or 2.5% of global annual turnover
- Violation of obligations (Article 10-16, including SBOM, support period, reporting): up to €10 million or 2% of global annual turnover
- Providing false information to authorities: up to €5 million or 1% of global annual turnover
For software products sold in the EU market, these are enterprise-level penalties. Market surveillance authorities in EU member states have the power to require product withdrawal and recall.
What CISOs Should Prioritise Now
Given the September 2026 reporting obligation date and the December 2027 full enforcement deadline, a realistic prioritisation:
Immediate (before September 2026):
- Map your product portfolio: which products are in scope, what CRA category do they fall into
- Establish a formal CVD process with
security.txtand a documented intake/triage SLA - Build the ENISA notification process: who is authorised to file, what information is needed, where the ENISA reporting portal is
- Identify your national CSIRT contact
Short-term (before December 2027):
- Deploy SBOM generation tooling across all product build pipelines
- Document the expected security support lifetime for each product and communicate it to customers
- Conduct a gap assessment against Annex I requirements for your highest-risk products
- Engage a conformity assessment body if any products are Class I or Class II
- Update software development lifecycle (SDLC) to embed security requirements as defined in Annex I
Governance:
- Ensure the board and executive team understand CRA obligations. Unlike NIS2, CRA liability attaches to the manufacturer as an entity — not to individual executives. However, investor pressure and customer contract provisions will put CRA compliance squarely in front of leadership.
- Update contracts with software component suppliers to include CRA-relevant provisions around vulnerability disclosure and support lifetimes.
The CRA represents a structural shift: security is no longer something you bolt onto products post-release. It becomes a condition of market access. Organisations that have already invested in secure development practices, dependency management, and vulnerability disclosure programmes will find compliance straightforward. Those that haven’t should treat the December 2027 date as a hard deadline requiring a funded programme starting now.