Five EU rules that now shape system architecture

Regulation is usually read as a list of duties to document. The five instruments in this article are better read as a list of properties a system has to be able to show: where a boundary runs, what a build produces, who can reach a repository and from where, where data has to be able to go, and who answers when something goes wrong. Each of them changed status between September 2025 and September 2026, and each was read at its primary source on 17 September 2026. The dates are those in the instruments themselves, not in secondary reporting.

This is a map, not advice. Whether any of these texts applies to a particular system is a legal determination that depends on the product, the sector and the role of the organisation, and nothing below replaces it. What the article does is translate each instrument into the architectural question it forces, because that question has to be answered in the design, before a lawyer is asked.

Regulation (EU) 2024/1689, the AI Act, does not apply to AI systems where and in so far as they are placed on the market, put into service or used, with or without modification, exclusively for military, defence or national security purposes (Article 2(3)). The word that matters is exclusively. A system built for both a civil and a defence use is not exclusively military, so its civil use is inside the Regulation in full, whatever its defence use is.

The timetable moved this summer. Regulation (EU) 2026/1744, the Digital Omnibus, entered into force on 27 July 2026 and rescheduled the high-risk regime: the standalone categories of Annex III, such as employment decisions and access to essential services, apply from 2 December 2027, and the systems embedded in regulated products under Annex I from 2 August 2028. The transparency duties of Article 50 were not deferred and have applied since 2 August 2026, with a transition to 2 December 2026 only for the marking duty on generative systems already on the market. The prohibitions of Article 5 have applied since 2 February 2025.

For architecture, Article 2(3) is a boundary that has to exist in the system, not only in a contract. If a model trained on civil data is reused in a defence context, or a defence component is reused in a civil product, the two uses have to be separable on demand: separate deployments, pipelines that do not share training data or weights by accident, and provenance for every artefact that says which side it belongs to and what it was built from. That is the logic of a digital product passport applied to models, datasets and prompts. An artefact that cannot state its origin cannot be placed on either side of the line.

Regulation (EU) 2024/2847, the Cyber Resilience Act, applies in full from 11 December 2027, but its reporting duty came first. Since 11 September 2026, Article 14 requires a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements, or of a severe incident affecting its security, to notify it through the single reporting platform run by ENISA: an early warning within 24 hours, a notification within 72 hours, and a final report no later than 14 days after a corrective measure is available, or one month for an incident. Impacted users have to be informed without undue delay, together with the measures they can take (Article 14(8)). Chapter IV, on the bodies that will assess products, has applied since 11 June 2026.

A 24-hour clock cannot be met by a process that starts with someone opening a spreadsheet. It presupposes that the manufacturer already knows what is in every shipped version, which requires a software bill of materials produced by the build rather than written afterwards; that it learns of exploitation from the field, which requires telemetry from the deployed product and a route for vulnerability reports; and that it can ship a corrective release within days, which requires a delivery pipeline that is exercised routinely rather than in emergencies. In Germany the Technical Guideline TR-03183 of the Federal Office for Information Security describes the minimum content such a bill of materials should carry.

Regulation (EU) 2021/821 controls exports of dual-use items, and its definition of export does not stop at goods crossing a border. It includes the transmission of software or technology by electronic media, and making such software or technology available in electronic form to persons outside the customs territory of the Union (Article 2(2)). A developer outside the Union who is given access to a repository, an object store or a cluster holding controlled technology is, under that definition, receiving an export, and it needs the same authorisation a shipment would.

The control list, Annex I, was updated by Commission Delegated Regulation (EU) 2025/2003, in force since 15 November 2025. The update brought in quantum computers and their cryogenic components, equipment and materials for advanced semiconductor manufacturing, high-performance computing, additive manufacturing systems for metals and the powders they use, and further advanced materials. Much of that list describes what an industrial software company builds for, or runs on.

Architecturally this turns identity and access management into an export-control instrument. An access decision has to be able to evaluate where the person is and where the data would go before it grants anything; where items of United States origin are involved, that country's rules add nationality as an attribute, which European law does not. Both attributes are personal data, so collecting them has to be justified against data minimisation under Article 5(1)(c) of the GDPR, and that tension has to be designed rather than discovered. And because a classification belongs to an artefact and not to a team, it has to travel with the artefact through the build: a repository, a container image and a model checkpoint each carry their own classification, and a pipeline that cannot read it cannot enforce it.

Regulation (EU) 2023/2854, the Data Act, has applied since 12 September 2025. It gives users of connected products, and of the services related to them, the right to access the data those products generate and to have it shared with a third party of their choice (Articles 4 and 5). For products placed on the market after 12 September 2026, the product itself has to be designed so that the data is accessible by default, easily, securely and in a comprehensive, structured and machine-readable format (Article 3(1)).

The same Regulation reaches cloud providers. Providers of data processing services have to let a customer switch to another provider or to their own infrastructure, with functional equivalence where the service is of the same type. Switching charges have been reduced since 11 January 2024 and may not be imposed at all from 12 January 2027 (Article 29).

For a manufacturing or edge architecture, the consequence is that a data export interface is a product feature with a legal definition, and that a deployment that can leave its cloud provider is a requirement rather than a preference. The data model of a machine, and the formats in which data leaves the machine, are now part of what a design has to show.

Directive (EU) 2022/2555, NIS2, obliged Member States to apply their transposing measures from 18 October 2024. Germany was late: its implementing act, the NIS2UmsuCG, entered into force on 6 December 2025 and rewrote the BSI Act. The federal government's estimate accompanying the bill put the number of entities brought into scope at around 29,500, across eighteen sectors, with the Federal Office for Information Security (BSI) as the supervisory authority.

Two provisions carry the architectural weight. The incident-reporting duty has the same shape as in the Cyber Resilience Act: an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within one month (Article 23 of the Directive). And section 38 of the new BSI Act makes the members of an entity's management personally responsible for approving the risk-management measures, for monitoring their implementation and for attending training, and it does not allow that responsibility to be waived.

Once a board is personally accountable, security stops being a supporting function and becomes a property the architecture has to demonstrate: an inventory of what runs, an incident path that can meet a 24-hour deadline, resilience during an attack rather than only after one, and evidence that the approved measures are in fact in place. A measure that exists in a policy document and nowhere in the system is exactly what a supervisor will ask about.

Set side by side, the five instruments ask for five architectural properties. The AI Act asks where the boundary between civil and defence use runs, and for proof of which side an artefact sits on. The Cyber Resilience Act asks what a build produces and how fast a fix can ship. Export control asks who may reach a repository and from where. The Data Act asks where data has to be able to go and in what form. NIS2 asks who approved the risk and how it can be shown that what was approved is what runs.

What the five share is a demand for provenance and evidence at the level of the individual artefact: a model, a build, a container image, a dataset, a machine's data stream, each carrying its origin, its classification and the checks it passed. That is the property a digital product passport gives to a physical product, and it is the property these texts now ask of software. A system that carries it can answer all five questions from its own records. A system that does not has to reconstruct the answer each time, under a deadline.

It does not say that any of these instruments applies to a given system, product or organisation. Scope depends on facts this article does not have, and on definitions, such as product with digital elements, essential entity or data holder, that each text defines for itself.

It does not say that the architecture described here is sufficient. Separate deployments, a bill of materials, attribute-based access, an export interface and an incident path are what the texts presuppose; each instrument asks for more, and some of it, such as the assessment of products under the Cyber Resilience Act or registration with the BSI, is procedural rather than technical.

And it does not say that the dates are final. Three of the five instruments have already moved once. Every date above names the instrument it comes from, so that a reader can check it against the text on the day it matters.