I work as a principal specialist at a pipeline operator where Operational Technology (OT) is the backbone of the business. I do not report to the board or act as a CISO, but the issues that get raised to those levels affect my job every single day.

Since the Colonial pipeline ransomware incident in 2021, it has become apparent that our industry has started posing different tones of “Are we zero trust yet?” I frequently witness its intense significance through auditing requests, TSA security directives and conversations around some control project’s goals.

One experience the zero trust role has changed is that it often feels misaligned with OT heavy environments. The NIST’s Zero Trust Architecture (SP 800‑207) model works for all, but is originally written as though for an IT network, not terminals, compressor stations and control rooms where equipment must run 24/7, perhaps more aged than the technology present within the organization. CISA’s guidance on adapting zero trust principles to operational technology helps close that gap, but applying it means satisfying the OT teams and company leadership at the same time.

The zero trust question I hear behind the scenes

I am pretty sure we all know it comes as a jolt of reality after something really major has happened, rather than a bullet point on a slide deck. You have pipeline. The whole distribution stops for six days. In Washington, DC, US congressional hearings are underway, and legislation is coming. TSA Directive 2021-02C requires pipeline operators to attest to several things, like network segmentation and zero-trust architectures.

NERC CIP-013 exists on a similar tack, more around supply chain security. In our case, the decision on how to select and manage a vendor partner and control their remote access is driven by regulatory compliance and governance frameworks. So, you have all those things that happen externally and force change. They say, “Are you zero trust? Yes or no?” We always get “yes.” They know it is not “yes, ” and the vendors know it is not “yes,” and nothing gets done about it until something happens.

How I reframe zero trust for OT in my work

My influence comes from how I frame problems and options in the conversations I am invited into. Zero trust is a good example.

NIST’s SP 800‑207 describes zero trust as a model where access decisions are to be based on strong identity, policy and context rather than network. CISA’s OT guidance narrows it, advising operators on the appearance of devices, identity management and what overlaps with IT instead of the overall replacement. Why zero trust breaks down in IoT and OT environments” highlights that when facing the complications of IoT and OT environments, one needs to be proactive.

During these conversations, I try to focus on three major points when talking about IoT.

1. Refer to zero trust as its functioning principle. In my experience, teams respond better when I say “Every user and system has to prove who they are and why they need access” than when I talk about abstract architectures. That language matches what NIST and CISA emphasize without overwhelming people with jargon.
2. Focus on where IT and OT converge, like jump hosts, historian connections, remote access paths and shared identity stores that span both worlds. Those are the choke points where zero trust style controls like stronger authentication, least privilege and detailed logging can give us quick wins without disrupting operations that depend on predictable behavior.
3. Tie everything that we need to do to the existing requirements. The conversation moves from “why are we changing this?” to “how do we do this well?” which aligns with TSA Security Directive Pipeline‑2021‑02C, a CISA alert or a NERC CIP‑013 requirement.

A 90-day plan OT leaders can execute

While someone operates a gas pipeline, they cannot play around with zero trust. Questions such as: “What can we accomplish before the TSA checks up next quarter?” Or “How can we show the internal audit team we are making progress this month?” comes often. We have established a list of actions we take over in a ninety-day plan, because we find it aligns more with our industrial settings while also being transferable to other OT settings.

Days 1–30: Map assets and identities at the IT/OT boundary

The first 30 days are for increased visibility. I focus on a relatively simple question: “Who and what can currently reach OT, intentionally or accidentally?”

CISA’s guidance on zero trust for OT, alongside other warnings, advocates for identifying and managing assets and communications where IT and OT interfaces exist, in addition to informal remote access routes. Also, TSA requires pipeline operators to regularly update and manage plans detailing which networks, systems and access points they will assess as per their established requirements across both IT and OT.

In my position, it comes down to three actions. First, I work with OT engineers, network staff and asset inventory systems to determine which OT assets threaten operations, safety or compliance if compromised, rather than inventorying every device. Second, I map the users and links that reach into OT, such as internal staff granted advanced privileges, remote vendor support, VPNs and cloud platforms that interact with production data. Third, I categorize these identities and connections based on risk, impact and exposure, not by their roles.

By the close of the first 30 days, the intention is to present leadership with an easily comprehensible overview: outlining the critical OT assets, delineating the entry points from both internal IT systems and external sources and identifying the associated identities. Having established this common understanding makes subsequent zero trust discussions less vague.

Days 31–60: Contain vendor remote access and create early wins

Look for quick wins in the next month, in a high-impact but non-disruptive area. Vendor or third-party remote access often fulfills it, and CISA has warned about it and continues to do so.

Their guidance emphasizes best practices, including using MFA, segmented user privileges and monitoring third-party activity independently. The NERC CIP-013 requires utilities to consider cybersecurity threats and risk management that protect their supply chains and suppliers that connect to critical systems. The TSA’s pipeline directives expect close monitoring and controls of remote access. In my case, early wins look like telling a vendor: OK, instead of an unsecured, remote access method, use an audited brokered remote access solution. MFA for any and all remote OT sessions. Close old vendor RDP connections that are not in service. You are simply saying that times change and since these methods were put in place a few years back, they have evolved; it is reasonable for you to evolve.

Days 61–90: Build a simple maturity scorecard and narrative

The third month is about visibility and repeatable progress. We now will have more clarity on assets and identities traversing the IT/OT boundary and have choked down the most dangerous of remote access paths. Now we will take time to track where we have been over time.

I will consult with leaders within security and OT teams to identify the right-sized set of metrics relevant to the specific context of the organization. While the specific terminology may vary, many will align with common language found in TSA, NERC, CISA and other industry documents. Consider the broad themes of “govern, protect and detect & respond”.

We can then identify solid “now” and “better next quarter” capabilities within each of these themes. “Govern” could incorporate specific OT policies on identity and access management that pull in zero trust directives alongside existing authoritative frameworks. “Protect” might track what fraction of your high-impact OT assets have been put behind better segmentation practices, coupled with the percent of your remote access pathways to OT identified as high-risk that have both MFA and a brokered connection. “Detect & respond” could see tested playbooks in place assuming a remote connection compromise that directly injects malware into an OT system, which aligns with how recent incidents have unfolded throughout North American utilities.

The output is not a scorecard to pass around but will be a meaningful, honest conversation for our leaders. You will know how to accurately frame how your organization applies zero trust in the OT world today, show what you achieved over the past three months and honestly describe where there is more work ahead.

I am not the only one trying to make zero trust ideas actually fit OT, and I pay attention to the CISOs who voice the same frustrations with IoT and OT environments. We are solving the same problem from different seats. What I have found is that a workable 90-day plan, updated monthly, beats any pledge to “Let us achieve zero trust together”

This article is published as part of the Foundry Expert Contributor Network.
Want to join?