Digital Compliance in Mechanical Engineering – Data Act, CRA and the AI Act in Tandem

Most machines today are operated by a control module that is regularly connected to the internet or a manufacturer’s platform and continuously generates data during operation for the purposes of maintenance and product and service improvement. This makes the control module a point of intersection between several regulatory frameworks that were originally separate, ranging from product safety, data law and cybersecurity to the regulation of artificial intelligence (AI). For machine manufacturers, acting in their capacity as manufacturers, these requirements will converge in autumn 2026 in a series of closely consecutive deadlines. From 11 September 2026, the reporting obligations under the Cyber Resilience Act (CRA) for actively exploited vulnerabilities and serious security incidents will apply, and from 12 September 2026 the Access by Design principle under Article 3(1) of the Data Act will impose a more stringent design requirement on connected products newly placed on the market. This article outlines the obligations under the Data Act, the CRA and the Artificial Intelligence Act (AI Act) that will be relevant to machine manufacturers from autumn 2026 and identifies the preparations that need to be made at short notice.

I. Background

The control module of a modern machine does far more than simply control operating sequences. Embedded software captures operating parameters, controls processes and records status information, which is transmitted to the manufacturer via a network or platform connection. This makes it possible to identify maintenance needs at an early stage, analyse operating data and offer additional services such as remote diagnostics or predictive maintenance. The resulting body of data is generally heterogeneous and includes machine and sensor data as well as configuration, usage and fault logs.

A considerable proportion of this data is not personal data but describes technical conditions and processes. The exchange of machine-generated data is governed by the Data Act, which grants the user rights of access to and sharing of non-personal product data without thereby conferring ownership of the data or any other inherent rights of use, and permits the manufacturer to use the data itself only on a contractual basis.

The distinction between personal and non-personal data is not, however, entirely clear-cut. Operating, maintaining and configuring a machine often requires the relevant user to log in, for example a member of the operating staff or an external maintenance technician. If access credentials, timestamps or individual operating actions are recorded in a way that allows them to be attributed to an identified or identifiable person, they constitute personal data within the meaning of the General Data Protection Regulation (GDPR). The data in question therefore remain subject to the requirements of data protection law, in particular the need for a valid legal basis under Article 6(1) of the GDPR. In practice, this means that one and the same data stream may have to be assessed differently under different legal regimes, and manufacturers should determine at the design stage which data, with what link to an identified or identifiable person, are processed for what purpose.

II. Data access under the Data Act

The Data Act has applied since 12 September 2025 and is tailored to data generated through the use of connected products and related services. Machine manufacturers will generally fall within its scope because their products continuously generate data during operation. Micro and small businesses with fewer than 50 employees and an annual revenue or total assets of no more than 10 million euros are largely exempt from these obligations.

Since 12 September 2025, users have had a right of access to readily available product data and related service data (as reported in Data Protection Update No. 214). This right applies irrespective of the date of manufacture and therefore also to existing machines, provided that the data holder already holds the relevant data, for example in a manufacturer’s portal or service back end. Users – typically the owners, tenants or lessees of the machine – can already rely on this right to request disclosure of the data generated through its use and to have that data made available to third parties. Users can therefore claim access to data to an extent that goes beyond the contractual arrangements. This is because the statutory right may also cover raw data and metadata and cannot effectively be limited by contractual arrangements to the contrary. Under Article 7(2) of the Data Act, contractual clauses that exclude or restrict the user’s access to the user’s detriment are not binding on the user.

The new requirement taking effect on 12 September 2026 concerns the design of the product itself. Under Article 3(1) of the Data Act, connected products and related services must in future be designed, manufactured and provided so that the data generated through their use are, by default, accessible to the user easily, securely, free of charge and in a comprehensive, structured, commonly used and machine-readable format. Where relevant and technically feasible, access must be possible directly from the product itself. This principle, known as Access by Design, requires the access capability to be built into the product architecture from the outset and generally cannot be implemented retrospectively without considerable effort.

