EU AI Act and Quantum Security: What Critical Infrastructure Operators Must Address Before August 2026

The EU AI Act's phased enforcement schedule reaches its next threshold in August 2026. From that date, high-risk AI systems, including AI systems used to manage critical infrastructure, must comply with the Act's conformity assessment and documentation obligations. This article addresses one dimension of that compliance that most AI Act guidance does not discuss: the intersection with quantum security.

Before the jurisdictional note: this article applies to operators and providers of AI systems subject to EU law, EU-based operators, and organisations placing AI systems on the EU market or operating infrastructure within the EU. UK-only organisations are not subject to the EU AI Act. A dedicated section at the end of this article addresses what that means in practice for UK readers.

The August 2026 Deadline: What Is Actually Happening

The EU AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024. Its enforcement is phased. 2 February 2025 brought the prohibition of AI practices listed in Article 5, uses of AI that the Act bans outright, including certain biometric categorisation applications and social scoring systems. August 2026 is the next enforcement threshold: from that date, providers and operators of high-risk AI systems face conformity assessment obligations, documentation requirements, and the penalty framework.

High-risk AI systems are defined by Annex III of the Act. The list is specific. For critical infrastructure operators, the relevant category is Annex III, paragraph 2: AI systems intended to be used as safety components in the management of critical infrastructure in energy, water, transport, and digital infrastructure sectors. An AI system used for grid management, network anomaly detection on operational technology, or automated control of water or transport systems falls squarely in this category. AI-based tools used to monitor, predict, or manage operational variables across critical national infrastructure are not edge cases under Annex III, they are the category's core intended scope.

Non-compliance with high-risk AI system obligations carries penalties of up to €15 million or 3% of total worldwide annual turnover, whichever is higher. The penalty applies to non-compliance with the high-risk system requirements in Chapter III. Operators that have not assessed their AI systems against the Annex III classification by August 2026 are operating without the knowledge of their own compliance position, a position that will not withstand regulatory scrutiny.

Where Quantum Security Intersects with the AI Act

Article 15 of the EU AI Act requires high-risk AI systems to achieve an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle. The Act does not specify cryptographic algorithms. It uses the phrase "state of the art" as the benchmark for technical robustness, a deliberately technology-neutral formulation. That phrase is consequential: it is the same standard used in GDPR Article 32 for data protection security measures and NIS2 Article 21 for network and information system security. Regulators and courts interpreting "state of the art" look to published technical standards as the benchmark for what that phrase requires at any given point in time. NIST FIPS 203, 204, 205, and 206, published in August and October 2024, are now part of the published cryptographic state of the art.

Article 15(5) specifies that high-risk AI systems must, to the extent possible, be resilient against attempts by unauthorised third parties to alter their use, outputs, or performance by exploiting system vulnerabilities. This encompasses the security of AI model serving infrastructure, inference APIs, training pipelines, and the cryptographic protection of AI-related data flows.

The connection to quantum security follows. An AI system at a critical infrastructure operator that is still protected by quantum-vulnerable cryptography, RSA or ECDH key exchange on data pipelines, ECDSA JWT tokens on inference APIs, RSA-encrypted model weights at rest, has a demonstrable gap between its current cryptographic posture and the emerging "state of the art" standard. The EU Cybersecurity Act (Regulation (EU) 2019/881) and ENISA's technical guidance increasingly reference NIST PQC standards as the baseline for cryptographic resilience. Regulators interpreting Article 15 post-2024 will have those standards available to them as a benchmark.

The relationship to quantum security is interpretive, not explicit. The Act does not say "implement ML-KEM." The correct framing is: Article 15's state-of-the-art robustness standard will be interpreted in light of the cryptographic standards that exist. ETSI TS 119 312 on quantum-safe electronic signatures, and ENISA's guidance on PQC as part of the cybersecurity baseline, provide the standards context regulators will apply. For the algorithm transition timeline that underpins this, the NIST IR 8547 transition timeline covers the deprecation schedule in full.

The AI System Cryptographic Attack Surface

An AI system deployed at a critical infrastructure operator presents multiple cryptographic surfaces, each of which is potentially quantum-vulnerable. Working through them systematically is the starting point for any Article 15 compliance assessment:

