In the world of IT cyber security, Zero Trust architecture has become the new gold standard. The idea is simple but revolutionary: we are abandoning the outdated “castle and moat” model, in which we trusted everything inside the network. Instead, we are adopting a new, paranoid motto: “never trust, always verify.” Any attempt to access a resource, regardless of its origin, must be treated as potentially hostile and subjected to strict verification. This approach works well in dynamic, cloud-based enterprise environments.
However, when we try to transfer this concept to the production floor, we run into a formidable wall. How do we “always verify” the identity of a PLC whose software was developed when the Internet was a novelty? How do we require strong authentication from a device that struggles to handle basic network traffic? Does this mean that Zero Trust is just an unrealistic marketing buzzword in the world of operational technology (OT)?
The answer is no. Zero Trust in the factory is not only possible, but necessary. However, it requires adaptation and a change in thinking. Instead of trying to forcefully teach old devices new tricks, we need to transfer intelligence and verification mechanisms from the end devices themselves to the network around them. It is the network that becomes the intelligent gatekeeper that surrounds each critical device with a “security bubble,” enforcing zero-trust rules on its behalf.
Shortcuts
- What is Zero Trust and why is it revolutionizing cyber security thinking?
- Why has the “castle and moat” model ceased to be effective in protecting modern factories?
- What are the biggest obstacles to implementing Zero Trust in the world of operational technology?
- Why doesn’t the PLC inherently trust anyone, but at the same time can’t verify anyone?
- How do I move the verification point from the end device to the network itself?
- Step One: How do you define who and what should have access to critical resources?
- Step Two: What is microsegmentation and how does it create “security bubbles” around machines?
- Step Three: What role do modern firewalls and NAC systems play in enforcing Zero Trust policies?
- Adapting Zero Trust for OT environments
- What does secure service technician access to the controller look like in practice in the Zero Trust model?
- How does Zero Trust complement and enhance the philosophy of the Purdue Model?
- Why is continuous monitoring and analysis essential to maintaining a Zero Trust architecture?
- Beyond security, what are the benefits of implementing Zero Trust in a production environment?
- Is Zero Trust at the factory a viable strategy or just a marketing slogan?
- How does nFlo design and implement Zero Trust architecture in production environments?
What is Zero Trust and why is it revolutionizing cyber security thinking?
Zero Trust is a strategic approach to cyber security that is based on the premise that threats exist both outside and inside traditional network boundaries. It rejects the concept of a trusted “inside” and an untrusted “outside.” Instead, any attempt to access data or applications is treated as if it came from an untrusted network. Trust is never implicit and must be openly and continuously verified.
This revolution in thinking involves moving from the question “Is this user on our network?” to a series of much more specific questions: “Who exactly is this user? What device is he or she trying to connect from? Is this device secure? Does this user have permission to access this particular resource? Is his behavior typical?” Access is granted dynamically, session by session, on a minimum necessary privileges basis.
In practice, the Zero Trust architecture is based on three pillars: explicit verification (always authenticate and authorize), access on a minimum privilege basis (give access only to what is necessary and only for as long as necessary), and the assumption of a breach (design the system to minimize the impact of a possible intrusion). It’s a comprehensive philosophy that changes the entire approach to security design and enforcement.
📚 Read the complete guide: IAM / Zero Trust: Zarządzanie tożsamością i dostępem - od podstaw do Zero Trust
Why has the “castle and moat” model ceased to be effective in protecting modern factories?
Traditional network security, known as the castle-and-moat model, was based on a simple concept. We built a single, powerful line of defense around the perimeter of our network (a moat with a firewall), and everything inside (the castle) was considered safe and trustworthy. The director’s computer could communicate freely with the file server, since both were inside the “secure” walls.
This model was sufficient in the days when network boundaries were clearly defined. Today, those boundaries have completely blurred. Remote work, mobile devices, cloud services and, most importantly in the industrial context, IT/OT convergence and the Industrial Internet of Things (IIoT), have made the “moat” as hollow as a sieve. Attackers have dozens of ways to bypass perimeter defenses and get in.
Once the attacker is inside a traditional “trusted” network, his options are almost unlimited. He can move freely between systems (lateral movement) because internal controls are weak or nonexistent. In a flat OT network, compromising a single, poorly secured IIoT sensor can open the way for attacks on the most critical PLCs. The “castle and moat” model in the modern factory is an illusion that gives a false sense of security.
What are the biggest obstacles to implementing Zero Trust in the world of operational technology?
Attempting to directly implement Zero Trust principles, as is done in IT, faces fundamental obstacles in the OT environment. The main problem is the nature of the devices themselves. IT systems, such as laptops and servers, are all-purpose computers with modern operating systems on which security agents can be easily installed and which natively support advanced authentication protocols.
OT devices, especially those at the lower levels of the Purdue Model, are a different story. PLCs, remote I/O modules or simple sensors are embedded systems with very limited computing resources. They are designed to perform one specific task reliably for 20 years. They do not have the computing power to handle complex encryption, and their firmware does not provide for the installation of any additional agents.
What’s more, communication in OT networks is often based on old, simple protocols (such as Modbus) that have no built-in authentication or authorization mechanisms at all. Any device that can “speak” in the Modbus protocol can send a command to a controller and the controller will execute it, trusting it unconditionally. Requiring such a controller to “always verify” the identity of the sender is simply technically impossible without completely replacing it.
Why doesn’t the PLC inherently trust anyone, but at the same time can’t verify anyone?
This is the paradox that lies at the heart of the Zero Trust challenge in OT. On the one hand, a PLC is an extremely “untrusting” device in an operational sense. It will only execute commands that are consistent with the program and logic uploaded to it. It cannot be forced to perform an operation that its programmer did not anticipate. It is a form of built-in, rigid trust based on the program’s logic.
On the other hand, the PLC is completely “naive” in the network sense. It has no mechanism to verify where a command comes from. If it receives a correctly worded “stop the motor” command over the network that conforms to the protocol, it will execute it without asking whether it was sent by an authorized HMI station or by a hacker’s laptop that just connected to the network.
This dichotomy makes the PLC both reliable and extremely vulnerable to attacks. Its security is based solely on the assumption that no unauthorized person can get into the network and send it a malicious but correctly worded command. In a world of interconnected networks, this assumption is no longer true. This is why the identity verification mechanism must be implemented outside the controller.
How do I move the verification point from the end device to the network itself?
Since we can’t install a guard inside the protected facility (PLC), we have to put one right outside its door. This gatekeeper role is taken over by a modern intelligent network. Adapting Zero Trust to the realities of OT involves moving the Policy Enforcement Point (PEP) from the end device itself to the surrounding network infrastructure - usually an industrial firewall or network switch.
In this model, the PLC remains in its simple, unchanged form. However, any attempt to communicate with it is first intercepted and analyzed by a network “guard”. It is this gatekeeper (firewall) that is responsible for implementing Zero Trust policies. It checks the identity of the sender, verifies its permissions and analyzes the content of the command itself before deciding whether to let it pass on to the controller.
With this approach, we can surround old, “dumb” devices from a security perspective with a virtual shield. The controller doesn’t need to be able to verify connections on its own - the network does it for it. This allows us to implement advanced security policies in legacy environments without the need for costly and risky replacement of working infrastructure.
Step One: How do you define who and what should have access to critical resources?
The first step to implementing any Zero Trust strategy is to create a detailed access policy. We need to define precisely who (what users and what devices) should be able to communicate with our critical OT resources. This process starts with inventory and mapping, which we have discussed in previous articles.
We need to identify all the resources (e.g., controllers, HMI panels) and all the “actors” who need access to them (e.g., operators, maintenance engineers, SCADA systems, remote service technicians). Then, for each “actor-asset” pair, we need to determine what type of access is necessary to perform tasks. This is an implementation of the principle of minimum privileges.
For example, a policy might state that: “Operator X, working at HMI station with address A, can only read the status of PLC with address B. Engineer Y, working at the engineering station with address C, can read the status and upload a new program to the same controller. No other communication with that controller is allowed.” Creating such a granular permission map is the foundation on which we will build rules in our network.
Step Two: What is microsegmentation and how does it create “security bubbles” around machines?
Microsegmentation is an evolution of traditional network segmentation. Instead of dividing the network into several large zones (as in the Purdue Model), microsegmentation allows us to create much smaller, more granular security boundaries. In an extreme case, we can create a segment consisting of only one critical device, such as a PLC managing a turbine.
This approach creates a virtual “security bubble” or “Zero Trust Zone” around each important machine or group of machines. Everything inside this bubble can communicate freely with each other (if required), but any attempt to enter or leave the bubble is subjected to rigorous inspection by a network “gatekeeper” (firewall) that enforces a defined access policy.
Thanks to microsegmentation, even if an attacker manages to compromise one device in the factory, the damage is limited to one “bubble.” He won’t be able to attack a controller on Line 1 from an infected HMI on Line 2, because traffic between the two “bubbles” is blocked by default. Microsegmentation is a key tool to implement the “assumption of violation” principle and minimize the impact of an attack.
Step Three: What role do modern firewalls and NAC systems play in enforcing Zero Trust policies?
It’s one thing to define policies and design microsegments, but we still need a mechanism to police it all in real time. This role of enforcer (Policy Enforcement Point) is fulfilled by modern network technologies, such as next-generation industrial firewalls (NGFW) and Network Access Control (NAC) systems.
As mentioned in the previous article, industrial firewalls with deep packet inspection (DPI) can analyze and understand OT protocols. They are the ones that are installed at microsegment boundaries and, based on defined rules, decide whether to let a packet through or block it. They are the ones who verify that the attempted communication complies with the “minimum privilege” policy.
NAC systems go a step further. They can identify and authenticate any device the moment it is connected to the network. If an unknown, unauthorized laptop is connected to a network port, the NAC system can immediately block that port or move the device to a special, isolated quarantine network. The combination of NGFW and NAC allows the creation of a dynamic system that enforces Zero Trust policies both at the level of communication and at the level of access to the network itself.
Adapting Zero Trust for OT environments
PillarTargetKey technologies and processes1. definition of Access PolicyCreate a map of who and what can communicate, based on the principle of minimum authority.Resource inventory, communication mapping, identity management systems (IAM).2. microsegmentationCreate granular safety zones around critical assets to isolate risks.Logical grouping of resources, creation of “security bubbles.”3 Enforcement on the WebMove verification from devices to the network and actively enforce policies in real time.Industrial firewalls (NGFW with DPI), network access control (NAC) systems.
What does secure service technician access to the controller look like in practice in the Zero Trust model?
Imagine the scenario: an external service technician needs to remotely connect to a PLC to diagnose a problem. In a traditional model, he or she would likely be given access to a wide VPN, which would pose a huge risk. In the Zero Trust model, the process looks very different.
First, the service technician must authenticate himself using a strong multi-factor authentication (MFA) method, such as a password and token from the application. His identity is verified by a central identity management system. Then, the system checks the context of his connection - is he connecting from an authorized laptop? Is antivirus enabled on the laptop? Is the connection occurring during a scheduled service window?
If all conditions are met, the central decision brain (Policy Decision Point) dynamically creates a temporary, one-time rule on the firewall. This rule only allows a connection from the service technician’s laptop (specific IP address) to one specific PLC, only using the required protocol (e.g. S7) and only for the duration of the service session. Any attempt to connect to another device or use another protocol is blocked. The entire session is recorded, and when the session ends, the temporary rule is automatically deleted.
How does Zero Trust complement and reinforce the philosophy of the Purdue Model?
Zero Trust and the Purdue Model are not competing, but complementary philosophies. They are an ideal combination of strategic planning and tactical execution. The Purdue Model provides us with a macro-perspective: a strategic map to logically divide the factory into large functional zones (production, supervision, DMZ), based on the criticality of the processes.
Zero Trust provides us with a micro-perspective: a set of tools and principles to precisely and dynamically enforce the boundaries between and within these zones. If Purdue tells us to build a wall between Level 2 and Level 3, then Zero Trust gives us instructions on how to build that wall out of smart, verifying every brick of the barrier, rather than simple, static concrete.
The combination of these two approaches allows us to create an extremely resilient architecture. We have clearly defined, large risk zones (Purdue), and within them we create even smaller “security bubbles” around key machines (microsegmentation). The whole thing is managed by dynamic access policies that verify every communication attempt (Zero Trust). This is the essence of modern deep defense (defense-in-depth).
Why is continuous monitoring and analysis essential to maintaining a Zero Trust architecture?
Implementing Zero Trust architecture is not a one-time project, but an ongoing process. Production environments are dynamic - new machines are added, processes change, and communication requirements change with them. Therefore, a key element in maintaining the effectiveness of the Zero Trust model is continuous monitoring and analysis.
All decisions made by policy enforcement systems (firewalls, NAC) must be logged in detail. These logs, which contain information about all connection attempts - both successful and blocked - should be centrally collected and analyzed by SIEM (Security Information and Event Management) systems. This makes it possible to detect anomalies and potential attack attempts.
Regular analysis of logs and communication patterns is also essential for adjusting and optimizing security policies. If we notice that any legitimate communications are regularly blocked, it means that our policy is too restrictive and needs to be adjusted. Conversely, if we notice unexpected but permitted communications, this could be a signal to tighten the rules further. Zero Trust requires constant visibility and a willingness to adapt.
Beyond security, what are the benefits of implementing Zero Trust in a production environment?
The main goal of Zero Trust is, of course, to dramatically improve cyber security. However, the process of implementing this architecture brings a number of additional valuable benefits that have a positive impact on the entire organization. First and foremost, it forces you to organize and gain a deep understanding of your own infrastructure.
In order to define access policies, we must first carefully inventory our resources and map all communication dependencies. This process often gives engineers for the first time a complete and accurate picture of how their network really works. This knowledge is invaluable for diagnosing problems, planning upgrades or assessing the impact of changes.
Implementing Zero Trust also improves flexibility and readiness for future changes. Once we have granular control over access, it is much easier and safer to integrate new technologies such as IIoT devices or cloud platforms. We can deploy them in a dedicated “security bubble” with precisely defined policies, without risking destabilizing the rest of the environment. Zero Trust architecture is not only a shield, but also a foundation for secure and agile digital transformation of the industry.
Is Zero Trust at the factory a viable strategy or just a marketing slogan?
Zero Trust in the factory is undoubtedly a viable and one of the most effective strategies for building digital resilience in modern industry. However, it is not a simple plug-and-play solution that can be bought out of the box. It’s a complex program that requires a change in philosophy, a deep understanding of one’s environment and the strategic deployment of appropriate technologies.
The key to success is to abandon the attempt to blindly copy methods from IT and consciously adapt Zero Trust principles to the unique realities of the OT world. Moving the point of policy enforcement from the end devices to the surrounding network is the foundation that allows even the oldest and simplest controllers to be protected.
Implementing Zero Trust is a journey, not a one-time project. However, it can be started in small, controlled steps - by inventorying and mapping one critical network segment and then surrounding it with the first “security bubble.” Each successive step will increase the level of protection and maturity of the entire organization, transforming a marketing buzzword into a tangible security architecture that works in practice.
How does nFlo design and implement Zero Trust architecture in production environments?
At nFlo, we specialize in adapting cutting-edge security concepts such as Zero Trust to the demanding and unique realities of operational technology. We understand that implementing ZT in a factory is not a task for theoreticians, but for engineers who understand both advanced network mechanisms and the priorities of the production process. Our methodology is based on a pragmatic and evolutionary approach. We start with an in-depth mapping of your environment to understand what needs to communicate with each other and why. Then, together with your team, we design a microsegmentation-based architecture and help you select and implement technologies (such as industrial firewalls or NAC systems) that can enforce policies in a way that is secure for your operations. Our goal is to build an architecture that is not only secure, but also flexible and scalable, providing a solid foundation for further secure digitization of your enterprise.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- Zero Trust — Zero Trust is an IT security model that assumes that no person, device, or…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
- Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
- NIST Cybersecurity Framework — NIST Cybersecurity Framework (NIST CSF) is a set of standards and best…
- Zero-Day Exploit — A zero-day exploit is malicious software that exploits an unknown or recently…
Learn More
Explore related articles in our knowledge base:
- What Is Zero Trust Architecture? Implementation in Large Organizations
- What is ZTNA - Zero Trust Network Access? Definition, Principles, Operation, Protocols, Technologies and Benefits
- Zero Trust in identity management
- Zero Trust in the Factory: Can the
- Zero Trust in practice - how to implement the zero trust model in your organization
Explore Our Services
Need cybersecurity support? Check out:
- Security Audits - comprehensive security assessment
- Penetration Testing - identify vulnerabilities in your infrastructure
- SOC as a Service - 24/7 security monitoring
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