Unlike the right of access that has existed since 2025, the design obligation applies only to connected products and related services placed on the market after 12 September 2026. There is no general obligation to retrofit existing products in this respect. However, because development cycles in mechanical engineering are long, the requirement has practical implications well before that date: products scheduled to be launched after the relevant date must take the access requirements into account during the preceding development phase. The design obligation is supplemented by the pre-contractual information obligations under Article 3(2) and (3) of the Data Act, which require, among other things, information on the nature, scope and format of the data generated and on ownership of trade secrets.

III. Reporting obligations under the CRA

Whereas the Data Act regulates who may access a machine’s data, the Cyber Resilience Act (CRA) focuses on the machine itself and, for the first time across the EU, establishes binding cybersecurity requirements for products with digital elements. Connected machines and their control modules generally fall within its scope because they contain software and have data connections. The obligations are addressed primarily to the manufacturer. For these purposes, that term covers not only the traditional hardware manufacturer but also anyone who markets products under its own brand or provides software.

The CRA does not become applicable at a single point in time but in stages. The Regulation will not become fully applicable until 11 December 2027. At that point, the substantive core requirements will apply, in particular the essential cybersecurity requirements for design and development (Security by Design), vulnerability management throughout a support period to be specified, conformity assessment, technical documentation and CE marking. Only the reporting obligations under Article 14 of the CRA have been brought forward: they already apply from 11 September 2026 and therefore constitute the first binding set of obligations for manufacturers.

Article 14 of the CRA requires the reporting of two types of event: actively exploited vulnerabilities in a product with digital elements and serious security incidents that have an impact on its security. By contrast, a vulnerability that has merely been discovered but not exploited does not trigger a reporting obligation. Reporting takes place in stages: an initial early warning must be submitted within 24 hours after the manufacturer becomes aware of the event, followed by a more detailed report within 72 hours and a final report. In addition, affected users must be informed of the incident and of available remedial measures. The reporting obligation applies not only to new products but also to products already placed on the market, provided that the manufacturer becomes aware of an actively exploited vulnerability after the relevant date.

For machine manufacturers, the real difficulty lies less in the reporting itself than in the conditions required for reporting. Compliance with the short deadlines presupposes that the manufacturer knows the software composition of its products and has channels through which it can learn of an ongoing exploitation in time. This is generally possible only if the manufacturer knows which software and third-party components are contained in each machine and has a process for detecting and internally categorising such incidents. The reporting obligation brought forward to September 2026 therefore has practical knock-on effects on requirements that formally apply only from December 2027, in particular structured vulnerability management and the recording of software components in the form of a software bill of materials (SBOM).

IV. Requirements under the AI Act

Control modules increasingly contain software components based on artificial intelligence, for example for adaptive process control, fault detection or the optimisation of operating processes. If a machine contains such an AI system, the AI Act may apply in addition to the Data Act and the CRA. For mechanical engineering, however, the relevant regulatory route has recently shifted: requirements for safety-related AI in machinery no longer arise from the AI Act’s set of obligations for high-risk AI systems, but from the sector-specific requirements of the Machinery Regulation governing AI-enabled safety components.

That classification is based on the system set out in Article 6(1) of the AI Act. Under that provision, an AI system is high-risk if it is used as a safety component of a product covered by the harmonisation legislation listed in Annex I to the AI Act, or is itself such a product, and the product is subject to third-party conformity assessment. For the machinery sector, this route previously ran through the Machinery Regulation, which was listed in Section A of Annex I to the AI Act. The AI Omnibus – Regulation (EU) 2026/1744 of 8 July 2026 – has, however, removed the entry for the Machinery Regulation from Section A and included it as No. 21 in Section B of Annex I. The amendment entered into force on 27 July 2026. The classification as a high-risk AI system therefore remains in principle. Under the amended Article 2(2) of the AI Act, however, AI systems in products listed in Section B are now subject only to Article 6(1), Article 60a and Articles 102 to 112 of the AI Act. In particular, the requirements of Chapter III and a separate conformity assessment under the AI Act no longer apply.

