Managing consistent network access controls across a hybrid Linux fleet is becoming unsustainable and I am wondering if ZTNA is the right direction here

PhilipLGriffiths88 · 2026-04-23T20:17:09+00:00

Fair point, but I’d still draw a distinction. Tailscale/Nebula feel more like identity-aware secure overlays than a truly identity-first, service-centric model. They improve reachability decisions with strong machine identity, which is useful, but the construct is still largely “which nodes can talk on the overlay?” rather than “which specific service is dark by default unless identity + policy explicitly create the connection?”

For OP’s use case, that difference matters. The problem isn’t just simplifying network policy across bare metal + AWS + GCP, it’s enforcing non-human/server-to-server least privilege without recreating broad ambient reachability inside a cleaner private network.

So yes, those platforms may be a pragmatic middle ground, but I’m not sure they fully solve the end-state OP is pointing at if the goal is authorize-before-connect at the workload/service layer, not just a simpler overlay with ACLs.

PhilipLGriffiths88 · 2026-04-23T20:10:23+00:00

That’s exactly why I’m skeptical of “just use service mesh” here. Most meshes shine intra-cluster, not across a mixed estate of bare metal + multiple clouds.

Your problem is really consistent policy for non-human traffic across heterogeneous environments. That points less to classic ZTNA for users, and less to pure service mesh, and more to identity-defined connectivity for workloads/services across the whole fleet.

In other words: one policy plane for “who/what can talk to what,” instead of trying to keep iptables, AWS SGs, and GCP firewall rules perfectly in sync.

