Zero trust for OT: start with the remote maintenance session

24 October 2026 · jackjohnsongithub-4360ebf8e4

This post is for the information technology practitioner helping a small utility or industrial facility protect its controls. If you have been asked to bring “zero trust” to the plant, start by choosing one maintenance workflow that you and an operator can explain together.

On October 8, the National Security Agency, or NSA, released a Cybersecurity Information Sheet, “Hardening Department of War (DoW) Critical Operational Technology (OT) Environments with Zero Trust (ZT) Principles.” OT covers systems that monitor or control physical processes. The sheet is written for owners of national security systems, Department of War systems and the defense industrial base, not for utilities. This post is about what a small utility can borrow from it. The NSA announcement is the October news hook.

The agency describes zero trust as assuming compromise is possible or already present and verifying users, devices, workflows and communications. For a utility practitioner, the useful question is specific: what should an authenticated maintenance connection be allowed to do next?

Read the announcement with operational constraints in view

We could not retrieve the October sheet itself during this review. The practical discussion below therefore draws on an accessible earlier joint federal document, “Adapting Zero Trust Principles to Operational Technology,” published April 29. It should not be read as a detailed summary of the unavailable October report.

That earlier guidance explicitly warns against applying conventional IT zero trust capabilities wholesale to OT. It emphasizes safety, availability, legacy equipment and collaboration between engineers and security staff. It also identifies remote access and emergency overrides as areas where cross-disciplinary understanding matters.

Those qualifications deserve to travel with the October headline. A discussion about access controls should include the person who understands what happens to the process when a connection disappears.

Make one workflow visible

Our suggested starting exercise is a remote maintenance session. Imagine a contractor needs to investigate a control problem. This is a hypothetical planning example, not an account of an incident at a Midwest utility.

Draw the intended route from the contractor’s device to the approved access service, through the maintenance workstation, and finally to the equipment they need to inspect. Put a person’s name beside each approval and operating decision. Leave unknown connections visibly marked as unknown so someone can investigate them later.

Describe the task in operational language. “Investigate an intermittent pump status signal” gives the team something to discuss. “Vendor needs access” leaves the actual scope undefined. Ask what information the contractor needs, whether changes are expected, and who will remain available while the work happens.

Then identify the point where the task should stop. Perhaps the contractor needs to inspect one workstation but has no reason to reach another process area. Ask the networking and controls staff how they could enforce that boundary, what they would need to test, and what evidence would show the intended task still works.

This exercise gives a small team a manageable piece of work. It also creates a document that an operator can correct before anyone changes a rule.

What to do about it

Schedule a short review with an operator, the person managing remote access and the maintenance provider. Ask each person to explain the session from their side. Record where their accounts differ. Treat those differences as investigation tasks, especially where nobody knows who can approve access or end a session.

For the chosen workflow, propose named access, approval for the intended task and a defined maintenance window. Ask how authentication, authorization and session records would work in your environment. Authentication establishes who connected; the next decision is what that connection may reach and change.

Before implementing a restriction, write a test plan with operations. Include the intended maintenance task, other work that might share the connection, the expected behavior when access expires and a rollback procedure. Ask the equipment supplier or integrator to review relevant compatibility questions. Use the site’s existing change approval process.

Document an emergency path alongside the normal path. Who can authorize urgent access? How will the operator verify the requester? Where is the procedure available if the usual computer or identity service is unavailable? Plan a tabletop exercise to expose missing information without interrupting production.

Choose a small set of records the team can actually review. For this workflow, consider the access approval, connection start and end, the systems reached, and the operator’s maintenance note. Ask how those records can be connected during an investigation and who retains them. Avoid declaring the exercise complete merely because a logging option was enabled.

Also decide how exceptions will end. If a temporary arrangement is necessary, record its owner, operating reason and review date. Ask what additional observation or local supervision is appropriate until the preferred arrangement is ready. Bring unresolved safety questions back to the responsible operator and engineer.

These steps are proposed planning practices for a small team. They are not a claim that the October release mandates a particular product, architecture or implementation deadline for municipal utilities.

Define success in terms an operator can check

A useful first deliverable is a maintenance access diagram with approved destinations, named decision makers, a tested procedure and an emergency contact sheet. Ask an operator who missed the planning meeting to walk through it. Their questions will help identify assumptions that the original group left unwritten.

Keep an explicit list of what remains outside the review. Other contractors, locally connected engineering laptops and additional process areas can become later work items. Recording that boundary prevents one successful exercise from becoming an unsupported claim that the whole facility has been secured.

At the next maintenance window, compare the planned workflow with what actually happened. Update the document when the work reveals a legitimate dependency. Investigate unexpected access before making it permanent. Use that evidence to select the next workflow for review.

The October announcement gives practitioners a timely reason to have this conversation. For a small utility, the result worth asking for is a procedure that people can explain, operate and review while keeping the physical process under control.