CRA and AI Act Synergies: What Dual Coverage Means for Industrial AI

Industrial AI rarely ships as software alone. It ships inside a product: a controller, a gateway, a cloud platform wired into physical assets. That simple fact is why the EU Cyber Resilience Act (Regulation (EU) 2024/2847) and the EU AI Act (Regulation (EU) 2024/1689) both land on the same engineering organization. The two regulations were adopted within the same six month window in 2024 and were engineered by the co-legislators to interlock. For any team building AI-driven industrial systems, understanding how the two regimes overlap on one product, one threat model, and one documentation set is now a core design question.

This post walks through the dual-scope question using a concrete example: an energy management system (EMS) for renewable assets, with edge-side local control and central-side forecasting and optimization. The goal of this post is: to give product, engineering and compliance leaders a clear picture of where each regulation lands, what the joint conformity story looks like, and what shared technical foundations make sense.

CRA and AI Act Scope: When Both Regulations Apply to the Same Product

The CRA applies to products with digital elements, defined broadly in Article 3 as any software or hardware product, and any remote data processing solutions, whose intended purpose includes a direct or indirect logical or physical data connection to a device or network. In practice, almost every connected industrial system meets this definition, from a field controller to a cloud-hosted analytics service.

The AI Act defines an AI system in Article 3(1) as a machine-based system that, for explicit or implicit objectives, infers from inputs it receives how to generate outputs such as predictions, recommendations, or decisions that can influence physical or virtual environments. Most industrial ML applications, including time-series forecasting, anomaly detection, and optimization planning, fall inside this definition.

A product can therefore sit in CRA scope, AI Act scope, or both. For dual-scope systems, the key question is whether the AI component qualifies as high-risk under AI Act Article 6. High-risk classification is where the two regulations really start to interact. Systems that are only limited-risk AI carry lighter transparency duties, and the CRA does its job independently.

Example: A Renewable Energy Management System Under CRA and AI Act

Consider a distributed EMS for renewable assets. On each site there is a local EMS running on edge hardware. It performs short-term load balancing, dispatches setpoints to battery storage (stationary and EV), PV inverters, and wind assets, and enforces site-level safety constraints. It talks to the field devices over industrial protocols like Modbus or OPC-UA and to a central platform over MQTTS.

On the central side there is a platform that ingests telemetry from the fleet, runs ML-based forecasting models for generation and demand, and computes day-ahead and multi-day dispatch plans. Plans flow back to the local EMS, which executes them and adapts in real time. Human operators use a central dashboard to supervise, override, and review.

The value chain has several actors: the EMS vendor as manufacturer and provider, the asset owner or operator as deployer, and in many cases a grid operator or aggregator as a downstream party. The engineering problem is that parts of this system are clearly in CRA scope, parts are clearly in AI Act scope, and in the dispatch loop, the two regulations reinforce each other.

Mapping CRA and AI Act Across the EMS Architecture

Two questions matter here, and they are often conflated. The first is general applicability: which regulation applies to which component, and under what conditions? The second is what that looks like once the product is an actual instance with real functionality.

Evaluating the software stack in general

The CRA applies horizontally to products with digital elements, but scope within a product is not uniform. Device software always falls under Annex I. Data processing, bi-directional services, and ML/AI services fall in scope when they are essential features of the product. Read-only digital services typically do not, depending on dynamic data integration. The CRA column of the conditional map below summarises this.

The AI Act applies to AI systems. ML/AI components are in scope whenever they exist, with requirements depending on risk level under Article 6 and Annex III. The remaining components are drawn in conditionally: device software if it is part of the AI system, data processing if it feeds high-risk AI, bi-directional services if they carry high-risk AI commands, and read-only services only when ML/AI functionality is present. The AI Act column of the map captures these conditions.

Applying the framework to the EMS example