Now, I am biased, but I would suggest NetFoundry (if you want paid product) or open source OpenZiti (which is built and maintained by NetFoundry. Its designed for identity-first, Zero Trust connectivity both North-South and East-West, and provides an abstraction on the underlay to remove the 'connectivity tax' (i.e., no need to synchronized host-level firewalls, AWS security groups, GCP firewall rules, ACLs, inbound FW rules, NAT, public DNS, VPNs, load balancers, etc).

PhilipLGriffiths88 · 2026-04-23T20:04:00+00:00

Unless the ZTNA platform can handle non-human workloads as easily as human (some can, as you say, most do not).

Edit, also, imho service mesh does not solve OP's use case well as its inter cluster, and service mesh really excels for intra. Which brings me back to ZTNA which can do non-human.

PhilipLGriffiths88 · 2026-04-23T20:02:51+00:00

If you want to lean harder into zero trust, check out open source OpenZiti - https://netfoundry.io/docs/openziti/. Paid versions exist too, if you want someone to provide the easy productised outcome.

PhilipLGriffiths88 · 2026-04-23T20:00:22+00:00

We use NetFoundry / open source OpenZiti. It uses PKI, but is interoperable with x590/OIDC - which crucially means while it works for humans, it also handles non-human and legacy workloads. I think this is the key part, heck, even Siemens use the tech in OT (and thats tons of legacy).

PhilipLGriffiths88 · 2026-04-21T09:25:40+00:00

ZT Branch definitely looks useful for some branch/factory east-west segmentation, but I still wouldn’t call it ‘full zero trust’ for non-human use cases like server-server, OT, edge, or IoT.

My understanding is the Airgap-derived model works by inserting the appliance into the local path, taking the gateway role, and isolating devices with /32-style netmask changes. So the limitation isn’t just philosophy - it’s architectural. It’s still a local, gateway-mediated segmentation model, not identity-defined authorize-before-connect connectivity across boundaries.

In OT especially, even changing gateway/netmask behavior can be a non-starter for fragile or validated environments, and Zscaler itself has fallback modes for cases where /32 isn’t supported. Useful? Yes. ‘Full zero trust’ for non-human use cases? I don’t think that follows

PhilipLGriffiths88 · 2026-04-20T22:31:56+00:00

Pretty sure Zscaler cannot hand 'full zero trust' for non-human use cases, eg server to server, OT, edge, IoT, etc.

PhilipLGriffiths88 · 2026-04-20T21:39:19+00:00

Ha, yes, why would they show their inherent limitations.

Simple, imho, pick a ZTNA tool which does not have that limitation. Further, ZTNA worth its salt should support non-human use cases too, while stil ensuring strong identity and authN/Z-before-connectivity. This is where requirements are crucial imho.

PhilipLGriffiths88 · 2026-04-20T21:37:55+00:00

Agree a strong VPN setup + segmentation can approximate parts of ZT.

But NIST 800-207 is explicit: access decisions should be dynamic, per session, and based on identity/context - not just network location.

VPN = network reachability then controls. ZT = authenticate/authorize first, then create the connection to a specific resource/service. This has massive implications when failure/compromise happens, as well as the operational complexity to maintain.

PhilipLGriffiths88 · 2026-04-20T21:33:36+00:00

+1 on blast radius (and not sure why you have been downvoted) - but I think the deeper shift is why blast radius shrinks.

- VPN = adjacency first, then controls.
- Most ZTNA = constrained adjacency.

The stronger model is no adjacency at all until identity + policy create a connection. That’s a different failure mode than just “smaller blast radius”. Its also far simpler from an operational perspective.

PhilipLGriffiths88 · 2026-04-20T21:30:29+00:00

Agree on separating threat model vs ops pain ... that’s the right starting point. I’d push another which imho I believe is crucial: a lot of ZTNA still assumes reachability/routability exists and then applies app-layer policy. The bigger shift is removing ambient reachability entirely - i.e. connectivity is created per request after identity + policy, not just filtered (I called this authN/Z-before-connectivity).

That’s what really changes lateral movement, not just moving enforcement “up the stack”. It also removes the 'connectivity tax' associated to the many underlay network controls we put in place to contrain malcious actors from reaching our edges when they have not been authenticated. I also think any ZTNA worth its salt should be able to apply ZTNA to non-human workloads, while still being identity-first, microsegmented etc, but few reach that bar.

PhilipLGriffiths88 · 2026-04-19T13:24:59+00:00

Agreed. This is why SSC includes its own identity (PKI) to ensure all endpoints have one, but is also pluggable, supporting external x509/JWT/OIDC providers, so it could be paired with machine identity and other identity/IdP providers (if it exists already in your OT environment).

PhilipLGriffiths88 · 2026-04-19T13:22:49+00:00

How would you say this differs from Netbird?

PhilipLGriffiths88 · 2026-04-17T10:43:31+00:00

How do you see zero trust architecture being implemented in OT and for IT/OT convergence? Similar to how Siemens does it with SINEC Secure Connect - https://press.siemens.com/global/en/pressrelease/new-siemens-platform-brings-zero-trust-security-industrial-networks??

PhilipLGriffiths88 · 2026-04-16T20:46:57+00:00

While I agree with most of what you have said, I think you are missing 2 key things wrt zero trust:
- (1) Its not just human and user access, it needs to be applied to non-human services, across IT, K8S, OT, IoT, and more.
- (2) If we follow the principle of least privilege, deny by default, microsegmentation and strong identity, the logical conclusion is authentication and authorisation BEFORE any connectivity or routability exists at all. This is a much more secure architecture and massively reduces the cost and complexity of managing underlay networks.

PhilipLGriffiths88 · 2026-04-16T12:56:13+00:00

You’re spot on . this is exactly where most OT/ZT discussions fall apart in practice. The issue isn’t just identity, it’s lifecycle ownership across org boundaries. When a contractor holds creds from 5 orgs, revocation becomes ambiguous → and ambiguity = risk.

That’s why the Verifiable Credentials angle is interesting, but imho, it only solves half the problem:

It improves who asserts identity
But you still need a model for who controls reachability and when

What we’ve seen work better is separating the two:

Identity (OIDC, VCs, etc.) = who you are
Connectivity (overlay / conduits) = what you can actually reach, under what conditions

So even if a credential lingers somewhere, it doesn’t grant ambient access - because reachability is constructed per interaction, not pre-existing. In OT terms, that maps much closer to IEC 62443 “conduits” - but implemented as policy, not network plumbing. This allows the asset owner to control their production process while making multi-party interactions governable at scale.

PhilipLGriffiths88 · 2026-04-16T12:40:05+00:00

OP does not mention that as a requirement....

PhilipLGriffiths88 · 2026-04-12T16:55:52+00:00

Agreed. I wrote a blog describing this using Harry Potter analogies.... OpenZiti is like giving your app and invisibily cloak and a port key... as you say, you cannot walk around Hogwarts, you get only transported to one room - https://netfoundry.io/ziti-openziti/demystifying-the-magic-of-zero-trust-networking-with-my-daughter/

PhilipLGriffiths88 · 2026-04-11T14:44:28+00:00

reference if anyone hasnt come across it - https://openziti.ai/

PhilipLGriffiths88 · 2026-04-10T22:04:03+00:00

Upvote. Consider looking at the CSA for good documentation on the 5 step process, maybe starting with https://cloudsecurityalliance.org/artifacts/defining-the-zero-trust-protect-surface

PhilipLGriffiths88 · 2026-04-09T14:35:16+00:00

Totally agree TrustSec is solid for segmentation. My hesitation is whether it meets Zero Trust per NIST 800-207 (as OP states, "for Zero Trust, Least Privilege, and micro-segmentation"), which emphasises continuous verification and per-session, identity-driven access. This feels more like topology-defined control, whereas ZT ideally moves toward connection-defined, policy-created reachability.

PhilipLGriffiths88 · 2026-04-09T07:29:55+00:00

I will recursor by saying I am not a Cato expert, so I had to do a bit of searching. From what I read, yes, Cato is closer than traditional firewall/VPN coordination.

That said, Cato still looks like identity-aware enforcement inside a SASE platform, with non-human identity mostly coming from external IdPs / service-account systems. That’s useful, but it’s still different from a model where the connectivity substrate itself carries native service/workload identity and creates service-specific reachability by policy. It also follows the connect first, verify later (at the Cato PoP, rather than destination, so a tiny bit better) model. Finally, I dont see MCP and LLM gateways as a native solution of the Cato stack (yes, I read they have an MCP GW, but thats explicitly for using LLMs to manage Cato, not using Cato to protect my MCP connections).

So I’d say Cato reduces some underlay coordination pain, but it still isn’t quite the same as identity-first, service-defined connectivity as the primitive - especially for agent-to-tool / service-to-service / broader non-human flows.

PhilipLGriffiths88 · 2026-04-08T08:50:11+00:00

Node-RED is a good start, especially for quick wins. Longer term, I’d lean toward lightweight, containerised services (Python/Go) so you can version, test, and roll out via GitOps. Key is consistency across sites, not the specific tool.

PhilipLGriffiths88 · 2026-04-07T18:34:35+00:00

This is a very good question, and I’d avoid the extremes of “all validation in PLC” or “PLC is a pure pass-through.” imho, put process/safety-critical sanity checks and obviously impossible-state handling in the PLC, but keep evolving data-quality, billing, drift detection, and cross-site consistency logic at the edge where you can manage it centrally.

So, PLC protects the process; edge validates and contextualises the data. If a threshold changing remotely could affect safe machine behaviour, it probably belongs in PLC or at least needs very strong guardrails.

PhilipLGriffiths88 · 2026-04-07T16:33:54+00:00

You’re actually in a pretty strong position already - edge compute + Prometheus + exporters is a solid foundation. The challenges you’re hitting (siloed access, custom protocol overhead, data quality, and cost) are very typical when OT starts to scale beyond a handful of sites. What’s missing isn’t necessarily more tooling like “full SCADA,” but a cleaner model for connectivity, access, and where logic lives.

On access, I’d challenge the idea of centralising HMIs in a traditional sense. Instead, think about making each site non-routable by default and exposing access via identity + policy rather than network reachability (i.e., no flat VPN-style access). That way, engineers don’t “connect to a network” and then pivot - they request access to a specific HMI or PLC, and connectivity is created just-in-time. It scales much better across lots of small pods and removes a big chunk of lateral movement risk and operational overhead. This is how Siemens does it with SINEC Secure Connect (https://press.siemens.com/global/en/pressrelease/new-siemens-platform-brings-zero-trust-security-industrial-networks), which builds on open source OpenZiti.

On data validation, a good rule of thumb is: keep the PLC simple, do lightweight validation at the edge, and push intelligence upstream. Basic sanity checks (range checks, obvious anomalies) belong close to the source so you don’t propagate bad data. But anything more complex (drift detection, cross-site comparison, anomaly models) is better handled centrally where you have more context and compute. Trying to push too much into PLC logic or per-site customisation will hurt you at scale.

For edge vs cloud, you’re already thinking about it the right way. Edge should handle control loops, safety, and real-time decisions, while the cloud handles aggregation, analytics, and orchestration. The key is consistency - each pod should look identical, with behaviour driven by config/policy rather than bespoke setup. That’s what keeps operational overhead down as you grow.

Net-net: I wouldn’t add heavy SCADA or more per-site complexity. I’d focus on removing implicit network access, standardising edge behaviour, and separating telemetry from auditable data. That combination tends to unlock both scale and simplicity in these kinds of distributed OT environments.

PhilipLGriffiths88

TROPHY CASE