The EU Data Act became applicable on 12 September 2025. For industrial operators, manufacturers, and cloud providers, the wait-and-see period has ended.
The Act has established a live regulatory environment in which access to industrial data, and the right to share it with third parties, is a statutory right of the user.
The regime is overseen by designated authorities across the EU and backed by penalties of up to 4% of global annual turnover.
The statutory obligations and their timing
The Data Act is a sequence of technical floors that impose cumulative requirements on the data holder, typically the OEM that manufactured the product or the provider of the related service that makes it work.
The access and sharing mandate. Since 12 September 2025, under Articles 4 and 5, users hold the legal right to request the data their assets generate, and to authorise its transfer to third parties of their choosing. This applies to legacy and new devices alike. The data holder must provide the pipe in a structured, machine-readable, free-of-charge format, and where technically feasible continuously and in real time. The same data must be made available repeatedly to multiple distinct recipients under the user's authority.
Design by default. From 12 September 2026, Article 3(1) closes the reactive compliance route for new products. Every connected product placed on the EU market from that date must be engineered for direct, machine-readable access by default, without the manufacturer acting as a constant intermediary.
The firmware warning. A substantial firmware or feature update to a legacy product may be construed as a new placing on the market, which can pull that device into the Article 3(1) design regime.
The paradox of openness and security. These transparency mandates must be satisfied alongside the requirements of NIS2 and the Cyber Resilience Act. The Data Act demands openness. The security regimes demand minimal attack surfaces and tightly governed access. Reconciling them requires an architecture that can open the data door for an authorised party without leaving the house unlocked for an attacker, and that can prove it did so under audit.
Why downstream compliance struggles
Most enterprise architectures attempt to solve compliance at the historian or cloud layer, after operational data has already been extracted and centralised.
This downstream approach triggers three failures as the regulation tightens.
The context tax. Once operational data has been stripped of its context and flattened into a cloud database or a historian's compressed schema, satisfying a user request becomes a manual reconstruction project. The Act creates a continuous obligation, so the engineering cost recurs with every request, for every device generation, and for every new third party authorised under Article 5.
The egress trap. The Act guarantees free-of-charge access to the user, but the data holder bears the operational cost. Extracting the entire telemetry stream into a hyperscaler only to serve a fraction of it back out converts a statutory right into an open-ended cloud, storage, and egress bill. The legal default has been reset. The economics have not, unless the architecture is.
The legacy gap. Older PLCs, RTUs, AMI infrastructure, and proprietary sensors cannot natively speak the structured formats the Act requires. Closing this gap through device-by-device custom gateways is too fragmented to satisfy a regulatory audit. Forcing all industrial data into the cloud to be treated for compliance is neither practical nor secure, and it deepens the lock-in the Act is specifically designed to dismantle.
Compliance treated as a downstream reconstruction effort scales badly with telemetry volume, with the number of third parties involved, and with the diversity of the installed base.
Altior: compliance at the operational technology layer
Altior shifts the interoperability requirement upstream, embedding it within the operational technology layer.
Altior's digital twin architecture federates data from heterogeneous sources, including cellular IoT through 3G, 4G, NB-IoT, and LTE Cat-M, alongside LoRaWAN, wireless M-Bus, Wize, Wi-Fi, and LwM2M at the network layer, and MQTT, AMQP, HTTP, gRPC, QUIC, and TCP and UDP-based protocols at the application layer.
Data is governed and filtered at the source, and only what is necessary moves upstream.
A unified interface for the entire fleet. A legacy AMI meter served under Article 4 and a 2027-spec sensor designed under Article 3(1) appear identically at the data layer, exposed through the same twin abstraction and governed by the same access controls. The data holder discharges both sets of obligations through one architecture rather than maintaining parallel systems for each device generation.
Security at the point of origin. The Aegis framework resolves the tension between transparency and security. Authentication and identity integrate through OAuth 2.0, OpenID Connect, and SAML. Fine-grained authorisation is enforced through ACLs and RBAC at the digital twin level. End-to-end encryption is supported by distributed key management through ska, aligned with NIST SP 800-57. Governance is enforced at the twin rather than downstream, which keeps the attack surface defined by NIS2 and the Cyber Resilience Act minimal.
Operational autonomy. A no-code visual designer puts data-flow configuration in the hands of the personnel closest to the technology, with access to twin properties and current cluster state, and with automatic code generation for native middleware applications where performance requires it. The IT bottleneck that typically slows Article 4 and Article 5 requests is removed, while the CIO retains the audit evidence required under both the Data Act and the security regimes around it.
Altior is designed to sit alongside the systems already on the estate.
Historians, hyperscaler platforms, and enterprise data lakes continue to do what they do best, with Altior feeding them operationally meaningful data in the form each is built to handle.
Altior versus the alternatives, obligation by obligation
Comparing Altior to traditional methods against the obligations of the Act, the architectural differences are important.
For Article 4 and Article 5 requests, industrial historians and hyperscaler IoT platforms require manual retrieval and bespoke integration for every new third-party recipient, each one sitting downstream of where the data was generated. Altior provides this access natively, through the digital twin. Authorised third parties read the same structured representation the user reads, on the user's instruction, without OEM intervention.
For the Article 3(1) design obligation, historians and cloud platforms sit too far downstream to influence the product itself. Altior provides a twin-based design pattern that manufacturers adopt at the product level, so new assets are born Data Act-ready before they reach any downstream system.
Economically, traditional approaches increase compliance costs with telemetry volume. Altior's capacity-based licensing decouples those costs from volume, which is what makes continuous free-of-charge access financially sustainable.
On sovereignty and portability, hyperscaler-based deployments are bounded by regional architectures and contractual switching costs, both of which the Act's cloud-switching regime is designed to dismantle. Altior is cloud and infrastructure agnostic, deployable on-premise, on private cloud, on public cloud, or in hybrid configurations, so switching rights are preserved as an architectural property.
The next phase of industrial architecture
The regulation has set standards that cannot, and should not, be resolved in the cloud.
The economics break under free-of-charge access at telemetry scale. The security perimeter widens precisely where NIS2 and the Cyber Resilience Act require it to narrow. Latency makes continuous, real-time access difficult to deliver.
And practically, neither the industrial operator nor the cloud provider actually wants every byte of telemetry sitting in the cloud at all times.
The industrial operator does not want to lose sovereignty over its own data. The cloud provider does not want to ingest, store, and govern undifferentiated streams that carry no value for the workloads cloud platforms were built for.
Altior makes that alignment of interests architecturally workable.
Data is compliant at the source.
Only what is needed moves upstream.
Historians continue to deliver the engineering and process reporting they were built for.
Cloud providers, including sovereign European providers, offer the analytics, modelling, and AI services their platforms are good at, on data that has been filtered and structured before it arrives.
The industrial operator retains the position the Act intended for the user, namely that the data remains theirs, auditable and secure, and usable as they see fit.
That transition should begin at the operational technology layer.