Resolving the conditions against the EMS collapses most of them into a single verdict. The forecasting and optimization models are AI components by definition. Grid-balancing AI used in the management of electricity distribution or transmission can fall under Annex III point 2 as a safety component in critical infrastructure, so in this class of deployment the AI system is high-risk. Once that is established, the downstream dependencies follow: data processing feeds the model, bi-directional services carry its commands, device software executes them, and all of them are essential features of the product. Only read-only monitoring stays outside both regimes. The second map shows the same stack with the EMS-specific conditions resolved.

Joint conformity: the Article 12 bridge

For high-risk AI systems, CRA Article 12 provides an explicit bridge to the AI Act. Compliance with the CRA essential cybersecurity requirements in Annex I grants a presumption of conformity with the cybersecurity leg of AI Act Article 15. Article 12(2) goes further and enables a single conformity assessment path, so a manufacturer can in principle rely on one notified body procedure and one technical file that satisfies both CRA Annex VII and AI Act Annex IV. The presumption is narrow: it covers cybersecurity. It does not discharge the accuracy and robustness obligations that also live in Article 15, and it does not touch the AI Act risk management, data governance, transparency, or human oversight duties.

For the EMS example this means the joint conformity path is available. General applicability is split across the architecture. Most of the stack falls under both regimes simultaneously, which is exactly the situation Article 12 was written for.

CRA and AI Act Threat Model: ICS Attacks Meet Adversarial ML

Once the regulatory map is clear, the threat model follows. CRA Annex I Part II treats the product as an attack surface: data integrity, authenticated commands, supply chain, and vulnerability handling. AI Act Article 15(5) adds a specific set of AI threats: training data poisoning, adversarial inputs at inference, and manipulation of AI-generated outputs.

In an AI-driven industrial system these two threat families do not sit in separate lanes. They converge on the same components. A tampered telemetry stream is both a CRA integrity violation and an AI Act poisoning vector. A spoofed command and a manipulated optimization plan produce the same unsafe setpoint at the asset. A compromised data processing layer biases the trained model and breaks product integrity in one move.

For engineering teams, this argues for one unified threat model rather than two separate ones. MITRE ATT&CK ICS and MITRE ATLAS describe the two attack surfaces in their respective vocabularies, but the controls that address them (verifiable data provenance, signed commands, cryptographic notarization at source) converge on the same data and command paths. Designing the threat model around those convergence points satisfies both regimes with a single set of engineering decisions.

Data Provenance: One Control for CRA Annex I and AI Act Article 10

Data integrity is where the CRA and the AI Act converge most clearly at the engineering level. The AI Act requirements include: documented data origin and quality (Article 10(2)(a) and Article 10(3)), measures against training data manipulation (Article 15(5)), and provenance evidence in the technical file (Annex IV, Section 2(d)). The CRA, in Annex I Part I, requirement (f), requires that products with digital elements protect the integrity of stored, transmitted, or otherwise processed data, commands, programs, and configurations against any manipulation or modification not authorized by the user.

Read together, the two texts point at the same technical control. For the EMS example it means verifiable integrity of telemetry from the sensor at the asset, across the edge, into the central data store used for training, and of the dispatch commands flowing back to the device. Access controls and audit logs describe what should happen. Cryptographic verification (signed data at source, tamper-evident storage, verification before training and before command execution) produces mathematical evidence that it did. That evidence is what a regulator asking for provenance or integrity proof can actually work with.

This is a convergence point rather than a new requirement. Teams that treat data integrity as a single architectural property across the stack end up with one set of evidence that serves the CRA integrity requirement, the AI Act data governance requirements, and the AI Act cybersecurity requirement via the Article 12 bridge.

One Technical Documentation for CRA Annex VII and AI Act Annex IV

CRA Annex VII and AI Act Annex IV have substantial overlap. Both require a general description of the product or system, a design description, a risk assessment, information on the software bill of materials, a change log, post-market monitoring arrangements, and the list of harmonized standards applied. The AI Act adds model-specific content such as training data characteristics, validation and testing procedures, performance metrics, and human oversight measures. The CRA adds product-specific content such as secure default configuration, update mechanisms, and the vulnerability handling process.

