September 2026: What the Cyber Resilience Act Means for Connected Infrastructure

From 11 September 2026, new vulnerability-reporting obligations under the EU Cyber Resilience Act (CRA) begin to apply. These obligations sit principally with manufacturers of products with digital elements, which must report actively exploited vulnerabilities and severe security incidents affecting their products.

The wider CRA regime follows from December 2027, including requirements around security by design, vulnerability handling, technical documentation, software component information and declarations of conformity. Manufacturers must retain the relevant technical documentation and EU declaration of conformity for at least ten years after the product has been placed on the market, or for the support period, whichever is longer.

When a manufacturer identifies a vulnerability, issues a mitigation or changes the security status of a product family, the operator needs to understand what that means across its deployed estate.

It needs to be able to answer, with confidence:

What is this device? What is it running? Where is it? What state is it in? What has changed? Who can access it? Where is its data going? And can we demonstrate that when required?

Across a small, homogeneous deployment, this may be manageable.

Across hundreds of thousands or millions of meters, sensors, gateways and controllers spanning different manufacturers, networks and generations of technology, it becomes an operational-data challenge.

CRA, NIS2 and the deployed estate

The CRA and NIS2 address different parts of the same connected environment.

The CRA strengthens the cybersecurity lifecycle of products with digital elements. Manufacturers have responsibilities around security by design, vulnerability handling, software components, security updates, reporting and conformity.

NIS2 requires covered utilities and infrastructure operators to manage cybersecurity risk across their operations, including incident handling, resilience and the security of their supply chains and relationships with suppliers.

This creates an important connection between the two regimes.

Information generated through the CRA framework — including software component information, vulnerability handling, support periods and conformity documentation — can provide useful evidence for an operator's own supply-chain risk management.

CRA information relates to products. The operator needs to relate it to the actual assets deployed across its estate.

A manufacturer may, for example, identify a vulnerability affecting a particular device family or software version. The operator then needs to determine which of those products are actually deployed, where they are, their current operational state and whether the required mitigation has been implemented.

A Software Bill of Materials is valuable in understanding the software components and dependencies within a product. Its operational value increases when that information can be connected to the physical population of products running in the field.

In many OT environments, this information is distributed across HES, SCADA and device-management systems, OEM platforms, asset databases, protocol layers and engineering records.

At infrastructure scale, bringing those sources together requires a current and governed view of the physical estate.

From data to operational state

Altior maintains the operational state of an asset, not simply the stream of observations generated by it.

A digital twin is created for each connected meter, sensor, gateway, machine or other operational asset. As information arrives, Altior maintains its current state and the context associated with it.

That context can include identity, ownership, location, communications, protocol, available firmware and configuration information, security attributes, access policy and other device-specific properties.

Where lifecycle or security information is available from a manufacturer, device, HES or another authorised source, it can be related to the same operational identity.

This provides the link between information about a product and the actual assets operating in the field.

It also avoids having to reconstruct that relationship from multiple systems every time an operational or cybersecurity question arises.

From inventory to continuous understanding

A static asset inventory provides part of the picture. Connected infrastructure, however, changes continuously.

Devices are replaced. Firmware is updated. Communications fail and recover. Credentials and access policies change. Networks are reconfigured. New device families are introduced.

Altior maintains available device state and configuration information as part of normal operation, with versioning and change management built into the platform.

It also monitors for meaningful changes in state.

A communications failure, configuration change, alarm or unexpected state transition can be treated differently from normal repeated telemetry. Relevant events can then be routed according to consumer, purpose and policy.

This creates a continuously maintained operational record rather than relying solely on periodic inventories or point-in-time assessments.

It can also reduce the amount of unnecessary data moving through the wider architecture. Not every repeated observation needs to be transported, stored and processed by every downstream system when the operational state has not meaningfully changed.

At the scale of national infrastructure, that can matter for network traffic, storage, cloud ingestion and downstream processing as well as operational visibility.

Governance at the point data is used

The same operational model can carry governance with it.

Security and access policies can be associated with individual assets and their digital twins. Altior supports authentication, authorisation, encryption and Zero Trust controls, while routing policies determine which information can be distributed, to whom and for what purpose.

The operator can maintain a governed representation of the physical estate and determine how information from that estate is exposed to different consumers — whether an operational platform, cybersecurity system, analytics environment, AI application, field-service provider or another authorised party.

Governance therefore becomes part of the operational data flow rather than something that has to be reconstructed downstream.

Working with the infrastructure already in place

A new operational data layer should not require an organisation to replace systems that already perform valuable functions.

Altior is designed to work alongside existing HES, SCADA, BMS, MES, asset-management, cybersecurity, analytics, digital-twin and AI platforms.

Those systems continue to perform their existing roles. Altior provides a consistent operational representation of the underlying heterogeneous estate and can expose the information each authorised consumer requires.

Reusable device models and intuitive building blocks allow teams to model assets, integrate data sources, maintain state and define routing and governance policies without creating another bespoke integration for every downstream application.

For device families that have already been digitalised, data can be exposed very quickly. New or more complex device types can typically be integrated in hours or days rather than requiring lengthy bespoke development programmes.

The complexity of heterogeneous infrastructure is handled within the operational layer and the resulting models can then be reused across sites, programmes and services.

That makes the approach practical and cost-effective even for estates containing very large numbers of relatively simple assets such as meters, submeters and sensors.

Control and data sovereignty

The architecture of the operational layer also determines who ultimately controls it.

Altior can operate at the edge, on-premise, in private or sovereign infrastructure, in public cloud, or across hybrid environments. Its architecture does not depend on a particular hyperscaler.

Public cloud may be appropriate for some workloads. Sovereign infrastructure may suit others. Critical systems may need to remain on-premise or close to the physical estate.

The architecture can follow those requirements while maintaining a consistent operational model.

Data sovereignty is therefore about more than where data is stored.

It is also about who controls the operational representation of the physical estate, who can access its information, where that information can be routed, under what policy, and whether that control can be retained as suppliers and applications change.

For infrastructure expected to operate for decades, that independence matters.

A reusable operational foundation

The September 2026 CRA reporting milestone makes these questions particularly timely, but the requirement extends well beyond regulatory assurance.

CRA strengthens the product-security information available around connected devices. NIS2 places broader cybersecurity and supply-chain risk-management responsibilities on covered operators. A governed operational data layer helps make product-level information usable across the physical estate in which those products actually operate.

The same foundation can then support asset management, device-status monitoring, cybersecurity, data sovereignty, digital twins, operational analytics and emerging Physical AI applications.

This becomes increasingly important as physical infrastructure becomes more software-defined and interconnected. AI and automation ultimately depend on knowing what an asset is, what state it is in, whether its data can be trusted and what an application is authorised to do with it.

Altior is designed to make that operational layer practical: continuously maintained device state, reusable digital twins, event-driven distribution, policy-controlled routing and flexible deployment across heterogeneous infrastructure.