Digital sovereignty for OT security, in practice

Most sovereignty discussions are about jurisdiction. For the team running a plant, the question is more concrete: where does the enforcement run, where does the evidence live, and who else can reach your network.

Last updated: August 2026

See Access Gate

Short answer

For an OT operator, digital sovereignty comes down to four questions with checkable answers: where the enforcement decision is made, where the audit evidence is stored, what your security vendor can reach inside your network, and whether the system keeps working if that vendor goes away. A deployment that answers all four on-premise is sovereign in the sense that matters operationally, regardless of which flag is on the box.

Why this is an operations question

Sovereignty is usually argued at the wrong altitude

The public debate is about law: which jurisdiction can compel disclosure, which statute reaches which data. That debate is real, and for European operators under NIS2 it has procurement consequences. But it is not the version of the question a control engineer can act on, and it is not the version that determines what actually happens on your network next Tuesday. The operational version is architectural. Every OT security product makes a choice about where the decision is computed and where the record is kept. Those choices are visible, testable, and they do not change when a legal opinion changes. They are also the ones that survive a vendor being acquired, changing its terms, or having an outage.

The four questions

What to ask about any OT security deployment

Where is the enforcement decision made?

When a user or a device asks to reach a controller, something decides yes or no. If that decision requires a round trip to a vendor's cloud, then your plant floor depends on their availability and their network path. If it is computed on a box in your building, it does not.

Where does the audit evidence live?

Session records, access logs and change history are the artefacts you hand a regulator. If they are stored in a vendor tenant, you are asking a third party to hold your compliance evidence, and your retention is their retention policy. If they are on-premise, the question does not arise.

What can the vendor reach?

Many OT security products maintain a management channel into the environment they protect. That channel is a legitimate design choice and also a real attack path, as the last several supply-chain incidents have shown. Ask what it can reach, who can use it, and whether you can watch or sever it.

What happens if the vendor disappears?

Acquisition, price change, end of life, or an outage. If the answer is that access control stops working, the dependency is not a commercial risk, it is an operational one. A system that keeps enforcing its last known policy without a call home is a different class of thing.

Data residency

Residency is not the same as encryption

Vendors often answer a residency question with an encryption answer: the data is encrypted in transit and at rest, so it is safe. Those are different properties. Encryption protects the content from an interceptor. Residency determines who can be compelled to produce it, which retention rules apply, and whose incident becomes your incident. For OT specifically, the sensitive material is not only process data. It is the network map, the asset inventory, the list of who can reach which controller, and the recordings of engineering sessions. That set describes exactly how to attack the plant. It is worth knowing where it sits.

Regulatory pressure

What NIS2 and the member states actually require

NIS2 does not mandate that data stay in the EU. What it does is make the operator accountable for supply-chain security under Article 21(2)(d) and for the effectiveness of its measures under 21(2)(f), which means a supervisory authority can ask you to demonstrate control over the security stack itself, not just over the plant. Several member states go further in sector-specific rules and in public procurement, where hosting location and jurisdiction are increasingly scored criteria rather than preferences. If you sell into or operate critical infrastructure in Europe, the direction of travel is toward having to answer the four questions above in writing.

See also NIS2 compliance for industry and OT and the secure OT remote access guide, which covers the Article 21(2)(d) supply-chain obligation in detail.

The architecture

What an on-premise enforcement layer changes

Access Gate is an appliance that sits in the data path in front of the assets. The policy decision is computed on that appliance, the session recordings and audit trail are written there, and there is no dependency on a vendor cloud for access to keep working. That gives the same four answers in every deployment: enforcement is local, evidence is local, the vendor reaches nothing it is not explicitly granted, and the plant keeps running if we are not there. It is the same architecture whether the site is in Lyon, Dublin or Ohio, which is the point. Sovereignty framed this way is not a European feature, it is a property of where the compute sits.

For the mechanism itself, see what is an industrial proxy and agentless Zero Trust for OT.

Honest limits

What on-premise does not solve

On-premise is not automatically more secure. A badly configured appliance in your own rack is worse than a well-run cloud service, and running it yourself means you own patching, backup and failover. It also does not make you compliant: NIS2 asks for governance, training, continuity and vulnerability handling, none of which a network control provides. What it does is remove an entire category of question from the conversation. You are not reasoning about a third party's jurisdiction, retention or uptime, because the third party is not in the path.

The second layer of value

Access Gate secures your assets first, then exposes the simple services your teams and vendors actually want, so they run through the sanctioned path, not around it.

OT runs through you, not around you.

FAQ

Frequently asked questions

Practically, it means you can answer four questions about your own deployment: where the enforcement decision is computed, where the audit evidence is stored, what the vendor can reach inside your network, and whether the system keeps working without them. A deployment that answers all four locally is sovereign in the operational sense.

No. NIS2 does not impose a residency requirement. It makes the operator accountable for supply-chain security under Article 21(2)(d) and for demonstrating the effectiveness of its measures under 21(2)(f), which in practice means being able to show control over the security stack itself. Several member states apply stricter rules in sector-specific regulation and in public procurement.

No, and treating it that way is a mistake. A neglected on-premise appliance is worse than a well-operated cloud service. On-premise changes which risks you own rather than removing risk: you take on patching, backup and failover, and you remove dependency on a third party's availability, retention and jurisdiction.

More than process values. Typically the asset inventory, the network map, the access matrix showing who can reach which controller, and recordings of engineering sessions. Collectively that describes how to attack the plant, which is why where it is stored is worth asking about.

Access does not depend on it. The policy decision is computed on the appliance and the audit trail is written locally, so sessions continue to be brokered and recorded whether or not the appliance can reach us. Software updates are a separate, operator-initiated path.

No. The four questions are architectural, not jurisdictional, and a US utility has the same interest in its audit trail staying on site and its access control surviving a vendor outage. European regulation is what has made the questions explicit, but the answers matter everywhere.