CRA × NIS2 × DORA × AI Act: the convergence

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

A technology-driven company can be subject to several EU cyber regulations at once. The Cyber Resilience Act (CRA), NIS2, DORA and the AI Act can apply to the same organisation at once - but they govern different things. It is a mistake 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) has applied since 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 mainly concern three building blocks: risk assessment, supply chain/SBOM, and incident/vulnerability reporting.

• CRA ↔ NIS2: A CRA manufacturer can also be 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. Where the AI system is high-risk, both require a documented risk assessment or risk management; the methods (threat modelling, risk classification) can be set up jointly.

The strongest operational overlap is reporting. CRA, NIS2 and DORA each provide for staged notifications 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 reporting obligation is the first CRA manufacturer duty already in force (since 11 Sep 2026), it makes sense to anchor the incident process to it. For actively exploited vulnerabilities and for severe incidents having an impact on the security of the product, the CRA (Art. 14) requires staged reporting via the single reporting platform (SRP), simultaneously to the CSIRT designated as coordinator and to ENISA:

It is wrong to set the final report at a flat "14 days". The correct distinction is: 14 days for the vulnerability, one month for the incident. At the request of the CSIRT, an intermediate report may also be due (Art. 14(6)). ENISA sets up the SRP under Art. 16 CRA; 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. For class II, internal control (Module A) would be excluded; the options would be Module B+C, Module H or, where available and applicable, a European cybersecurity certification scheme at least at assurance level 'substantial' (Article 32(3)). It would require an SBOM (commonly used machine-readable format, covering at least the top-level dependencies; BSI TR-03183-2 specifies CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1), a documented risk assessment, vulnerability handling across the support period (at least five years, shorter only where the expected use time is shorter, Article 13(8)), and technical documentation per Annex VII, kept for at least ten years after placing on the market or for the support period, whichever is longer.
• AI Act: The AI component would need risk-class classification. If it were a high-risk system, the risk management required there could be set up methodologically together 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 can then serve as a basis in all three applicable regimes. Separate silos per legal act lead to duplicate work.

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. Article 64 is not among the provisions that apply early and applies from 11 December 2027 (Article 71(2)); the German implementing act (Bundestag printed paper 21/6134), which is to set the authority and fining procedure, had been neither adopted nor promulgated as of 9 October 2026. The figures argue for structured preparation.

What Blackfort does

Blackfort Technology UG (haftungsbeschränkt) supports manufacturers with the CRA building blocks that can also be used under other frameworks: a risk assessment per product, an SBOM chain, a coordinated vulnerability disclosure policy and an Article 14 reporting process. Whether NIS2, DORA or the AI Act apply to your company is for your legal department or counsel.

A good first step is our applicability check: it schematically indicates whether and how the CRA covers your product. 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 build the CRA evidence so your team can reuse it under other frameworks, get in touch: contact us.