How should security teams reduce exposure in cloud-routed ZTNA architectures?

Why This Matters for Security Teams

Cloud-routed ZTNA reduces direct exposure compared with legacy VPN patterns, but it can also centralise trust into a handful of broker, relay, and policy endpoints that become attractive public targets. When those services sit on the internet, the security boundary is no longer just the protected application; it also includes the control plane that decides who reaches it. That is why exposure analysis has to focus on shared components, not only the destination systems.

Current guidance from NIST SP 800-207 Zero Trust Architecture treats each access decision as continuous and contextual, which is useful, but teams often stop at the architectural label and miss the operational reality. NHIMG research on NHI and secret handling shows why this matters: the Guide to the Secret Sprawl Challenge highlights how quickly access pathways expand when credentials, relays, and shared control points are left to drift. In practice, many security teams discover the weakest link only after a broker or relay becomes the easiest path for abuse, rather than through a deliberate review of the access path.

How It Works in Practice

The practical goal is to shrink the number of internet-reachable components that can influence access. That usually starts with mapping the full path: user or workload, identity provider, ZTNA broker, relay or connector, policy engine, and the target application. Then classify each component by whether it must be public, whether it can be tenant-isolated, and whether it can be moved behind customer-controlled network boundaries.

A strong pattern is to keep policy evaluation separate from data forwarding. Policy can remain centralized if it is hardened, heavily monitored, and limited to decision-making, while the traffic path itself is minimized. For workload-to-workload access, teams should prefer workload identity and short-lived credentials instead of static shared secrets. NHIMG’s Guide to SPIFFE and SPIRE is a useful reference for treating identity as cryptographic proof of workload origin rather than as a reusable secret.

Useful control moves include:

• Reduce exposed broker surfaces by moving enforcement points inside the customer boundary where the design allows it.
• Use short TTL access tokens and rotate credentials automatically so compromise windows stay narrow.
• Segregate policy administration from traffic handling to reduce lateral movement if one service is touched.
• Log every broker decision and connector change as a security event, not an admin convenience.
• Require step-up controls for high-risk applications rather than giving all routes the same trust level.

Where this becomes urgent is cloud-to-cloud connectivity: the more connectors, tenants, and administrative paths a ZTNA service exposes, the more it resembles a shared control plane with an internet edge. Those controls tend to break down when organisations depend on one broker layer for many environments because a single misconfiguration or flaw can widen blast radius across every routed application.

Common Variations and Edge Cases

Tighter exposure controls often increase deployment and operational overhead, so teams have to balance lower blast radius against easier scale and centralized administration. There is no universal standard for this yet, especially across hybrid estates where some applications cannot move behind customer-owned enforcement points without breaking connectivity or vendor support.

One common edge case is SaaS-to-SaaS routing through a cloud broker. In that model, forcing every component inside the customer boundary may be unrealistic, so the better answer is to harden the public control plane, reduce standing privileges, and use separate trust zones for different application classes. Another edge case is remote admin access for break-glass operations, where strict routing controls must be paired with explicit authorization and very short-lived access.

For teams handling high-value secrets or sensitive infrastructure routes, NHIMG’s 52 NHI Breaches Analysis shows why overextended trust paths are repeatedly abused once credentials or connectors are exposed. In the broader risk picture, the 2024 Non-Human Identity Security Report also found that only 19.6% of security professionals felt strongly confident in securing non-human workload identities, which aligns with the reality that ZTNA exposure reviews are often incomplete. Best practice is evolving toward narrower public control surfaces, ephemeral access, and policy enforcement that can be independently verified.

Related resources from NHI Mgmt Group

• How should security teams reduce exposure in remote access infrastructure?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams reduce cloud data exposure from misconfigured storage?