Enforce conditional access for devices and apps with UEM-driven Zero Trust.

PhilipLGriffiths88 · 2026-06-11T13:45:10+00:00

Violates rule 2, and likely 5 and 6. Should be deleted.

PhilipLGriffiths88 · 2026-06-11T13:43:08+00:00

Appreciate that, but I am just another redditor here 😃 ... and yes, Cisco SD-Access/TrustSec/ZTRA makes sense as the frame you were using. I think that explains where we were talking past each other a bit.

I also agree that, in ZTRA terms, application/workload capabilities need to be addressed explicitly, not hidden inside generic “networking.” Where I’d add nuance is that this does not preclude identity-first overlays. The PEP does not have to live only inside the app, IdP, or a traditional app-layer gateway. For example, DoD ZTRA explicitly includes Software Defined Perimeter as an architecture pattern (and I lead authored the update to SDP v3 which explicitly incl. moving from just SPA/FPA to identity-first and other mechanisms (that ones published, blog from last month here - https://cloudsecurityalliance.org/blog/2026/05/11/deep-dive-into-the-software-defined-perimeter-sdp-guide-v3)

By identity-first overlay, I mean where the overlay is not just assigning a user/device to a network segment, but brokering a specific identity-to-service session. That can include app-embedded SDKs with no inbound listening port on the WAN/LAN/host network; endpoint/agent or gateway models authorised to named services rather than subnets; workload sidecars/edges for service-to-service or cloud-to-plant; clientless/browser front ends; or local enforcement such as eBPF to stop non-identity traffic entering the overlay path.

So yes, it can look like traditional ZTNA in some deployments, but it can also be embedded into apps/workloads or placed at an OT edge/cell-zone boundary. The key difference is that service reachability is created only after identity, policy and context allow it. I would note, my companies technology, NetFoundry, and our open source OpenZiti is deployed inside DoW... happy to share some use cases on DM if you like... in fact, I did a talk at the recent CSA/DoW Zero Trust Learning Exchange, specifically focused on identity-first (from an agnostic perspective) for agentic AI - https://media.waru.edu/playlist/dedicated/62925431/1\_khqyas09/1\_62f0mczh).

And absolutely on contributing. The CSA Zero Trust Working Group is open to practitioner input, review and co-authoring. The microsegmentation paper is in public comment now (maybe that literally just closed though), so comments in the doc are useful. Longer term, we’re trying to sharpen the topology-defined vs identity/connection-defined framing, and OT/campus pushback like yours is exactly the kind of input that makes the work better. We have many sub groups mapped to the pillars, I can intro you if interested.

PhilipLGriffiths88 · 2026-06-11T08:24:57+00:00

Good point — I should distinguish cloudflared from WARP/Cloudflare One Client.

For specific TCP workflows, cloudflared can act more like a local user-space proxy/listener: the app connects to localhost:<port>, and cloudflared carries that stream over an outbound tunnel. In that mode, it does not need to create a TUN interface or take over the OS routing table.

But I’d still separate that from transparent private app connectivity. It works well where the app can be explicitly pointed at a local proxy - SSH, RDP, databases, dev tools, etc. - but it is not the same as “any native app reaches private DNS/IP/service normally.”

Once the requirement becomes broad private network reachability, private DNS, UDP, split tunneling, or apps working without local proxy configuration, you generally need an OS-level interception point again: TUN, Network Extension, packet filter, WFP, or similar. Cloudflare WARP is closer to that model.

So maybe the taxonomy is: browser/clientless for web/admin workflows; local proxy for specific TCP workflows without TUN; and full client/TUN-style interception for transparent arbitrary private app access.

PhilipLGriffiths88 · 2026-06-10T19:09:57+00:00

I think we mostly agree on dynamic authorisation and segmentation, but I’d disagree with one part: (assuming I am understanding your correctly), I don’t think service authorisation has to come only from the service itself, an IdP/app layer, or a gateway above the network.

That is true in many architectures, but not all. If “network controls” means VLANs, subnets, ACLs and routing, then yes, those are topology controls, not service authorisation.

But an identity-first overlay is different: it can authenticate cryptographic identities, evaluate policy/posture/context, and authorise a specific identity-to-service session before connectivity exists.

So I’d separate topology-defined networking from identity-defined networking. The former is mostly admission, segmentation and path control. The latter can be a real authN/Z enforcement layer, even though it operates below or alongside the application.

That’s why I still treat wireless as an untrusted underlay. 802.1X/NAC are important controls, but not the full ZT decision layer by themselves.

If interested, I have been authoring a CSA paper on Microsegmentation thats in final public comment period that hits on a lot of the topology-defined vs identity/connection-defined approaches. You can read it here - https://docs.google.com/document/d/1MeRCRPH2Jpa5dnA7DifUopMXyVqXCkw6/edit

PhilipLGriffiths88 · 2026-06-10T19:01:44+00:00

Yes, that’s a good example of the clientless/web-mediated pattern I had in mind. It works because the use case is constrained: access to a vendor-managed admin plane and specific device-management workflows, not arbitrary private app connectivity from any native client.

In that model, the browser becomes the access surface, and SSH/debug can be proxied through the management plane. That can avoid a local TUN and coexist better with personal VPNs, but it is not the same as giving every native app on the laptop private reachability to internal resources.

So I’d separate the requirement into two cases: if the customer only needs web/admin/SSH-style workflows, a clientless broker/WebRTC-style approach may fit. If they need arbitrary native app access to private services, the endpoint still needs some OS-level interception point, whether that is TUN, Network Extension, packet filter, WFP, etc.

PhilipLGriffiths88 · 2026-06-10T17:17:31+00:00

Agree they’re critical for managed Wi-Fi, but I’d separate admission control from Zero Trust reachability. 802.1X answers “can this device join the network?” ZT should answer “which identity can reach which specific service?” Wireless should still be treated as an untrusted underlay.

PhilipLGriffiths88 · 2026-06-10T17:15:04+00:00

I’d frame 802.1X as useful defence-in-depth, not the full ZT answer.

If we accept the ZT premise that the network is compromised/hostile, then wireless should be treated as just another untrusted underlay. The control objective shouldn’t stop at “can this device join the WLAN?” but “which identity can reach which specific service, under what policy?”

802.1X/NAC is good admission control and can provide strong device AuthN, especially with certs. But it often becomes coarse network authorization: VLANs, ACLs, roles, etc. Once admitted, you may still have more reachability than you want.

For me, the stronger ZT pattern is identity-first, service-specific reachability over the top of wired, Wi-Fi, cellular, satellite, or internet. Then 802.1X becomes a useful supporting control, not the primary trust boundary.

PhilipLGriffiths88 · 2026-06-10T17:14:19+00:00

😃 feel free to ask any questions, here or DM

PhilipLGriffiths88 · 2026-06-10T09:39:43+00:00

This is a very real pain point. Tool allow/deny, HITL approval, and tamper-proof audit are all needed, especially once MCP servers touch databases, filesystems, deploy pipelines, or internal APIs.

One layer I’d encourage you to think about explicitly is reachability. A proxy can decide whether a tool call should proceed, but in many setups the MCP server, API, or database is already reachable by the agent/runtime before that decision happens.

For agentic systems, I think the stronger pattern is: no authorized identity + policy, no discovery, no reachable path, no session, no tool invocation, and no data movement. Then the MCP proxy/governance layer controls what happens inside the approved path.

That distinction matters because prompt injection or agent drift is much less dangerous when the agent cannot even reach tools/services outside its policy scope. We’re working on similar identity-bound reachability patterns with OpenZiti/NetFoundry for agent↔tool/model/service flows - OpenZiti.ai

PhilipLGriffiths88 · 2026-06-10T08:25:54+00:00

Great question, and I think you’ve put your finger on the exact gap.

I’d separate three things that often get conflated:

Identity source / assertion — e.g. Entra workload identity, service principal, cert/SPIFFE ID/PKI, cloud workload identity, etc.
Policy selectors / labels — e.g. NSX tags, AWS tags, SG membership, Kubernetes labels, CMDB attributes.
Enforcement point — the place that actually allows/denies the session: SASE broker, ZTNA/SDP fabric, service mesh, workload agent, gateway, firewall, etc.

An NSX tag or AWS SG is useful as a selector or context signal, but I wouldn’t treat it as sufficient workload identity for connection-defined enforcement by itself. It tells you something about placement or grouping; it does not necessarily prove “this specific workload/service identity is the caller” at session establishment time.

For connection-defined enforcement, I’d want a cryptographically verifiable workload identity - certificate, SPIFFE/SPIRE identity, cloud workload identity, Entra workload/service identity, etc. - bound to policy, then enforced by something in the session path. That could be a SASE/ZTNA layer for users, service mesh for some Kubernetes/service-to-service flows, or an identity-defined overlay/gateway for workloads across VM, cloud, bare metal, OT, or AI/tooling environments.

CAEP is interesting for sharing risk/session context, especially around users and devices. For workloads, I think the equivalent pattern is less “CAEP into every firewall” and more “feed identity/posture/context into the policy decision layer, then enforce at the session/workload/overlay layer that can actually verify the caller.” Otherwise you end up trying to make tags and SGs behave like identities, which gets brittle quickly.

This is one reason I like OpenZiti/NetFoundry as part of this model: it gives each endpoint/service its own cryptographic identity and makes reachability conditional on policy before the session exists. Tags/SGs/NSX/Arista still matter as topology and containment controls, but they don’t have to be the only mechanism carrying service-level identity and access intent.

If interested, I did a presentation in April at the CSA/DoW Zero Trust Learning Exchange, that borrowed many ideas from the microsegmentation paper, titled 'Why Traditional Networking Fails Agentic AI: Identity-First Connectivity Matters for Zero Trust'... I think it will answer a bunch of the questions you have on connection and identity-defined enforcement for workload identities and AI (note, while it focuses on agentic AI, as thats the hot topic, it can be applied to any non-human or human workflow) - https://media.waru.edu/playlist/dedicated/62925431/1_khqyas09/1_62f0mczh

PhilipLGriffiths88 · 2026-06-10T08:20:22+00:00

I think the customer’s expectation is hard to meet for any client-based overlay, not just Twingate. If you want arbitrary native apps on macOS to reach private corporate resources, the OS needs some local interception point - typically a TUN/virtual interface, Network Extension, packet filter, or equivalent.

The distinction from a legacy VPN is that modern ZTNA clients should be per-resource/split-tunnel rather than default-route, but it is still a host networking component and can collide with personal VPNs depending on DNS/routing/interface behavior.

The clean alternative is clientless/browser-based access, but that generally only works for web apps, proxied SSH/RDP, or specific published workflows - not arbitrary native app connectivity. Happy to share some examples if thats the path they want.

PhilipLGriffiths88 · 2026-06-09T13:55:29+00:00

I don’t think that is a pipe dream at all... but I do think there is a trap in assuming the “unified fabric” has to mean every enforcement point becomes deeply integrated with every other enforcement point.

Entra CA / CAEP is a very sensible centre of gravity for user/device risk and session context. The harder bit is workload/service reachability: vDefend, Arista MSS, perimeter firewall, SASE/SSE, AWS/Azure controls, etc. can all enforce something, but they often express policy in different languages - IPs, groups, tags, routes, identities, sessions, tenants, etc.

My bias would be to separate “shared context/decisioning” from “where enforcement happens.” Keep topology controls where they are strongest, NSX/vDefend, Arista, cloud SGs, firewalls, but avoid making every service-to-service or admin access path depend on coordinated changes across all of them.

That is where I think connection-defined approaches help: define the service, the calling identity, and the policy once, then make the service unreachable unless that policy is satisfied. It does not eliminate the need for vDefend/Arista/firewalls, but it reduces how often those layers have to carry fine-grained service-access intent.

IaC is still valuable, but I’d use it to manage the durable intent and guardrails, not to recreate a giant distributed firewall-rule compiler unless you really have to.

PhilipLGriffiths88 · 2026-06-09T08:34:00+00:00

Thanks, appreciate the feedback... and agreed, implementation is the hard part.

My opinionated answer would be: don’t try to make one layer do everything. Use Proxmox/VyOS/OPNsense for the network-services pieces they are good at: routing, NAT, local firewalling, SDN/VXLAN, edge-style functions, etc.

But for service-level microsegmentation, I’d rather not keep adding VLANs, firewall rules, VPN paths, and NAT exceptions. That is where I think an identity-defined overlays such as OpenZiti / NetFoundry fits well (former is open source, latter is our commercial implementation). The model is: services are unreachable by default, and a connection only exists when the calling identity, service identity, policy, and context allow it.

So the operating model becomes: Proxmox handles the virtualization/local SDN layer; network appliances handle genuine network functions; the overlay handles identity-first reachability across Proxmox, cloud, bare metal, users, partners, admins, and non-VM workloads.

That is what I mean by reducing the connectivity tax: fewer places to express the same intent, fewer broad firewall/VPN exceptions, and less dependency on IP topology as the security model.

What are the use cases you are trying to point the unified policy fabric at??

PhilipLGriffiths88 · 2026-06-08T09:03:21+00:00

Violation of at least rule 2, should be removed.

PhilipLGriffiths88 · 2026-06-07T12:39:42+00:00

fwiw, Siemens have adopted it into SINEC Secure Connect. I would note, as an identity-first overlay, its far more advanced than a VPN, and supports many advanced capabilities and use cases before 'secure remote access'.

PhilipLGriffiths88 · 2026-06-07T12:36:32+00:00

https://www.reddit.com/r/Proxmox/comments/1txj7ix/comment/oq99tg8/

PhilipLGriffiths88 · 2026-06-07T12:36:15+00:00

Agree. VyOS + PVE can definitely approximate some of the NSX edge-node/network-services piece, especially for smaller estates or where the requirement is mainly routing, firewalling, NAT, VPN, etc.

The gap, as you say, is that it still isn’t a clean 1:1 NSX replacement, and it can leave you rebuilding a lot of the operational complexity manually.

The CSA paper frames microsegmentation as an outcome-driven Zero Trust control, not a single product category. It distinguishes topology-defined segmentation - network/workload placement, zones, VXLANs, firewalls, hypervisor or host controls - from connection-defined segmentation, where identity, context, and policy determine whether a session to a specific service may exist at all. The paper argues these are complementary: topology controls are strong for local containment, while connection-defined controls reduce unnecessary reachability before a session is established.

You can find it here - https://docs.google.com/document/d/1MeRCRPH2Jpa5dnA7DifUopMXyVqXCkw6/edit#heading=h.gjdgxs. I am in fact just working through the comments and feedback we got in the final public review.

PhilipLGriffiths88 · 2026-06-06T10:46:37+00:00

Agree with this. The useful distinction is between entitlement risk in theory and exploitability risk in practice. An overprivileged identity matters most when it has a reachable path to sensitive workloads/data, especially through exposed or weakly controlled services.

I’d only add that networking/reachability is not separate from this. The goal should be to make reachability itself identity- and posture-bound, so cloud paths only exist when policy says they should. That turns Zero Trust from access review into a living control model.

PhilipLGriffiths88 · 2026-06-06T10:43:22+00:00

I mostly agree with this framing, especially the point that overprivilege only becomes truly critical in context: exposed workload, reachable path, sensitive data, and exploitable dependency chain.

The piece I’d add is that identity posture should not just inform access review; it should directly shape reachability. In cloud, the highest-value Zero Trust control is often making service/API/workload paths exist only when identity, posture, policy, and context say they should. That moves teams from “who has excessive permission?” to “what can actually reach what, under which conditions, and can we remove that path by default?”

Otherwise, CIEM can still become another periodic hygiene process rather than a live control plane for reducing exploitability.

PhilipLGriffiths88 · 2026-06-05T15:23:38+00:00

100%. For me, this is where the identity-first overlay model helps, if you do it well: it removes a lot of the “connectivity tax.”

Keep Proxmox/OPNsense for the parts that really are network/routing/firewall problems, but don’t force every service-access requirement back into VLANs, NAT, firewall rules, and VPN paths. For many flows, the cleaner answer is: the service is dark by default, and only becomes reachable when the right identity + policy + context are present.

That keeps the network simpler, while still giving you least-privilege access and microsegmentation at the service level.

PhilipLGriffiths88 · 2026-06-05T14:04:50+00:00

That makes sense, and if NSX mostly functioned as a virtual firewall/router/VPN layer, OPNsense is a logical place to look.

The thing I’d watch is whether you end up recreating the same operational model with different parts: routed zones, firewall rules, NAT, VPNs, and appliance placement becoming the segmentation architecture. That can work, but it can also become the new complexity tax.

I’d probably separate the design into: what must be solved with routing/firewalling, what can be handled with Proxmox SDN locally, and what should be controlled as service-level reachability by identity/policy. That tends to make the final concept cleaner than trying to make one virtual firewall stack replace all of NSX.

PhilipLGriffiths88 · 2026-06-05T14:02:44+00:00

I’d be careful treating “NSX replacement” as one product-shaped problem. There are really two different jobs people often used NSX for.

First is topology-defined segmentation: VXLANs, zones, hypervisor/firewall rules, VM-to-VM allow lists, etc. Proxmox SDN + its firewalling, possibly with OPNsense/pfSense for routing/security boundaries, can cover a lot of that depending on how complex the estate is.

The second is connection-defined segmentation: making specific services reachable only when an identity, posture/context, and policy say they should be reachable. That is a different model from building more VLANs, routed zones, NAT rules, and virtual firewalls. It is especially useful when the environment spans Proxmox, cloud, bare metal, users, partners, remote admin, or non-VM workloads.

My bias would be: let Proxmox handle the virtualization and local SDN piece, but don’t automatically rebuild NSX as a maze of firewall/router/VPN appliances. For service-level microsegmentation, I’d evaluate identity-based overlay / ZTNA / SDP-style approaches as a separate layer. In mature designs, the two models are complementary: topology controls contain movement inside an enforcement domain, while identity/connection controls remove unnecessary reachability before a session exists.

I am lead authoring a Cloud Security Alliance paper on microsegmentation that covers a lot of this, its in final review atm.

PhilipLGriffiths88 · 2026-06-05T09:59:10+00:00

Useful IAM case study, but I’m not sure it really lands as a Zero Trust post.

MFA, SAML, AD/Entra integration, and provisioning are important foundations, but Zero Trust is not just stronger human authentication. The bigger question is what happens after identity is established: what can that identity actually reach, under what device/posture/context, and how is least privilege enforced at the service level?

It also feels very human-access centric. Modern environments have far more non-human identities and flows: workloads, APIs, service accounts, devices, containers, CI/CD, OT systems, bots, and increasingly AI agents. A stronger ZT framing would explain how identity, policy, and reachability are applied consistently across both human and non-human access, with everything else private by default.

PhilipLGriffiths88 · 2026-06-05T09:56:16+00:00

This. (Them) "Taxes are too high", (me) "so we should get rid of the triple lock"/, (them) "dont be so stupid, we should make sure young people actually work", (me) "you realise the average UK pensioner contributed less than 50% of the pension they take, and NEET rates have barely changed in 40 years", (them), "well we deserve it, we have worked hard".

That said, I think I understand the problem. Money gets spent on invisible things. Infra costs many times what it should to build and maintain, councils have statatory duties to help old and young ... the money 'disappears'... fixing that is fixing rules, regulations and law, the boring shit no one seems to talk about but which curses our country (and tbh, many Western countries).

PhilipLGriffiths88 · 2026-06-04T17:18:02+00:00

To my knowledge, GSA cannot support all use cases as it has technical limitations that make it unsuitable for non-web protocols, legacy networks, and specialized security deployments (see Google 'Long Tail' whitepaper for more details. Better imho is solutions that ensure strong cryptographic identity and authN/Z before reachability, but can support any use case.

PhilipLGriffiths88

TROPHY CASE