CRA × NIS2 × DORA × AI Act: the convergence

Four legal acts, four objects — no two wordings are alike

Hardly any technology-driven company today is subject to just one EU cyber regulation. In practice, the Cyber Resilience Act (CRA), NIS2, DORA and the AI Act often apply to the same organisation at once — but they govern different things. The most common mistake is to lump them together. These are four separate legal acts with four distinct anchoring points: the CRA regulates the product, NIS2 the organisation as an operator, DORA the resilience of the financial sector, and the AI Act the AI system. Keeping these four objects cleanly apart is also the key to understanding why the obligations overlap without replacing one another.

The CRA (Regulation (EU) 2024/2847) entered into force on 10 Dec 2024. For manufacturers it bites in two stages: the product-level reporting obligation (Art. 14) applies from 11 Sep 2026, and full application of all product requirements from 11 Dec 2027. These dates set the tempo around which a coordinated implementation can be built.

Who is subject to what — the multi-regulation map

The overview below maps the four legal acts schematically. It does not replace a case-by-case assessment and is not legal advice — actual applicability depends on your product, business model and market role.

Note: NIS2 is a directive, taking effect through national law (in Germany the NIS2 implementation act) — whereas the CRA, DORA and AI Act are directly applicable regulations. That, too, is a reason not to treat them as equivalent.

Where the regimes overlap — and where they don't

The efficiency gains sit precisely in the intersections. They almost always concern the same three building blocks: risk assessment, supply chain/SBOM, and incident/vulnerability reporting.

• CRA ↔ NIS2: A CRA manufacturer is frequently also a NIS2 entity. Conversely, NIS2 supply-chain duties turn the CRA conformity of purchased products into a procurement criterion — CE-marked conformity becomes a sales argument.
• CRA ↔ DORA: ICT products used by a financial entity are subject, as products, to the CRA, while DORA governs their use and third-party risk inside the institution. A CRA-compliant product with a clean SBOM and a documented support period eases the buyer's DORA evidence work.
• CRA ↔ AI Act: An AI product may be subject to both — the AI Act for AI risk, the CRA for product cybersecurity. Both require a documented risk assessment; the methods (threat modelling, risk classification) can be set up jointly.

The strongest operational overlap is reporting. CRA, NIS2 and DORA each demand early warning, interim and final reports to authorities — with different deadlines and addressees, but comparable process steps. Build the process once and you can parameterise it across regimes.

The CRA reporting cascade — the anchor for a shared process

Because the CRA reporting duty bites first (11 Sep 2026), it makes sense to anchor the incident process to it. For actively exploited vulnerabilities and severe incidents, the CRA (Art. 14) requires staged reporting via the ENISA Single Reporting Platform (SRP) to the competent CSIRT and ENISA:

A common error is to set the final report at a flat "14 days". The correct distinction is: 14 days for the vulnerability, one month for the incident. The SRP is to be available by 11 Sep 2026; until then, internal workflows must be set up so the 24-/72-hour clock can be met.

A worked example: an SME with an AI-assisted network sensor

Consider a fictitious manufacturer selling an IDS-like product with AI anomaly detection, who also operates as a mid-sized IT service provider. Schematically, the picture might look like this:

• CRA: Depending on classification, the product might fall into the "important" category (Annex III, e.g. IDS/IPS as Class II) — the technical description of these categories follows Implementing Regulation (EU) 2025/2392. Class II would regularly involve a notified body. It would require an SBOM (machine-readable, CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 per BSI TR-03183-2), a documented risk assessment, vulnerability handling across the support period (guideline: at least 5 years), and technical documentation per Annex VII — retained for 10 years.
• AI Act: The AI component would need risk-class classification; the required risk assessment could be set up jointly, methodologically, with the CRA risk assessment.
• NIS2: As an IT service provider, the company itself might be an important entity — with risk management, supply-chain duties and an organisation-wide incident process that reuses the CRA product process.

The lever: SBOM, risk assessment, CVD policy and incident process are built once, cleanly, and then serve large parts of all three applicable regimes. Separate silos per legal act are costly, redundant and error-prone.

Penalty framework — soberly framed

The CRA tiers penalties (Art. 64, whichever is higher): up to €15m / 2.5% of worldwide annual turnover for breaches of the essential requirements (Annex I, Art. 13/14); up to €10m / 2% for other duties; up to €5m / 1% for incorrect information to authorities or notified bodies. NIS2 and DORA each have their own penalty frameworks. These figures are a reason for structured preparation — not for panic.

What Blackfort does

Blackfort Technology UG (haftungsbeschränkt) helps manufacturers and operators treat the four regimes not as four projects but as one integrated evidence build. We structure the shared building blocks — risk assessment and threat modelling, SBOM generation, CVD and incident processes aligned with the CRA reporting cascade — so they are reusable across the CRA, NIS2, DORA and the AI Act. Results and recommendations are schematic and do not constitute legal advice; binding legal classification remains subject to your own review or your legal advisers.

A good first step is our applicability check: it schematically indicates which of the four regimes might apply to your product and organisation. Small and mid-sized companies find a pragmatic entry point in our SME section, and sector-specific perspectives in the industry overview. If you want to work through the convergence concretely for your organisation, get in touch: contact us.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
• Directive (EU) 2022/2555 (NIS2), EUR-Lex
• Regulation (EU) 2022/2554 (DORA), EUR-Lex
• Regulation (EU) 2024/1689 (AI Act), EUR-Lex
• Implementing Regulation (EU) 2025/2392; ENISA Single Reporting Platform; BSI TR-03183-2