Introduction:
Enterprises in the OT and IIoT sectors are increasingly adopting identity-based, secure private zero trust networking. A foundational element in this journey is the implementation of least privilege access and microsegmentation to achieve granular access control. This requires that all communicating entities—whether users, devices, or applications—be assigned unique identities. However, a significant challenge arises when dealing with machines that are unable to support the installation of software clients or tunneling agents that enforce identity-based access.
As we have engaged closely with our customers, a common need has emerged: a solution to extend zero trust access to non-identity-aware machines. These are typically legacy or specialized OT devices that cannot host identity clients yet still require secure, policy-driven communication. Addressing this need is essential to achieving comprehensive zero trust coverage across heterogeneous environments.
What is it?
Before diving into implementation details, let’s first understand the concept. In industrial environments, edge or industrial compute devices typically serve as network gateways, connecting to machines such as PLCs, sensors, actuators, and other OT assets. These gateways generally run a standard operating system and possess sufficient compute resources to host NetFoundry edge software.
In this architecture, the gateway acts as the identity-bearing entity—running the NetFoundry tunneler/router—while the connected machines communicate with cloud services, applications, and other machines through the identity of the gateway. The core objective is to implement a mechanism that controls and restricts which specific machines behind the gateway can access designated resources, even though they themselves may not have individual identities or tunneling capabilities. This enables enforcement of zero trust principles such as least privilege and segmentation, even for non-identity-aware devices.
Scenario:
The following are the communication objectives we want to achieve:
- At factory site 1, only specific machines in Subnet A ( a /24 subnet) connected to the upstream IEC device running the NetFoundry tunneler with identity A should connect to cloud
- At factory site 1, only specifc machines in Subnet B ( a /23 subnet) connected to the upstream IEC device running the NetFoundry tunneler with identity B should connect to the DC
- From factory site 2, only spefic machines in subnet G ( a /21 subnet) connected to the upstream IEC device running the NetFoundry tunneler with identity G should connect to machines in subnet C at factory site 1
As part of the NetFoundry “Service Config”, access is restricted to a spefic port(s) and IP(s) / host name(s) and specific identities are allowed to access based on the “Service Policy Config”.
For example, machines connected to the IEC device that runs Identity A can be allowed to access a SCADA application in the cloud through appropriate service and policy configurations. However, this identity-based model alone does not prevent unauthorized machines within Subnet A from reaching the SCADA service.
Introducing “Allowed Source Address”
To address this requirement, NetFoundry introduces the Allowed Source Address feature within the service configuration. This enhancement enables administrators to enforce access control beyond the identity level, down to the level of specific source IP addresses of individual machines behind the tunneler or a router.
With this feature:
- The NetFoundry platform inspects the originating IP address of traffic from machines behind the IEC gateway.
- Access is granted only if the source IP matches the list defined in the service configuration.
- Machines not listed—even if they route traffic through an authorized IEC device—are denied access.
This capability allows organizations to maintain the IEC gateway model, while still enforcing machine-level access policies, ensuring that only explicitly permitted devices within a subnet can access critical applications or services.
How to use the “Allowed Source Address” feature:
Let’s replicate this scenario in a lab environment. The objective is to restrict access to an “Extended Zero Trust Service”—which hosts a simple “Hello World” application on AWS—to a specific IP address: 10.0.0.5.
Once the configuration is complete, the service should only be accessible from the IP address 10.0.0.5, regardless of whether other identities are permitted by the service policy configuration. Any requests originating from other IP addresses should be denied, even if the identity is authorized by policy.
The service config with allowed source address of 10.0.0.5:
Service Policy Config that allows access to three identities, one that of a router identity and two other identities.
10.0.0.5 is a VM in Azure deployed behind the identity – ” Customer hosted edge router in Azure London”. The service should only be reachable from that VM and not reachable from our identities “………..001” and “…………002” whose IPs are not added to the allowed source address list.
Trying to access the service from the identity “NetFoundry Cloud Identity 002” ( does not match the source IP of 10.0.0.5)
The identity has access to the service as per policy but can’t access since the IP is not added to the list:
Successfull access from 10.0.0.5:
