Zero trust in industrial IoT: start with the access

Zero trust interests me because it forces a useful question: why does this connection need to exist?

That question gets harder in industrial environments. A building controller might have to keep running through an identity provider outage. A vendor may need remote access to one system. An older device might not support the authentication method you want, and you still have to protect it.

I wouldn't start by putting a new gateway in front of everything. I'd start with the systems, the people who depend on them, and the connections that keep the process running.

Map the path before changing it

Take a maintenance connection as an example. A technician signs in, reaches a remote access service, connects to an engineering workstation, and uses that workstation to reach a controller.

Each of those is its own boundary. The technician needs a verified identity, the workstation needs its own access controls, and the controller should only accept the traffic it requires. A successful login at the first step shouldn't grant a route to every device behind it.

I'd write down the source, destination, protocol, purpose, owner, and expected hours for each allowed connection. An unknown connection is something to investigate. It isn't automatically safe to block while the process is running.

Put the control where it can work

Some equipment can use certificates and encrypted protocols directly. Older equipment may need an enforcement point in front of it, such as a controlled jump host or an industrial gateway. That gateway doesn't give a legacy protocol properties it never had, and the network between the gateway and the device still needs protection.

Segmentation helps narrow which systems are reachable, application authorization narrows the actions, and identity and device checks add context. The controls support each other, but a VLAN alone doesn't make a design zero trust.

That's how I read NIST's zero trust guidance: network location shouldn't be enough to grant access to a resource.

Revocation has to be designed around the process

For a remote maintenance session, a short access window and a clear way to revoke it make sense. Applying the same timeout to a control loop could create a different problem.

Before enforcing a change, I'd want to know what happens when the identity service, the gateway, DNS, or certificate renewal fails. Can the local process keep going? How does an operator recover? Is emergency access documented and logged?

There's no universal five-minute session lifetime or latency budget for industrial systems. Those limits have to come from the process and its safety requirements. NIST's OT guidance is a useful reference for those constraints.

Test both the allowed path and the denied path

A useful test plan would cover:

• The authorized technician can reach the approved system and do the expected work.
• The same account cannot reach an unrelated controller or management interface.
• Removing access has the intended effect on new and existing sessions.
• A gateway or identity outage has a known recovery path.
• Logs identify the person, destination, action, and outcome well enough to investigate later.

I wouldn't claim this makes lateral movement impossible. Shared credentials, broad gateway permissions, or an overlooked route can still undermine the design. The goal is to reduce those paths, test the controls, and know what's left.