Data pipelines. Training data sourced from HTTPS APIs, model weights transferred over TLS between training infrastructure and serving infrastructure, and inference results transmitted to operational systems are all typically protected by TLS with RSA or ECDSA certificates and ECDH key exchange. Quantum-vulnerable across all three flows.

Model storage. Model weights encrypted at rest under AES typically use an RSA-wrapped or ECDH-derived key management scheme. The AES-encrypted data is not directly quantum-vulnerable, but the key wrapping is.

API authentication. JWT tokens authenticating inference requests commonly use RSA or ECDSA signatures. An adversary running Shor's algorithm on a cryptographically relevant quantum computer (CRQC) could forge API authentication tokens.

Audit logs. Signed with ECDSA or RSA to ensure tamper evidence. The signature algorithm is the exposure point.

MLOps pipeline integrity. Code signing for model packages and pipeline scripts using ECDSA or RSA certificates.

The Harvest Now, Decrypt Later (HNDL) risk for AI systems is asymmetric and worth stating plainly. An adversary who captures encrypted model weights or proprietary training data today could potentially decrypt them after a CRQC exists. The central estimate for when a CRQC might emerge is 2033 to 2035. For critical infrastructure operators whose AI systems process operational data with multi-year retention periods or embody intellectual property with long commercial lifetimes, the confidentiality exposure begins accumulating now. The Mosca inequality framework, which quantifies the relationship between data sensitivity lifetime, migration time, and CRQC probability, provides the risk quantification tool. A system trained on ten years of sensitive operational data has a confidentiality window that extends well into the period when HNDL attacks become executable.

DORA and NIS2: The Overlapping Compliance Landscape

Many EU critical infrastructure operators are subject to multiple regulatory frameworks simultaneously. The EU AI Act is not the only instrument that creates quantum security compliance obligations, and understanding the overlap is part of compliance planning.

NIS2 (Directive 2022/2555) applies to operators of essential services across energy, transport, water, digital infrastructure, health, financial markets, and other critical sectors. Article 21 requires these operators to implement "state-of-the-art" cybersecurity measures, including encryption. The same "state of the art" standard applies. A critical infrastructure operator that is subject to both the EU AI Act and NIS2 faces consistent cryptographic expectations from both frameworks, and the convergence makes the PQC migration argument more robust, not more complex.

DORA (Regulation (EU) 2022/2554, Digital Operational Resilience Act) applies to EU financial entities and their ICT service providers. DORA's Article 4 and Annex I on ICT risk management and cryptographic controls use equivalent language for cryptographic resilience. The detailed analysis of what DORA requires of financial sector operators on PQC migration is covered at DORA and post-quantum cryptography.

One note on DORA jurisdiction that matters here: DORA binds EU financial entities and their ICT service providers. A UK-only financial organisation is not subject to DORA. UK financial services firms should refer to FCA PS21/3 on building operational resilience and the PRA's cryptographic controls guidance.

For critical infrastructure operators at the intersection of all three frameworks, an EU energy utility with financial services subsidiaries operating AI systems across both, the compliance landscape requires a single coherent cryptographic programme rather than three parallel ones. The cryptographic state-of-the-art standard runs through all three.

Article Obligations: What the Act Actually Requires

Translating the Act's articles into specific quantum security actions requires working through four provisions.

Article 9, Risk management system. Providers of high-risk AI systems must establish and maintain a documented risk management system throughout the AI system's lifecycle. From a quantum security standpoint, this system should include: identification of the cryptographic controls protecting the AI system; assessment of HNDL risk for AI-system data with long confidentiality lifetimes; and a roadmap for upgrading cryptographic controls to post-quantum standards aligned with the NIST FIPS 203/204/205/206 suite. The Article 9 documentation is the audit trail a regulator will examine. Absence of any engagement with quantum security risk in the risk management system will be a finding.

Article 15, Accuracy, robustness, and cybersecurity. The state-of-the-art cybersecurity standard. Documented engagement with the quantum security dimension of AI system cryptographic controls is the minimum defensible position. An operator that can show it has assessed its cryptographic surface, documented the gap against the emerging post-quantum standard, and produced a migration roadmap is in a materially different position from one that has not considered the issue.

