Securing AI in critical infrastructure: where the AI Act, Cyber Resilience Act and NIS2 meet

Short answer: The moment you deploy AI in a port, a terminal or a transport chain, you usually trigger three regulatory frameworks at once. The AI Act requires the AI system itself to withstand errors and attacks (Article 15). The Cyber Resilience Act sets cybersecurity requirements for the product with digital elements that contains the AI. And NIS2 obliges the operator — as an essential entity in the transport sector — to take organisation-wide risk measures and report incidents. Three layers around one system — product, AI function and organisation (and, for physical machinery, a fourth: the machine itself). Confuse the layers and you cover gaps that aren't there while missing the ones that are.

Three frameworks, three different questions

The frameworks overlap, but they don't ask the same question. It helps to see them as three layers around the same system:

• The Cyber Resilience Act — the product layer. Question: is this product with digital elements securely designed, supplied and maintained? It targets the manufacturer and applies horizontally to almost all hardware and software with a digital element.
• The AI Act, Article 15 — the AI layer. Question: is the AI function itself accurate, robust and resistant to AI-specific attacks? It targets the provider of the high-risk AI system.
• NIS2 — the organisation layer. Question: does the operator of the essential service manage its cyber risk and report incidents? It targets the deploying organisation — the port, the terminal operator, the carrier.

The skill is not to choose, but to see which layer places which obligation on which party.

The AI layer: Article 15 of the AI Act

Article 15 requires providers to build high-risk AI so that it achieves an appropriate level of accuracy, robustness and cybersecurity across its lifecycle. Beyond classic security, the framework explicitly names AI-specific threats: data poisoning (manipulating training data), model poisoning (sabotaging pre-trained components), adversarial examples (input designed to deliberately mislead the model) and confidentiality attacks (extracting the model or data).

That distinction matters: a camera model classifying containers may be technically "secure" as a product and still be foolable with prepared stickers or lighting. That is not a classic IT vulnerability — it is an attack on the model's logic. Only Article 15 explicitly covers it.

Mind the timing: the high-risk obligations (including Article 15) have shifted under the Digital Omnibus agreement from 2 August 2026 to 2 December 2027; until publication in the Official Journal the original date formally still stands. See the timeline of obligations for the current state.

The product layer: the Cyber Resilience Act

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) sets horizontal security requirements for products with digital elements: secure-by-design, no known exploitable vulnerabilities at delivery, security updates throughout the support period, and reporting of actively exploited vulnerabilities. The reporting duties start earlier (from 11 September 2026) than the broader manufacturer obligations (from 11 December 2027).

Crucial for AI: the AI Act states that high-risk AI which also falls under the CRA and complies with it is presumed to meet the cybersecurity requirement of Article 15 — to the extent those requirements coincide. So you avoid duplicate work, but both the supplier requirements and the AI-specific threat analysis must be demonstrably covered; the CRA does not fully replace the AI layer.

The organisation layer: NIS2

NIS2 (Directive (EU) 2022/2555, transposed in the Netherlands via the Cybersecurity Act) targets not the product but the organisation. Operators in the transport sector — air, rail, water and road, including port authorities and terminal operators — generally qualify as essential or important entities. They must take appropriate risk-management measures, manage their supply chain, report incidents and assign accountability at board level.

So for a port deploying an AI system, the AI is part of the broader risk picture NIS2 already requires. A failing or manipulated AI system that disrupts container handling or access control is, in NIS2 terms, a potentially reportable incident. The overlap with DORA matters for anyone also touching financial chains.

The physical layer: the Machinery Regulation

When the AI sits inside physical equipment — an automated crane, an AGV or a warehouse robot — a fourth framework applies: the Machinery Regulation (Regulation (EU) 2023/1230). It sets safety requirements for machinery and explicitly addresses AI-driven safety functions. For heavy equipment in a terminal this is not an edge case but the core: see AI in a warehouse robot under the Machinery Regulation, where product safety and AI conformity converge on a single machine. Note: high-risk AI embedded in such regulated products (Annex I) carries an even later AI Act date — under the Digital Omnibus agreement, 2 August 2028 — yet another clock than the standalone Annex III systems.

Where they meet: an AI system in the port

Suppose a terminal deploys an AI system for automated crane or stack planning, fed by cameras and sensors. Then the following apply at once:

1. CRA on the product (the software/hardware with digital elements) — the supplier must design and maintain it securely.
2. AI Act Art. 15 on the AI function — the provider must show the model is robust and resistant to poisoning/adversarial input, provided the system is high-risk.
3. NIS2 on the terminal operator — who must fold the system into its risk management, supplier agreements and incident response.

Three parties, three kinds of evidence, one chain. The mistake organisations make is assuming that "our supplier is ISO-certified" covers all three layers. It does not: product-level certification says little about the adversarial robustness of the model, and nothing about the operator's own NIS2 duties.

Who is responsible for what

• The manufacturer/supplier carries the CRA product obligations and, as provider of the high-risk AI system, Article 15.
• The deployer (the port, carrier, terminal) carries the NIS2 organisation obligations and the AI Act deployer duties (human oversight, use according to instructions, monitoring).
• Pin this down contractually: ask suppliers for evidence of CRA conformity and of AI-specific robustness testing, and arrange access to logging and vulnerability notifications. See also the role of the CISO under the AI Act.

What to do

• Map, per AI system, which layers apply — product (CRA), AI function (Art. 15), organisation (NIS2) — and who carries each.
• Require AI-specific threat analysis on top of standard security: poisoning, adversarial input, model evasion and extraction of model/data.
• Lean on the CRA presumption where it applies, but cover the AI layer in addition; they overlap but do not fully cover one another.
• Fold AI into your NIS2 risk management — a manipulated AI system in a critical chain can become a reportable incident.
• Pin it down contractually: evidence of conformity, access to logging, update agreements and supply-chain vulnerability reporting.
• Track the dates: CRA reporting duties (Sep 2026) and broader CRA obligations (Dec 2027) do not run in step with the shifted AI Act high-risk date (Dec 2027).

For the broader context, see AI regulation in transport and logistics, predictive maintenance in transport and the maritime single window (EMSWE). Secure AI in critical infrastructure is not a matter of one certificate — it is three layers you must be able to prove separately.