Digital sovereignty for OT security, in four questions.

Most sovereignty debates are about law. A plant team needs concrete answers. Where does enforcement run? Where does the evidence live? Who else can reach your network?

Last updated: August 2026

Request a demo Size my deployment From $5,745 per site

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
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

Treat sovereignty as an architecture question.

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

The four questions

Four questions 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

Data residency and encryption solve different problems.

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 EU member states require.

NIS2 does not require data to stay in the EU. It makes the operator accountable for supply-chain security under Article 21(2)(d). It also makes the operator accountable for the effectiveness of its measures under 21(2)(f). So a supervisory authority can ask you to show control over the security stack itself, as well as the plant. Several member states go further in sector rules and public procurement. There, hosting location and jurisdiction are more and more often scored criteria. If you sell to or operate critical infrastructure in Europe, expect 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 connects to your existing network, beside the assets it protects. The policy decision is computed on that appliance. Session recordings and the audit trail are written there. Access keeps working with no dependency on a vendor cloud. That gives the same four answers in every deployment. Enforcement is local. Evidence is local. The vendor reaches only what you explicitly grant. The plant keeps running if we are not there. The architecture is the same in Lyon, Dublin or Ohio. Framed this way, sovereignty is a property of where the compute sits, wherever the plant is.

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 gate is the first service you run, not the last.

Secure your plants today. Control your digitalization tomorrow.

Access Gate puts compute on the wire, next to your assets. Once the gate is in, the same box hosts the services that pull OT in securely: remote access, protocol gateways, DNS and time, historian, update server. Accelerate your digitalization, in control.

Request a demo Size my deployment

FAQ

Questions about digital sovereignty for OT.

It means you can answer four questions about your own deployment. Where is the enforcement decision computed? Where is the audit evidence stored? What can the vendor reach inside your network? Does the system keep working without the vendor? 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 the effectiveness of its measures under 21(2)(f). In practice, you must be able to show control over the security stack itself. Several member states apply stricter rules in sector regulation and public procurement.

No. A neglected on-premise appliance is worse than a well-run cloud service. On-premise changes which risks you own. You take on patching, backup and failover. In return, you no longer depend 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 about architecture. A US utility also wants its audit trail on site and its access control to survive a vendor outage. European regulation made the questions explicit. The answers matter everywhere.