Article 17, Technical documentation. Providers must prepare technical documentation before placing a high-risk AI system on the market, including a description of the cybersecurity measures implemented. Including the quantum security posture of the AI system's cryptographic controls in the Article 17 documentation is not explicitly required by the Act's text, but it is a defensible and prudent approach given the Article 15 robustness obligations. Specific format guidance from ENISA for Article 17 cybersecurity documentation had not been published as of the knowledge cutoff for this article; monitor ENISA publications before finalising the documentation approach.

Article 26, Deployer obligations. Organisations that deploy high-risk AI systems in a professional context must ensure the system is used in accordance with the provider's instructions and must monitor its operation for anomalies. Where anomaly detection systems are themselves AI-based and meet the Annex III critical infrastructure classification, the deployer's monitoring obligation extends to the security of the monitoring system, including its cryptographic security.

Four Steps Before August 2026

Step 1: Classify AI systems against Annex III. Conduct an audit of all AI systems deployed across critical infrastructure against the Annex III criteria. The classification question for each system: does this AI system manage or operate components of critical infrastructure in the Annex III sector categories? If yes, it is likely a high-risk AI system requiring compliance by August 2026. This audit needs to be completed before the enforcement date, not after.

Step 2: Conduct a cryptographic surface assessment for each Annex III classified system. Map the cryptographic controls across data-in-transit (TLS configuration, certificate key types), data-at-rest (storage encryption key management), API authentication (JWT key types and signature algorithms), audit log signing (algorithm and key size), and MLOps pipeline code signing. The NIST NCCoE SP 1800-38B CBOM methodology provides the framework for this work, scoped to the AI system's infrastructure.

Step 3: Include quantum security risk in the Article 9 risk management documentation. For systems handling long-lived sensitive data, operational telemetry with multi-year retention, proprietary model weights, AI training datasets built over years of operational history, document the HNDL risk explicitly and produce a roadmap for quantum-safe cryptographic controls. Operationally, this means documenting the gap between current RSA/ECDSA-based controls and the FIPS 203/204/205/206 post-quantum standard, and producing a phased transition plan.

Step 4: Update Article 17 technical documentation. Include the current quantum security posture of the AI system's cryptographic controls and the migration roadmap produced in Step 3. Given that ENISA had not published formal Article 17 cybersecurity documentation guidance as of the knowledge cutoff for this article, frame the quantum security section as a demonstration of Article 15 compliance engagement rather than a response to a specific documentation template.

The August 2026 deadline requires the risk management system and technical documentation to be in place, not the quantum migration to be complete. An operator that can demonstrate it has assessed the quantum risk, documented it appropriately, and produced a credible roadmap is compliant with the Articles 9 and 17 obligations even if the cryptographic migration is underway but not finished. The operator that has done nothing, no assessment, no documentation, no roadmap, is the one in genuine difficulty when supervisory authorities begin enforcement.

UK Organisations: This Does Not Apply to You Directly

The EU AI Act is a regulation of the European Union. The UK left the EU before the Act was adopted and is not subject to it through membership.

A UK-based operator with no EU market presence and no infrastructure within the EU has no EU AI Act obligation. Full stop. The Act's territorial scope (Article 2) covers providers placing AI systems on the EU market and operators using AI systems within the EU. A UK-only operation with no EU customers, no EU-located infrastructure, and no EU-market AI products falls outside that scope.

UK operators that do have EU market presence, UK companies selling AI systems to EU customers, UK cloud infrastructure providers serving EU operators, UK financial services firms with EU-regulated entities, should assess their EU footprint against Article 2 specifically, not against this article's general framing.

For UK-only organisations, the applicable frameworks are different. The UK Government's pro-innovation AI regulation approach operates through sector-specific regulators: FCA for financial services AI, ICO for data protection, Ofcom for digital communications, CMA for competition. The NCSC's AI cyber security principles guidance covers the cybersecurity dimension of AI systems for UK operators. On the quantum security side, the NCSC's PQC migration timeline guidance (March 2025) and the UK National Quantum Strategy provide the relevant planning framework. The quantum security case for UK operators is strong and the timeline is substantively aligned with the EU frameworks, but the regulatory basis is different, and conflating EU and UK obligations would be inaccurate.