The EU Cyber Resilience Act (CRA), published as Regulation (EU) 2024/2847, entered into force on December 10, 2024. For the first time, the European Union imposes binding cybersecurity requirements on manufacturers of “products with digital elements,” including ERP software. The first reporting obligations apply from September 2026, with full compliance required by December 2027.
For CIOs and CISOs of European enterprises, this regulation changes the game: it transforms cybersecurity from a bilateral contractual issue into a verifiable regulatory obligation, with CE marking as proof.
The CRA Overview: Why Europe Regulates Digital Products
After NIS2 and DORA, the CRA Targets Products Themselves
Europe’s cybersecurity regulatory architecture now rests on three complementary pillars:
- NIS2 targets essential and important service operators (demand side)
- DORA regulates digital operational resilience in the financial sector (specific sector)
- The CRA regulates digital products themselves (supply side)
This distinction is fundamental. NIS2 says “you must secure your systems.” The CRA says “the products you buy must be secure by design.” For a CIO, this means compliance no longer rests solely on their shoulders: the ERP vendor now has legal obligations of their own.
Timeline: Three Key Dates
The CRA applies progressively according to a precise timeline (source: European Commission):
| Date | Obligation |
|---|---|
| June 11, 2026 | Member states establish conformity assessment bodies |
| September 11, 2026 | Vulnerability and severe incident reporting obligations take effect |
| December 11, 2027 | Full compliance required: security requirements, technical documentation, CE marking |
The critical point for businesses: from September 2026, any vendor who discovers an actively exploited vulnerability in their ERP must report it to ENISA within 24 hours via the unified reporting platform (CRA Reporting Platform).
Who Is Covered: Manufacturers, Importers, Distributors
The CRA applies to the entire supply chain of products with digital elements:
- Manufacturers (ERP vendors): primary responsibility, from design to product end-of-life
- Importers: must verify that non-EU products are compliant before market placement
- Distributors: must ensure CE marking and declared conformity
An integrator who distributes a non-European ERP in the EU market (a reseller of NetSuite or an Indian ERP, for example) becomes an importer under the CRA, with associated obligations.
What the CRA Requires from ERP Vendors
Security by Design and by Default
The CRA introduces “security by design, security by default” as a legal obligation. Specifically, an ERP vendor must:
- Integrate cybersecurity from the product design phase
- Deliver the product in a secure default configuration (no default passwords, encryption enabled, unnecessary ports closed)
- Conduct documented cybersecurity risk assessment
- Exercise reasonable due diligence on integrated third-party components
For CIOs, this is a powerful contractual lever: a vendor who delivers an ERP with lax security settings by default will be in violation.
Security Updates Throughout Product Lifetime
The vendor must guarantee security updates throughout the entire “support duration” they declare for their product. This duration must be clearly communicated before purchase. Security updates must be free and separate from functional updates.
This is a major change for vendors who condition security fixes on a paid maintenance contract or who cease support for “end-of-life” versions without sufficient notice.
24-Hour Vulnerability Reporting
From September 2026, manufacturers must report actively exploited vulnerabilities via ENISA’s unified platform, following a three-step protocol (source):
- Early warning within 24 hours: initial notification to national CSIRT and ENISA
- Complete notification within 72 hours: vulnerability details, impact scope, measures taken
- Final report within 14 days (vulnerabilities) or 1 month (severe incidents): complete analysis and deployed fixes
This reporting timeline is binding. An ERP vendor who discovers on Monday morning that a vulnerability in their accounting module is being exploited must have notified ENISA before Tuesday morning.
Technical Documentation and Software CE Marking
The CRA extends CE marking, historically reserved for physical products, to software. An ERP marketed in the EU after December 2027 must bear CE marking attesting to its compliance with cybersecurity requirements.
The conformity assessment procedure depends on the product category:
| Category | Procedure | ERP Examples |
|---|---|---|
| Standard product | Self-assessment (Module A) | Small business ERP without critical network component |
| Important Class I | Self-assessment if harmonized standards applied | Standard market ERP |
| Important Class II | Third-party assessment | ERP handling sensitive or critical data |
| Critical | Mandatory third-party assessment | ERP for critical infrastructures |
Technical documentation must include an SBOM (Software Bill of Materials), a machine-readable inventory of all software components, at minimum first-level dependencies, in a standardized format like CycloneDX or SPDX (source: FOSSA). This SBOM is not made public but must be available to market surveillance authorities.
Open Source: Commercial Vendors Are Fully Covered
The CRA distinguishes two scenarios for open source software:
- Non-commercial open source (voluntary community project, no monetization): excluded from CRA scope
- Commercially distributed open source: fully subject to CRA obligations
A vendor like Odoo (which sells support, hosting and proprietary modules around an open source core) is a manufacturer under the CRA, with all associated obligations. The same applies to any company distributing ERPNext as part of a commercial offering.
The CRA also creates the concept of “open source software steward”: an entity that systematically supports the development of open source software intended for commercial use, without distributing it themselves. Stewards have reduced obligations (cybersecurity policy, vulnerability reporting) and are not subject to administrative fines (source: European Commission).
Concrete Impact for CIOs Buying an ERP
New Clauses to Require in Vendor Contracts
The CRA gives you a regulatory foundation to require from your ERP vendor commitments that previously relied on commercial negotiation:
Non-negotiable post-CRA clauses:
- Guaranteed security support duration (with explicit end date)
- Maximum delay for security patch deployment (patch SLA)
- SBOM provision and notification when components are vulnerable
- CRA compliance commitment with EU declaration of conformity production
- Documented vulnerability management process
Recommended clause:
- Audit right on CRA technical documentation (or attestation by a trusted third party)
What to Verify in Post-CRA ERP Tenders
When launching an ERP tender after September 2026, integrate these evaluation criteria:
- CE marking: can the vendor provide (or commit to provide before December 2027) an EU declaration of conformity?
- SBOM: does the vendor maintain an up-to-date SBOM and can they share it?
- Patch policy: what is the SLA for critical vulnerability fixes? (CRA implicit standard: 24h reporting, so rapid correction expected)
- Support duration: what is the guaranteed security support duration after purchase?
- Reporting history: has the vendor already reported vulnerabilities transparently?
SaaS vs On-Premise ERP: Does the CRA Apply Differently?
This is an essential question, and the answer is nuanced:
- On-premise ERP (installed at customer site): clearly a “product with digital elements” under the CRA. Fully subject.
- Pure SaaS ERP (100% cloud, nothing installed locally): in principle excluded from CRA scope, as it’s a service, not a product. It falls under NIS2 instead.
- Hybrid ERP (SaaS with local components, agents, connectors): locally installed components fall under CRA. “Remote data processing” essential to product operation is also covered.
In practice, most market ERPs combine local and cloud components. An ERP like SAP S/4HANA (which has on-premise components even in cloud version) or self-hosted Odoo are within CRA scope. A 100% SaaS ERP like some Sage Business Cloud offerings would fall under NIS2 (DLA Piper analysis).
CRA, NIS2 and DORA: How These Three Regulations Interact
Summary Table: Who Targets What
| CRA | NIS2 | DORA | |
|---|---|---|---|
| Target | Digital products (supply) | Service operators (demand) | Financial sector |
| Who is responsible | Manufacturers, importers, distributors | Essential and important entities | Financial entities and their ICT providers |
| Type of obligation | Product security, CE marking, SBOM | Risk management, incident reporting | Operational resilience, penetration testing |
| Max sanctions | €15M or 2.5% global turnover | €10M or 2% turnover | According to national financial regulation |
| Effective from | Sept 2026 (reporting), Dec 2027 (full) | October 2024 (transposition) | January 2025 |
Regulatory Overlap Risk for Enterprises
A financial sector enterprise using an on-premise ERP is potentially subject to all three regulations simultaneously:
- As a user: NIS2 (if essential/important entity) and DORA (if financial sector)
- Their ERP vendor: CRA (as manufacturer)
The CRA reduces the burden on the user side by transferring product security responsibility to the vendor. But it creates new verification work: ensuring the vendor is CRA-compliant, documenting this verification in their own NIS2/DORA approach.
Sanctions match the ambitions: up to €15 million or 2.5% of global turnover for violations of essential cybersecurity requirements, €10 million or 2% for documentary failures, and €5 million or 1% for misleading information (CRA Article 64). Beyond fines, authorities can order market withdrawal of a non-compliant product.
CIO Checklist: Preparing for CRA in 5 Actions
The CRA enters application progressively. Here are priority actions for an enterprise CIO:
1. Audit Your ERP’s Software Components (SBOM)
Request your vendor’s SBOM or, failing that, the list of third-party components integrated in your ERP. Identify open source components and verify their maintenance status. This is a revealing exercise: many vendors will discover obsolete dependencies when creating this inventory.
2. Require CRA Compliance in Contract Renewals
At each vendor contract renewal, add a CRA compliance clause with a timeline aligned with regulatory deadlines (reporting from September 2026, full compliance December 2027). If the vendor cannot commit, document it in your risk register.
3. Verify Your Vendor’s Patch Policy
What is the average delay for critical vulnerability correction with your vendor? If the answer is “it depends” or “in the next major version,” you have a CRA compliance problem approaching. The regulation requires fixes throughout the support duration, free and separate from functional updates.
4. Train Security Team on CRA Reporting
The CRA reporting protocol (24h, 72h, 14 days) applies to manufacturers, but as a user, you need to know what to expect from your vendor and how to react when they notify you of a vulnerability. Integrate this scenario into your crisis management exercises.
5. Anticipate CE Marking on Future Acquisitions
From December 2027, any new ERP placed on the European market must bear CE marking. Integrate this criterion into your evaluation grids now, not as an elimination filter (the date hasn’t passed yet), but as a maturity indicator: a vendor already preparing their CE marking is a vendor taking cybersecurity seriously.
To deepen your understanding of the European cybersecurity regulatory framework, read our NIS2 and ERP guide for enterprises, our DORA analysis for the financial sector and our complete ERP cybersecurity guide.
