A zero trust access pattern where traffic passes through cloud-brokered infrastructure before reaching the target resource. It can improve policy enforcement, but it may also introduce latency, routing dependencies, and resilience concerns for performance-sensitive environments such as healthcare.
Expanded Definition
Cloud-routed ZTNA is a zero trust access pattern in which a user, workload, or AI agent reaches a target resource through brokered cloud infrastructure rather than via a direct network path. That broker can enforce identity checks, policy evaluation, and session controls before access is allowed, which aligns conceptually with NIST SP 800-207 Zero Trust Architecture. In NHI environments, the pattern is often used to avoid exposing services to the public internet while centralising access decisions for distributed teams and cloud workloads.
The practical distinction is that the trust boundary moves from the network perimeter to the access broker, so availability, routing, and telemetry quality become part of the security design. Definitions vary across vendors on whether cloud-routed ZTNA must terminate traffic in a vendor cloud, use private connectors, or simply require a brokered policy plane, so the implementation detail matters more than the label. NHI Management Group sees the pattern most clearly when paired with workload identity and short-lived credentials, as explained in the Guide to SPIFFE and SPIRE and the Ultimate Guide to NHIs — Standards. The most common misapplication is treating cloud-routed ZTNA as a substitute for identity hardening, which occurs when organisations rely on the broker while leaving credentials, entitlements, and session duration uncontrolled.
Examples and Use Cases
Implementing cloud-routed ZTNA rigorously often introduces latency and dependency on the broker path, requiring organisations to weigh centralised policy enforcement against performance and resilience requirements.
- A healthcare application that must keep private APIs off the public internet, while still allowing clinicians, integrations, and service accounts to access them through a controlled broker path.
- A multi-cloud operations team that uses brokered access for administrators, so a single policy layer can evaluate source identity, device posture, and session risk before connection is established.
- A machine-to-machine integration where an AI agent or workload identity accesses internal services through cloud-mediated policy checks instead of static network allowlists, which reduces exposed attack surface.
- An environment with ephemeral credentials where the broker validates short-lived identity assertions before forwarding traffic, pairing access routing with the Guide to SPIFFE and SPIRE model for workload authentication.
- A regulated data platform that uses cloud routing to log every access decision centrally, making it easier to support incident review and access governance aligned with NIST SP 800-207 Zero Trust Architecture.
Cloud-routed ZTNA is also relevant when reviewing cloud compromise patterns such as the 230M AWS environment compromise, where access architecture and identity control both affect blast radius.
Why It Matters in NHI Security
Cloud-routed ZTNA matters because it can either strengthen or weaken the security posture of non-human identities depending on how routing, authentication, and policy enforcement are designed together. If the broker becomes a single point of failure, or if service identities authenticate too broadly, then the access path can create new operational risk even while reducing perimeter exposure. That is especially relevant for NHI use cases where secrets, tokens, and certificates are already difficult to govern consistently. In the 2024 Non-Human Identity Security Report, Aembit found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which helps explain why brokered routing is attractive in the first place.
The governance issue is not just connectivity but control integrity: if access is granted through a cloud intermediary without tight identity binding, then theft of a secret or abuse of a workload token can still bypass intent. Breaches like the Codefinger AWS S3 ransomware attack and the Snowflake breach show how access paths become critical once identity controls fail. Organisations typically encounter the operational cost of cloud-routed ZTNA only after a broker outage, unexpected latency spike, or access incident, at which point the routing model becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Cloud-routed access relies on verified identities before resources are reached. |
| NIST Zero Trust (SP 800-207) | Zero trust architecture directly supports brokered, policy-driven access paths. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Brokered ZTNA still depends on secure handling of NHI credentials and tokens. |
| NIST SP 800-63 | AAL2 | Identity assurance is relevant when access brokers depend on strong authentication. |
| NIST AI RMF | AI agents using routed access need governed identity, context, and risk controls. |
Use a policy decision point to evaluate identity and context before forwarding traffic.
