Turning hybrid into singular

One obligation sits across many security models

A customer journey, payment service, transport network or water system is experienced as one service even when it depends on many generations of technology. Its control environment is rarely as coherent.

A SaaS platform may support contemporary identity standards. A mainframe may use a mature security model built around terminal sessions and long-established entitlements. A heritage application may accept only a username and password. An OT device may have been engineered primarily for safety, availability and deterministic operation. A field controller may communicate through an industrial protocol that does not carry a modern identity construct at all.

These are not failed systems. Many remain in operation because they perform valuable functions reliably. The difficulty appears when an organisation tries to impose a contemporary security outcome by changing every system internally.

The result is an estate of exceptions. MFA reaches the applications that can accept it. Fine-grained access reaches the databases that can express it. Strong audit reaches the services that expose suitable events. OT access is protected through a separate set of gateways and processes. The organisation can spend heavily and still retain a small number of interactions that do not meet the intended posture.

Minimum cyber expectations are converging

The frameworks differ by jurisdiction and sector, but the direction is increasingly consistent. Boards are expected to understand material cyber risk. Critical infrastructure operators are expected to identify what is vital, reduce unnecessary exposure, manage identity and privileged access, monitor activity, preserve evidence and prepare to isolate and recover.

Australia makes this particularly visible. The Essential Eight provides a prioritised baseline for internet-connected IT. ASD is explicit that it was not designed as an OT framework, even though some principles can inform OT controls. CI Fortify addresses the operational side more directly by asking critical infrastructure operators to identify vital OT and enabling systems, define isolation points, maintain critical services through extended isolation and prove that vital systems can be rebuilt.

The Security of Critical Infrastructure Act creates a parallel governance requirement. Responsible entities within scope must maintain critical infrastructure risk management programmes and governing bodies approve the annual report. The 2026 enhanced rules also incorporate recognised cyber frameworks, including the Essential Eight and NIST Cybersecurity Framework, into the risk management programme regime.

The same pattern is visible elsewhere. CISA describes its Cybersecurity Performance Goals as a baseline for both IT and OT owners. The UK Cyber Governance Code of Practice places cyber risk squarely at board level, while the NCSC OT connectivity principles call for limited exposure, brokered access, strong authentication, least privilege, logging and planned isolation. NIS2 requires management bodies of covered EU entities to approve and oversee cybersecurity risk-management measures. DORA places ultimate responsibility for ICT risk with the management body of financial entities. US public companies must disclose their cyber risk-management processes and board oversight under SEC rules, while sector-specific regimes such as the FTC Safeguards Rule impose concrete safeguards on covered financial institutions.

These instruments are not equivalent and they should not be treated as a single legal standard. Their common architectural implication is more useful: cyber governance is moving towards evidence that minimum outcomes are achieved across the service, including the systems that are difficult to change.

Heritage systems are not the problem

The word heritage matters because it changes the starting assumption.

A system that has survived for twenty or thirty years may contain substantial institutional knowledge. It may support a regulated process that has been proven repeatedly. In OT it may be tied to a physical asset whose safe operating life is much longer than a typical software cycle. Replacing that system simply to acquire one new security capability can increase risk rather than reduce it.

The problem is therefore not that the system is old. The problem is that the contemporary control requirement sits somewhere the system was never designed to express.

This distinction leads to a different design question. Instead of asking how to rewrite every application so that it can enforce the latest policy, ask where the interaction is already visible and where a new decision can be made without altering the system inside.

That is the point at which Data Mediation enters the architecture.

Data Mediation makes control a property of the path

A Programmable Data Agent is placed in the authorised data path between requester and target. The requester may be a person, an application, an AI agent, a vendor connection or another machine. The target may be SaaS, a mainframe transaction, a database, a terminal service, an HMI, a historian or an industrial controller.

The PDA understands the protocol and the context required for the policy decision. It can establish identity, inspect the requested operation, apply deterministic rules, invoke approved intelligence, transform the interaction and record the result before the exchange completes.

Consider MFA on a heritage application. The application does not need to learn a new authentication protocol. The mediated path identifies the user, invokes the contemporary authentication service and releases the original interaction only when the policy is satisfied. The application receives an interaction it already understands.

