The EU Cyber Resilience Act, formally Regulation (EU) 2024/2847, is the first Union-wide law that makes cybersecurity a legal precondition for placing any product with digital elements on the EU market. For compliance officers, CISOs and IT decision-makers in government, finance, healthcare and legal services, this is not a distant vendor problem: it reshapes procurement criteria, changes what audit evidence looks like, and directly affects every sovereign infrastructure decision made from 2026 onward.
CRA Obligations Versus NIS-2: Understanding the Boundary
The CRA governs products; NIS-2 governs operators of essential and important services. The two instruments are complementary but address different duty-bearers.
Under the CRA, manufacturers of products with digital elements must embed cybersecurity across the entire product lifecycle, from initial design through end-of-life decommissioning. Concretely, this means: no known exploitable vulnerabilities at market placement, a secure default configuration, the ability to receive security updates, and documented disclosure of the software components inside the product via a Software Bill of Materials (SBOM). These are supply-side obligations that attach to whoever puts a product into circulation.
NIS-2 (Directive (EU) 2022/2555), by contrast, imposes demand-side obligations on the regulated entity itself, covering risk management under Article 21, incident reporting, business continuity and supply-chain security. The practical intersection is Article 21(2)(d), which requires NIS-2 entities to vet the cybersecurity of their suppliers. CRA conformity documentation, including the declaration of conformity and the technical file, becomes the primary evidence base for that vetting. An organisation running sovereign infrastructure that has been CRA-assessed is therefore simultaneously advancing its NIS-2 supply-chain due diligence.
Product Classification: Annex III, Annex IV and Mandatory Third-Party Assessment
The CRA divides products into three tiers. Default-class products may self-certify against harmonised standards. “Important” products listed in CRA Annex III are split into two classes: Class I products may self-assess if recognised standards are followed, whereas Class II products require third-party assessment by an accredited notified body. “Critical” products listed in Annex IV, which covers hardware security modules, smart-card readers and industrial control system components, face the most stringent route, including mandatory notified body involvement or a European cybersecurity certification scheme where one exists.
Implementing Regulation (EU) 2025/2392 specifies the concrete product categories that fall into each tier. For sovereign infrastructure buyers, the most practically relevant Annex III categories include network management software, identity and access management solutions, remote access tools, endpoint protection software and operating systems for general use. Any commercial sovereign workspace product that incorporates these functions must be evaluated against its correct classification before procurement.
Vulnerability Reporting Timelines and the ENISA Single Reporting Platform
The CRA introduces three sequential reporting obligations that manufacturers and, in certain delegation scenarios, their authorised representatives must fulfil toward ENISA’s Single Reporting Platform (SRP).
| Deadline | Trigger | Required content | Recipient |
|---|---|---|---|
| 24 hours (early warning) | Awareness of actively exploited vulnerability | Nature of vulnerability, affected product, initial impact estimate | ENISA SRP, relevant national CSIRT |
| 72 hours (full notification) | Same trigger | Detailed technical description, remediation status, affected user base estimate | ENISA SRP, national CSIRT |
| 14 days (final report) | Completion of remediation | Root-cause analysis, full mitigation measures, updated SBOM if components changed | ENISA SRP |
These timelines apply from 11 September 2026, ahead of the full CRA product compliance date of 11 December 2027. Sovereign operators who run their own infrastructure should verify whether their providers have pre-configured SRP submission workflows, because a missed 24-hour window in an actively exploited scenario carries both regulatory and reputational consequences.
SBOM Requirements: What the CRA Actually Mandates
The CRA requires manufacturers to produce and maintain an SBOM covering at a minimum: a unique identifier for each top-level component and its dependencies, the component version, the cryptographic hash of each component, the applicable license, the name of the tool used to generate the SBOM, and the dependency relationships between components. This specification aligns closely with the established machine-readable standards CycloneDX and SPDX, both of which can express all mandatory fields.
According to the ENISA SBOM Implementation Guide published in December 2025, organisations should prefer CycloneDX 1.5 or later for sovereign infrastructure contexts because its VEX (Vulnerability Exploitability eXchange) component allows manufacturers to assert exploitability status for each vulnerability against each product configuration, directly supporting the CRA’s continuous vulnerability management obligation.
For NIS-2 purposes, the SBOM doubles as the primary artefact for supply-chain vetting under Article 21. A regulated entity that receives an SBOM from its sovereign infrastructure provider can cross-reference each listed component against vulnerability databases such as the EU’s own vulnerability database (EUVDB, maintained by ENISA) and commercial threat intelligence feeds. This transforms SBOM data from a static compliance document into a live risk management tool.
Open-Source Software: The CRA’s Nuanced Position
Many sovereign infrastructure stacks rely on open-source components, including Nextcloud for collaborative workspaces and Mistral or Llama models for private AI. The CRA contains an explicit carve-out: software developed and supplied in a non-commercial open-source context is not subject to CRA manufacturer obligations. The policy rationale is to avoid deterring community-maintained projects that underpin critical infrastructure without being commercial products themselves.
The boundary activates when a commercial entity integrates an open-source component into a product it places on the market. At that point, the integrating company becomes the CRA manufacturer and inherits all obligations, including the SBOM requirement for every included open-source dependency. For regulated buyers, this means the relevant question is not “is Nextcloud open-source?” but rather “has the sovereign infrastructure provider that delivers our Nextcloud-based workspace carried out a CRA conformity assessment for their integrated product?” Providers who have not yet done so represent a compliance gap that procurement contracts should now address explicitly.
EUCC Certification and the Cross-Regulatory Evidence Stack
The EU Cybersecurity Certification scheme on Common Criteria (EUCC), established under the EU Cybersecurity Act and administered by ENISA, provides assurance levels that can satisfy or complement CRA notified body requirements where implementing acts designate equivalence. EUCC certificates are issued by accredited conformity assessment bodies and are recognised across all EU member states.
For regulated buyers, EUCC certification creates a single, authoritative evidence artefact that can be referenced across multiple regulatory frameworks simultaneously:
- GDPR Article 25 (data protection by design and by default): EUCC assurance at the appropriate level demonstrates that the technical measures required by Article 25 were independently verified.
- NIS-2 Article 21 (risk management): A certified product satisfies the supply-chain due diligence requirement without requiring the buyer to conduct its own technical assessment.
- DORA ICT risk management: EUCC certificates provide the independent assurance evidence that DORA’s ICT third-party oversight requirements expect for critical service providers.
According to ENISA, “The Cyber Resilience Act is a paradigm shift: for the first time, cybersecurity becomes a legal prerequisite for placing a product on the EU market, not an optional feature.” This framing signals that buyers who continue to accept undocumented conformity claims from vendors, whether hyperscalers or sovereign alternatives, will face increasing difficulty demonstrating audit readiness.
The IBM Cost of a Data Breach Report 2024 recorded the global average breach cost at USD 4.88 million, the highest in the report’s history, underlining the financial stakes of inadequate cybersecurity assurance across the supply chain. ENISA’s Threat Landscape 2023 identified vulnerability exploitation as one of the top three attack vectors across NIS-2 sectors, precisely the attack surface that CRA SBOM and patch management obligations are designed to close. Full CRA vulnerability reporting obligations take effect on 11 September 2026, with complete product compliance required by 11 December 2027.
Building an Audit-Ready CRA Compliance Package
For a compliance officer or CISO assembling evidence for a joint GDPR, NIS-2 and DORA audit, the practical CRA evidence package should include: the manufacturer’s declaration of conformity, the technical file summary (where the full technical file is not public), the machine-readable SBOM in CycloneDX or SPDX format, the EUCC certificate where applicable, and the provider’s documented vulnerability disclosure and patch notification process referencing the SRP timelines. Each of these documents maps directly to an audit question in at least one of the three frameworks.
Sovereign infrastructure providers operating under Swiss or EU jurisdiction, without exposure to US-law extraterritorial access mechanisms such as the CLOUD Act or FISA 702, can add a fourth layer: a jurisdiction attestation demonstrating that no data stored or processed by the platform is legally accessible to foreign government demands. Combined with CRA conformity documentation, this creates a defensible, multi-layer compliance record that standalone Big Tech procurement cannot replicate, because hyperscale platforms remain subject to US jurisdiction regardless of where their EU data centres are physically located.
FAQ
Does the CRA apply to internal sovereign infrastructure operated by a public-sector organisation, or only to commercial software vendors?
The CRA primarily targets manufacturers who place products with digital elements on the EU market. Public-sector organisations that develop software exclusively for their own internal use are generally outside the manufacturer definition. However, if a public body procures or deploys a product, it must ensure that product carries CRA-compliant conformity documentation before using it in regulated environments, making the CRA relevant for procurement decisions even where the organisation is not itself a manufacturer.
What is the difference between the 24-hour early warning, the 72-hour notification and the 14-day final report under the CRA?
The 24-hour early warning is a rapid alert submitted to ENISA’s Single Reporting Platform as soon as a manufacturer becomes aware of an actively exploited vulnerability, enabling coordinated threat response. The 72-hour notification must contain more detail on the nature, scope and initial remediation steps. The 14-day final report closes the loop with a full technical description, root-cause analysis and completed mitigation measures. Sovereign operators should pre-configure reporting workflows so that all three deadlines are met without manual escalation delays.
Is Nextcloud or Mistral subject to CRA obligations as open-source software?
The CRA exempts software developed and supplied in a non-commercial context, which covers most community-maintained open-source projects. However, when a commercial entity integrates Nextcloud or Mistral into a product or service it places on the market, that entity becomes the manufacturer for CRA purposes and bears the conformity obligations. Regulated buyers should therefore verify that their sovereign infrastructure provider has carried out the required conformity assessment and can supply the relevant documentation and SBOM.
How does CRA conformity documentation help satisfy GDPR, NIS-2 and DORA simultaneously?
CRA conformity documentation, especially the technical file, declaration of conformity and SBOM, provides auditors with evidence that cybersecurity by design and by default principles were applied. This directly supports GDPR Article 25, NIS-2 Article 21 risk management and DORA ICT risk management requirements. Rather than producing separate evidence sets for each regulator, a regulated buyer can reference the same CRA documentation package as a cross-regulatory compliance artefact, reducing audit preparation time significantly.
When is a notified body conformity assessment mandatory under the CRA, and can EUCC certification substitute for it?
Third-party assessment by an accredited notified body is mandatory for Class II important products listed in CRA Annex III and for the highly critical products in Annex IV. For Class I important products, self-assessment against harmonised standards is permitted. EUCC certification under the EU Cybersecurity Certification scheme on Common Criteria can, where the relevant implementing act specifies equivalence, substitute for or complement notified body assessment, creating a single certification artefact that satisfies both CRA and ENISA scheme requirements.