I have spent more than 13 years in enterprise and industrial security, and much of my recent work as an OT security architect involves looking closely at how people and systems actually reach production equipment in manufacturing plants. That means reviewing firewall change requests, OEM remote maintenance workflows, segmentation designs and the long tail of exceptions that builds up around all three. The leftovers I run into most often are firewall rules, vendor VPN access and service accounts that have outlived the projects that created them.
One case that stayed with me involved default passwords that were still in use on OT assets long after installation, which we only discovered because our OT threat monitoring flagged them. We changed the credentials and documented the accounts, then moved them into regular rotation, with the credentials injected through our secure remote access tool so that technicians and vendors could do their work without ever seeing the passwords. Cases like that are why the access that worries me most is usually the access that was approved for a good reason, still works and has not been questioned since.
This article looks at where Zero Trust tends to break down once it reaches the factory floor. I cover five places where implicit trust survives even after a user has been properly verified: inherited network routes, privileges held by service accounts and other non-human identities, vendor support paths, limited visibility into engineering actions and recovery assumptions that have never been tested. For each one I describe how I approach the problem in practice, from where I start a segmentation design to the questions I ask when a firewall change lands on my desk, and I finish with a review method and a set of measures that manufacturing leaders can use to tell whether trust in their environment is actually shrinking. Public incidents, including Colonial Pipeline, TRITON, Norsk Hydro and the 2023 Unitronics PLC compromises, anchor the discussion. The overnight support call that runs through the middle of the article is a composite I put together from conditions common across manufacturing sites, so please read it as an illustration of design and governance choices and not as an account of events at any particular plant.
In manufacturing, a remote maintenance session can satisfy every visible security requirement and still expose equipment beyond the scope of the repair. An OEM technician may authenticate successfully, pass multifactor authentication and enter through an approved gateway, only to reach an engineering workstation that retains a route to unrelated controllers. The user is authorized, but the path that user can actually travel may not be, and it is in that gap that Zero Trust turns into a practical engineering problem instead of an authentication slogan.
The problem often grows out of decisions that made sense at the time. Production teams create temporary connections to commission equipment, restore a failed line or support an older machine; service accounts receive privileges needed to keep specialized applications running. When nobody revisits those decisions, the exceptions quietly settle into ordinary infrastructure, which is why my own access and segmentation reviews spend less time on who was approved to connect than on whether every remaining permission is still necessary for the work and safe for the process.
Colonial Pipeline remains one of the clearest public examples. In his June 2021 testimony to the U.S. Senate, CEO Joseph Blount said the company believed the attacker had exploited “a legacy virtual private network (VPN) profile that was not intended to be in use.” At the same hearing, he acknowledged that the profile relied on single-factor authentication, even though its password was complex. No clever exploit was involved; the attacker used access that should have been removed well before the attack. And although the ransomware hit Colonial’s IT network, the company shut down pipeline operations as a precaution, a reminder that an incident can have OT consequences without an attacker ever touching a controller.
NIST SP 800-207 describes Zero Trust as avoiding implicit trust based solely on network location or asset ownership, and in an industrial setting that principle has to be translated into concrete decisions about engineering workstations, service identities, controller communications and operational consequence.
A Support Call at 2:13 a.m.
Consider a fictional composite scenario drawn from common manufacturing conditions. At 2:13 a.m., a packaging line stops after an intermittent drive fault, so the operations team opens a support ticket and approves an OEM technician to troubleshoot. The technician authenticates with MFA and connects through the approved remote-access platform to a designated engineering workstation, where the session is recorded against a ticket that names the affected line.
Approval and authentication have both worked as designed, but the ticket says nothing about a six-month-old commissioning exception that still allows the engineering workstation to communicate with a controller on a neighboring line. The same workstation runs a utility using a broadly privileged service identity, so a session limited at the remote-access gateway may still have more capability once it reaches the plant network.
This arrangement creates exposure even when the technician does everything right: if the laptop were compromised, a diagnostic file were malicious or the workstation session were hijacked, an attacker could potentially use an already-permitted route to reach equipment outside the approved repair. Authentication identifies the person entering the environment; it does not, by itself, establish that every reachable controller belongs to the maintenance task.
Repeating MFA would not resolve the underlying issue because different parts of the access chain enforce different boundaries. The gateway validates the user and session, while the engineering workstation determines which tools and credentials are available; network controls govern reachable destinations, and some controllers have little awareness of the original ticket. Effective safeguards therefore compare actual reach with the approved target and apply task-specific destination restrictions, protocol-aware controls, time-bound authorization and reviewed workstation privileges. Alerts should also flag engineering activity outside the approved boundary. Where an application genuinely requires wider access, that exception needs a named owner, a documented purpose and a recurring validation process.
Why a VLAN Diagram is Not Proof of Segmentation
The Purdue Model is useful for describing industrial layers, and ISA/IEC 62443 asks teams to group assets into zones and connect them through conduits with defined security requirements. (The ISA Global Cybersecurity Alliance’s quick start guide is a good primer.) Neither framework makes a plant secure just because the boxes are drawn correctly. A VLAN separates broadcast domains without enforcing a security boundary on its own, and while a firewall rule can enforce one, a broad allow rule can just as easily undermine it. NIST’s Guide to OT Security (SP 800-82 Rev. 3) treats network architecture as one layer of defense in depth, not a substitute for access control and monitoring.
I start segmentation design with the production process rather than the switch configuration. Which PLCs exchange control data? Which HMIs and engineering workstations need to reach them? Which historians, MES applications, recipe servers and quality systems cross production zones? What traffic is essential during startup, steady-state production, maintenance and recovery? A rule that looks unnecessary during normal operations may support a safety-reviewed maintenance procedure, while the rule beside it may exist only because nobody went back after commissioning. In my experience reviewing firewall change requests, justifying a new rule is usually the easy part of the conversation; the harder part is establishing whether the old rules are still justified.
A practical design documents each permitted conduit with its source, destination, protocol, direction, purpose, owner and review trigger. It favors narrowly scoped flows between defined assets over open subnet-to-subnet access, and it tests how traffic behaves when a dependency fails. For legacy protocols that cannot support modern authentication or encryption, compensating controls at the network and access layers carry more of the weight.
Segmentation should shrink the blast radius of a compromised workstation without causing an outage through an untested change. That means observing real traffic, involving controls engineering, testing rules during approved windows and having a rollback plan. A policy that blocks a needed industrial protocol may look strict on paper and still be operationally unsafe.
The Identities That MFA Does Not Solve
Human authentication addresses only one part of the OT identity problem. Engineering applications frequently depend on service accounts, data collectors use machine identities, and some OEM utilities require local administrator privileges. Older controllers may rely on fixed credentials or lack any practical integration with centralized identity management. Removing all standing privilege is therefore not an immediate configuration change; it requires an understanding of vendor supportability, operational dependencies and the consequences of modifying an established control system.
For each critical identity, teams should know what it authenticates to, where the credential is stored, whether it is shared, who can use it and what breaks if it changes. Where the system supports it, use individual named access, credential vaulting, controlled elevation and rotation. Where a vendor-certified system cannot tolerate a change, restrict what it can reach, harden the host, monitor its use and document the residual risk along with a next review date.
What matters is whether an unavoidable legacy exception is understood and managed: a service identity that cannot be modernized can still be restricted, monitored and reviewed, whereas an account with unexplained privileges and no accountable owner remains an unmanaged trust relationship.
Secure Remote Access Must be Narrower Than the Support Relationship
Manufacturers often rely on specialized suppliers because the OEM may have the deepest knowledge of a machine’s controls and diagnostic tools. Remote support is consequently an operational requirement for many facilities, but a trusted commercial relationship should not translate into unrestricted technical access. Each support session needs a scope defined by the maintenance task, not by everything the supplier might conceivably need to reach.
Exposed or weakly protected access is still being exploited; in late 2023, CISA reported that attackers had compromised a Unitronics PLC at a U.S. water facility, likely by taking advantage of weak password security and exposure to the internet; the utility took the system offline and moved to manual operations. CISA’s recommendations read like a checklist for this section: change default passwords, take PLCs off the open internet, require MFA for all remote access to the OT network and allow connections only from approved IP addresses.
A mature workflow ties a named person to a specific task, an approved target and a bounded time window. The access path should never expose controllers directly to the internet; instead, it should run through a managed intermediary where appropriate and keep vendor traffic separate from unrelated plant systems. Sessions should be attributable, and access should expire or be revoked when the work ends. Session recording helps investigations, but it cannot replace destination-level restrictions or detection of unusual engineering activity.
The design also has to account for the technician’s tools, since some industrial engineering protocols rely on discovery, broadcast or multiple ports and may not work through a simple single-port proxy. When troubleshooting gets hard, that is when people start bypassing the remote-access architecture, so validate vendor tooling in a test environment and provide controlled alternatives, such as a narrowly scoped engineering jump host, ahead of time. The tools themselves are part of the attack surface: joint guidance from CISA, NSA, FBI and partners warns that threat actors increasingly co-opt legitimate remote access software to get into victim systems.
Detection Has to Understand Engineering Behavior
In the fictional packaging-line scenario, a large volume of routine network traffic may be less significant than a single engineering connection to a controller on the wrong line. Unexpected program downloads, controller mode changes or connections from unfamiliar engineering hosts can be stronger indicators of concern than generic traffic spikes, provided they are interpreted alongside maintenance approvals and normal process behavior.
The TRITON incident shows why this matters. In the 2017 attack analyzed by Mandiant, the attacker gained remote access to a safety instrumented system (SIS) engineering workstation and used a tool disguised as legitimate Triconex software to reprogram safety controllers. Some controllers then tripped into a safe state and shut the process down, which is what prompted the investigation; Mandiant assessed that the shutdown was probably unintended. One of its recommendations was deliberately low-tech: Triconex keys should not be left in PROGRAM mode outside scheduled programming events. A controller sitting in program mode at 3 a.m. with no change ticket is exactly the kind of signal OT monitoring should raise.
To interpret those events, security teams need asset and process context: the controller’s line, its function, its expected engineering relationships, the maintenance window, the authorized change record and its operational criticality. Passive network visibility can identify communications and some protocol-level actions, but it will not always tell you whether a logic change was authorized. Correlating network observations with workstation logs, remote-access records, change tickets and controller audit capabilities, where they exist, gives a much stronger picture.
Response has to be designed with operations too, because automatically isolating a PLC may interrupt a process or affect safety. Agree in advance who can terminate a vendor session, disconnect an engineering workstation, block a conduit or stop a production asset, and under what conditions. The first of the Principles of OT Cyber Security, published in 2024 by Australia’s cyber security centre with CISA, NSA, FBI and international partners, is simply “safety is paramount,” and no unreviewed automated containment action should outrank it.
Recovery is the Last Trust Boundary
Consider the recovery question after investigators suspect that a controller program may have been altered. A backup file is available, but its version history is uncertain: the team cannot immediately establish whether it predates the latest recipe adjustment, matches the installed firmware or includes the parameters required to restart safely. Without a tested restoration procedure, possession of that file offers less assurance than the organization may assume.
A backup file proves that a copy exists, but it says nothing about whether the asset can actually be recovered. When ransomware hit Norsk Hydro in March 2019, several business areas kept producing through what the company later described as “work-intensive workarounds and manual procedures,” while encrypted PCs and servers were rebuilt from backups. Hydro’s extruded products business took the heaviest operational and financial hit. The backups existed and were used, yet the recovery still leaned on people, procedures and rebuild capacity as heavily as on the files themselves.
For production-critical assets, engineering and security should agree on approved baselines, change-linked backups, protected storage, version compatibility, restoration responsibilities and periodic tests. Recovery exercises should cover commissioning steps, vendor involvement, spare hardware and the safe sequence for bringing a line back into service. Even CISA’s Unitronics alert tells owners to back up PLC logic and configurations and to practice redeploying them.
Recovery therefore belongs in the Zero Trust discussion because it exposes another form of implicit confidence: the assumption that a known-good industrial state can be restored without having demonstrated the process. Testing that assumption requires engineering ownership, compatible backups and a safe sequence for returning equipment to production.
A Practical Hidden-trust Review for Manufacturing Leaders
For a manufacturing organization with multiple sites, I would begin with one production-critical workflow rather than attempting to redesign every segment at once. OEM remote maintenance of a packaging line is a useful starting point because it brings together identity, engineering workstations, network conduits, controller behavior and recovery. Cybersecurity, controls engineering, plant operations and the asset owner should examine the workflow together, with the shared objective of reducing unnecessary reach without compromising safe production.
First, map the actual access chain: person or service identity, source device, remote-access entry point, intermediary host, network conduit, engineering application and target asset. Then compare what is actually reachable with the approved work. Second, challenge each inherited permission by asking why it is needed, who owns it, when it was last used and what would happen if it were removed. Third, validate detection by checking whether the team would notice an engineering connection to the wrong controller or a programming action outside the ticket. Fourth, walk through the response and recovery decisions with the people responsible for keeping production safe.
Prioritize findings by exposure and consequence, not just by open ports or vulnerability scores. A broad path to a production-critical controller with weak recovery assurance may deserve attention ahead of a high-severity vulnerability on an isolated, low-impact device.
The review also has to be repeatable, because a new machine, a changed vendor contract, a plant expansion or a cloud integration can each create new trust assumptions; every material change should trigger a fresh look at access scope, operational dependencies and ownership. This is the Govern function of NIST CSF 2.0 applied where it matters most: the point where architecture meets production.
Measuring Whether Trust is Actually Shrinking
Leaders need evidence that access is becoming narrower and recovery more dependable. A useful scorecard can track the share of vendor sessions limited to approved destinations; the number and age of temporary conduits still open past their review date; the proportion of critical service identities with a named owner; the share of high-consequence engineering actions correlated with approved change records; and the percentage of critical controller configurations successfully restored in a controlled test.
I would treat these as starting points rather than universal benchmarks, so establish a baseline by site and process, define what counts as a completed review or successful restore, and examine exceptions with engineering before setting targets. A lower count of firewall rules is not automatically safer if essential production traffic was blocked; the meaningful outcome is less unnecessary reach with no unacceptable impact on safety or availability.
What Zero Trust Should Mean on the Factory Floor
Industrial environments will continue to contain older equipment, narrow shutdown windows, specialized vendors and exceptions that cannot simply be eliminated. A workable Zero Trust program acknowledges these constraints and makes the remaining trust relationships explicit, limited, observable and subject to review. The goal is to make sure necessary access does not silently expand beyond its operational purpose, including on devices that will never support modern identity controls.
For manufacturing leaders, the number of deployed Zero Trust products is a weak substitute for evidence of reduced exposure. More useful questions are whether an approved support session could reach another production zone, whether unexpected engineering activity would be detected and whether operations could contain an incident and recover safely. The answers depend on actual access paths, tested procedures and accountable owners, and a deployment dashboard shows very little of that.
In manufacturing, the most consequential trust relationship may be one that was approved for a legitimate reason years ago and has not been challenged since.
References and Further Reading
Australian Signals Directorate’s Australian Cyber Security Centre, Cybersecurity and Infrastructure Security Agency, et al. (2024, October 1). Principles of operational technology cyber security. Australian Cyber Security Centre. https://www.cyber.gov.au/about-us/view-all-content/publications/principles-operational-technology-cyber-security
Blount, J. (2021, June 8). Testimony of Joseph Blount, President and CEO, Colonial Pipeline Company, before the U.S. Senate Committee on Homeland Security and Governmental Affairs. https://www.hsgac.senate.gov/wp-content/uploads/imo/media/doc/Testimony-Blount-2021-06-08.pdf
Cybersecurity and Infrastructure Security Agency. (2023, November 28). Exploitation of Unitronics PLCs used in water and wastewater systems. CISA. https://www.cisa.gov/news-events/alerts/2023/11/28/exploitation-unitronics-plcs-used-water-and-wastewater-systems
Cybersecurity and Infrastructure Security Agency, National Security Agency, Federal Bureau of Investigation, MS-ISAC, & Israel National Cyber Directorate. (2023, June 6). Guide to securing remote access software. CISA. https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software
Dark Reading. (2021, June 9). Colonial Pipeline CEO: Ransomware attack started via pilfered “legacy” VPN account. Dark Reading. https://www.darkreading.com/cyberattacks-data-breaches/colonial-pipeline-ceo-ransomware-attack-started-via-pilfered-legacy-vpn-account
Hydro. (n.d.). 2019 cyber attack on Hydro. Norsk Hydro. https://www.hydro.com/en/global/about-hydro/company-history/2018-present/2019-cyber-attack-on-hydro/
International Society of Automation. (n.d.). ISA/IEC 62443 series of standards. ISA. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
ISA Global Cybersecurity Alliance. (2020, June). Quick start guide: An overview of ISA/IEC 62443 standards. International Society of Automation. https://gca.isa.org/hubfs/ISAGCA%20Quick%20Start%20Guide%20FINAL.pdf
Johnson, B., Caban, D., Krotofil, M., Scali, D., Brubaker, N., & Glyer, C. (2017, December 14). Attackers deploy new ICS attack framework “TRITON” and cause operational disruption to critical infrastructure. Mandiant. https://cloud.google.com/blog/topics/threat-intelligence/attackers-deploy-new-ics-attack-framework-triton
MITRE. (n.d.). Program Download (T0843). MITRE ATT&CK for ICS. https://attack.mitre.org/techniques/T0843/
National Institute of Standards and Technology. (2024, February 26). The NIST Cybersecurity Framework (CSF) 2.0. NIST. https://www.nist.gov/cyberframework
Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020, August). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/207/final
Stouffer, K., Pease, M., Tang, C., Zimmerman, T., Pillitteri, V., Lightman, S., Hahn, A., Saravia, S., Sherule, A., & Thompson, M. (2023, September). Guide to operational technology (OT) security (NIST Special Publication 800-82 Rev. 3). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/82/r3/final
This article was created using AI assistance. The topic selection, technical positions, recommendations and field experience are that of the author.