The same architecture can be used differently in OT. A remote engineering session can be brokered through a controlled path that requires strong identity, limits the target, constrains the permitted operation, records the session and remains subordinate to the operator’s safety and availability requirements. The policy outcome is common. The protocol-specific implementation is not.

This is what turns hybrid into singular. The technology does not become one stack. The control surface becomes one governed architecture.

A minimum posture can be extended across IT and OT

Data Mediation does not replace endpoint security, patching, segmentation, safety systems, backups, secure engineering or end-of-life replacement. It provides another place to implement controls when the native system cannot implement them quickly enough or consistently enough.

Across IT, that can mean enforcing MFA around a heritage application, masking sensitive fields in a database response, limiting an API operation by role, blocking a disallowed file transfer, inserting audit around a terminal session or applying a market-specific policy without changing the application code.

Across OT, the same architectural method can broker remote access, restrict communications to known peers, limit commands by function or state, observe protocol activity, separate read paths from control paths and create a narrower route between IT and OT zones. Whether a particular control is appropriate remains an engineering and safety decision.

The July 2026 FBI and EPA warning about attacks on internet-facing water-sector PLCs shows why the distinction matters. The agencies recommended removing direct exposure, brokering remote access through secure gateways, using strong authentication, restricting communications and maintaining manual operating capability. The warning was about specific controllers, but the underlying problem is broader: a contemporary control may need to be placed around an asset before that asset can be replaced or redesigned.

CI Fortify pushes the same logic further. Isolation and rebuild are not merely incident-response tasks. They are capabilities that must be designed before the crisis. A mediated architecture can help reduce the number of uncontrolled paths that must be understood and severed, while preserving explicitly approved data flows where the safety case allows them.

Platform-led implementation changes the economics of exceptions

The conventional response to a difficult cyber exception is often a project. A specialist team analyses the system, writes custom code, performs regression testing, passes change governance and deploys a local solution. The next exception starts again.

A platform-led model treats the control as reusable capability. Protocol definitions, authentication patterns, masking rules, audit requirements, deployment profiles and test evidence can be retained and applied again under local governance.

Historical TomorrowX deployments show why this matters. In one global bank, regulatory rules that previously required long application change cycles were moved to the mediation boundary and applied across numerous internet banking sites. The underlying applications remained unchanged. In another large enterprise, security controls were introduced alongside an application still under development, so protection did not have to wait for the application to be finished.

The economic shift is not that hard engineering disappears. It is that every policy change no longer requires a separate engineering programme inside every affected system.

That is the basis for a faster and more affordable route to minimum cyber coverage: solve the control problem once as a governed platform capability, then apply it at the boundaries where the risk exists.

Directors need evidence of coverage, not assumptions

Board accountability changes the test. It is not enough to know that an MFA programme was deployed. The relevant question is which material interactions remain outside it. It is not enough to know that OT is segmented. The question is which paths cross the boundary, who can use them, what they can do and whether those conditions can be evidenced.

A common mediation architecture can produce that evidence at the interaction point. Which identity was established. Which policy version applied. Which system or device was reached. Which data or command was permitted. Which exception was invoked. What happened next.

This does not make a board responsible for protocol design. It gives the organisation a way to connect board-level risk appetite to technical evidence across a mixed estate.

It also changes the role of Cyber, Enterprise Data Privacy and Protection and risk teams in new initiatives. When the control boundary exists from the beginning, those teams do not have to accept a project team’s assurances after the architecture is fixed. They can define what may move, which identity is required, what must be masked, which actions are permitted and what evidence must be retained.

That is how governance becomes an enabler. A large financial services deployment used this pattern to govern nineteen production sources feeding an account-intelligence workflow. The security and data-protection functions could enable the work because they controlled the data path rather than reviewing an uncontrolled one after the fact.

The estate does not have to become uniform to become governable as one

Modern cyber obligations are increasingly expressed across the whole service while the estate underneath remains heterogeneous. That gap is structural. It cannot be closed solely by asking every system to become something it was never designed to be.

Data Mediation changes the location of the control. Identity, policy, transformation, observability and evidence can be applied in the interaction path, then expressed according to the protocol and operating requirements of the target system. Native hardening and replacement continue where they are required. The organisation gains another route for dealing with the exceptions now.

The estate was never required to become one technology. It needed one governable control surface.