The requirements for safety-related AI do not therefore disappear; rather, their legal basis changes. Regulation (EU) 2026/1744 requires the Commission to supplement Annex III to the Machinery Regulation by means of delegated acts to include essential health and safety requirements for AI systems that are used as safety components in machinery or themselves constitute machinery, taking into account the requirements of Chapter III, Section 2 and Articles 17, 19, 72 and 73 of the AI Act. These delegated acts are intended to apply from 2 August 2028, thereby ensuring alignment with the date on which the obligations for high-risk AI systems under Annex I to the AI Act begin to apply. The relevant requirements will therefore be the sector-specific requirements of the Machinery Regulation and the newly worded definition of a safety component, which expressly includes software and learning systems. Under Annex I, Part A, Nos 5 and 6 of the Machinery Regulation, this includes in particular safety components with fully or partially self-evolving behaviour based on machine-learning approaches and performing safety functions.

It therefore remains decisive whether the AI system performs a safety function. The AI Omnibus has sharpened this distinction (as reported in Data Protection Update No. 256). Under the clarified definition, a safety function exists only if the AI system’s intended purpose, as specified by the provider, is to avert or mitigate risks to health, safety or property. AI systems whose sole purpose is to assist users, optimise performance, improve service efficiency, automate processes or enhance ease of operation are expressly excluded. An AI module that merely optimises operating processes or processes diagnostic data, without itself performing a safety function, is therefore generally not a safety component and is not subject to the stricter requirements. A careful case-by-case assessment nevertheless remains necessary, because the same function may have to be assessed differently depending on the type of machine and the risk situation.

If, following this assessment, an AI system performs a safety function, the manufacturer is subject to the requirements applicable to AI-enabled safety components. For machinery, these do not arise directly from the obligations imposed on providers of high-risk AI systems – particularly not from the obligation under Article 9 of the AI Act to establish a risk-management system – but from the requirements transposed into the Machinery Regulation by delegated acts. In substance, the familiar requirements remain, namely risk management covering the entire life cycle and requirements relating to data governance, technical documentation, logging, transparency and human oversight. The international standard ISO/IEC 42001 may serve as a practical implementation tool, as it provides a framework for an AI management system and can map the requirements described above in a structured way. A distinction must be made as to timing: the Machinery Regulation already applies from 20 January 2027, from which date machine-learning-based safety components will be subject to conformity assessment by a notified body. The AI-specific requirements of Annex III to the Machinery Regulation, however, are not intended to apply until 2 August 2028, in parallel with the application date – postponed by the AI Omnibus – of the obligations for high-risk AI systems under Annex I to the AI Act.

V. Conclusion and outlook

In autumn 2026, machine manufacturers will face several regulatory instruments whose key dates are close together. From 12 September 2026, the Data Act’s Access by Design principle requires newly placed products to be designed so that the data generated are accessible to the user by default, easily, securely and in a machine-readable format and, where relevant and technically feasible, that access is possible directly from the product itself. The CRA brings the reporting obligations forward to 11 September 2026 and therefore already presupposes structured vulnerability management and knowledge of their own software composition before the remaining requirements apply from December 2027. The requirements for safety-related AI also apply whenever a control module performs a safety function. Since the AI Omnibus, these requirements for machinery are no longer to be met through the AI Act’s set of obligations for high-risk AI systems but through the sector-specific requirements of the Machinery Regulation, whose AI-specific requirements are intended to apply from 2 August 2028.

Despite their different objectives, the requirements often focus on the same areas, namely product architecture, data flows and internal processes. It is therefore advisable to consider these topics together rather than address them in isolation. As the relevant terms and requirements have so far been neither clarified by the courts nor conclusively specified in regulatory guidance, companies should keep a close eye on further developments.

For manufacturers of connected machines, we have developed a tailored Digital Compliance package that brings together the requirements of the Data Act, the CRA and the AI Act in a coordinated approach and provides support from the initial assessment through contract and process design to implementation within the business. Please feel free to contact us.

This article was created in collaboration with our student employee Emily Bernklau.