Notifications
Clear all
Topic starter
10/07/2026 9:12 pm
TL;DR: Cloud-routed ZTNA and SASE models that depend on a vendor-operated cloud broker keep the broker publicly reachable, which expands shared exposure and broadens the blast radius of a single flaw, according to Appgate. Direct-routed, customer-boundary enforcement changes the identity and access risk calculation by reducing discoverability and shared-service exposure.
NHIMG editorial — based on content published by Appgate: Why Cloud-Routed Access Creates Unnecessary Exposure
Questions worth separating out
Q: How should security teams reduce exposure in cloud-routed ZTNA architectures?
A: Start by identifying every cloud broker, relay, and control endpoint that sits in the access path.
Q: Why do shared ZTNA brokers increase risk for federal and regulated environments?
A: Shared brokers create a common failure domain.
Q: What breaks when access enforcement depends on a publicly reachable broker?
A: The main break is the assumption that the access layer is a private control boundary.
Practitioner guidance
- Map your exposed access plane Inventory every externally reachable ZTNA and SASE enforcement point, including brokers, gateways, and control endpoints.
- Separate enforcement from shared reachability For high-value environments, test whether direct-routed access can keep policy enforcement local while avoiding a publicly reachable broker.
- Use cloaking as an exposure control Where the architecture supports it, require hidden or low-discoverability gateways for sensitive segments so scanners cannot enumerate access points before authorization.
What's in the full article
Appgate's full analysis covers the operational detail this post intentionally leaves for the source:
- Architecture comparisons between cloud-routed and direct-routed ZTNA deployment patterns.
- Vendor-stated federal proof points, certifications, and deployment contexts for mission environments.
- How Single Packet Authorization is used to keep gateways invisible until a valid packet is presented.
- The specific operational trade-offs Appgate highlights for low-latency access, tactical edge, and DDIL conditions.
👉 Read Appgate's analysis of cloud-routed ZTNA exposure and direct-routed access →
Cloud-routed ZTNA exposure: what federal teams should re-evaluate?
Explore further
10/07/2026 9:35 pm
Cloud-broker exposure is now an identity governance problem, not just a network design trade-off. When access enforcement depends on a publicly reachable, multi-tenant broker, the control plane itself becomes part of the threat surface. That changes how teams should think about trust boundaries, because an access layer that can be scanned and attacked at scale behaves more like shared infrastructure than private enforcement. Practitioners should treat broker exposure as a governance decision with identity consequences.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to the 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to Oasis Security & ESG.
A question worth separating out:
Q: Who is accountable when a cloud-routed access broker fails or is compromised?
A: Accountability remains with the organisation that chose the architecture, even when the service is operated by a vendor. Teams need clear ownership for availability, incident response, change control, and exposure review. If the enforcement point is shared, accountability for the business impact cannot be outsourced along with the traffic path.
👉 Read our full editorial: Cloud-routed ZTNA creates avoidable exposure in federal access