A practical approach is to design one technical file with a shared spine and two specialized sections, rather than two disconnected documents. Version control, signatories, and the change-management process can then be run once for both regulations.

CRA Update Obligations and AI Act Post-Market Monitoring

The CRA expects manufacturers to provide security updates during a defined support period aligned with the expected product lifetime, with a minimum of five years where the product is expected to be in use for that long. For a fleet of edge EMS installations that can mean thousands of devices receiving signed updates over many years. The AI Act adds continuous compliance monitoring under Article 72, including data collection and analysis that lets the provider evaluate ongoing conformity with Article 10 and Article 15.

Both obligations push in the same direction: instrumented, automatable evidence that the deployed system, including its data inputs, still behaves the way the technical file says it does. Designing for this operational tail early is cheaper than retrofitting it.

What the Digital Omnibus Changes for CRA and AI Act

The Commission's upcomming Digital Omnibus package is optimizing the EU digital rulebook, expected in the second half 2026. For engineering teams already planning for CRA and AI Act, the relevant question is narrow: what actually changes?

CRA: Requirements and Timelines Unchanged

CRA requirements and deadlines stay as published. Annex I applies as-is, Article 14 reporting goes live 11 September 2026, and full applicability remains 11 December 2027.

What does change is reporting logistics: incidents flow through the ENISA single reporting platform, NIS2 alignment removes duplicate notifications, and high-risk data breaches share a harmonized 96-hour window. Less administrative friction, same substantive obligations.

AI Act: More Movement

The AI Act changes more:

• Later deadlines. Article 6(2) moves to 2 December 2027, Article 6(1) to 2 August 2028.

• Joint conformity assessment with relevant sector legislation (e.g. MDR/IVDR), via new Annex XIV NANDO codes

• Clearer legal basis for personal data in training (GDPR Art. 6(1)(f)) and special-category data for bias detection.

• Lighter obligations for small mid-caps and a shift of AI literacy duties to Commission and Member States.

• Centralised oversight from the AI Office for GPAI-based systems and VLOPs/VLOSEs, with an EU-level GPAI sandbox from 2028.

For an EMS provider: more AI Act preparation time, a simpler conformity path where sector rules apply, and clearer ground for training-data work. CRA stays the fixed anchor in the plan.

CRA, AI Act, Data Act, ESPR: The Four-Regulation Picture

A compliance roadmap that considers only CRA and AI Act misses two regulations that land on the same products. The Data Act imposes access and portability obligations on data generated by connected products and related services. The ESPR introduces the Digital Product Passport for product groups covered by delegated acts. Energy storage is already on that list and more industrial product categories are likely to follow.

For the EMS example this matters. Battery systems under the Digital Battery Passport must carry lifecycle data accessible via a data carrier. Operational data generated by the EMS may fall under Data Act access rights for the deployer. These duties share infrastructure with CRA and AI Act: trusted data, controlled access, lifecycle documentation. Treating the four regulations as one landscape avoids duplicated work and compliance gaps.

Recommended reading: our post on how CRA, ESPR, Data Act, and AI Act map across the product lifecycle: Navigating CRA, ESPR, Data Act and AI Act.

A Shared Compliance Foundation for CRA, AI Act and Digital Product Regulations

Regulations that overlap reward architectures that overlap. When CRA, AI Act, Data Act, and ESPR all ask for versions of the same property, trusted data, controlled access, versioned documentation, lifecycle integrity, building those properties once as shared technical and organizational foundations is strictly cheaper than building them four times.

The compounding returns show up in three places. Technical: one data integrity layer, one access architecture, one documentation pipeline feed multiple regulatory outputs. Organizational: one risk management process, one update release process, one incident response process carry evidence into several compliance files. Commercial: an integrated program moves faster through notified body engagement, reduces audit overhead, and adapts better as new regulatory deltas appear.

For teams building industrial AI systems, the strategic question how to design one foundation that accounts the next wave of product regulation. Getting that foundation right is what turns compliance from a cost center into a durable product advantage.