For workloads with strict localisation, direct-routed ZTNA is usually the safer choice because it keeps the enforcement path under customer control. Cloud-routed designs can still be acceptable in lower-risk contexts, but only if the jurisdictional path, failover, and logging model are provably compliant. The decision should follow residency obligations, not convenience.
Why routing choice changes the security boundary
Direct-routed and cloud-routed ZTNA are not just deployment variants, they define where the trust boundary lives. For sensitive workloads, that matters because enforcement path, inspection point, and logging path can all change the legal and operational exposure of traffic. The question is less about feature preference and more about which architecture preserves control over the path.
Direct-routed ZTNA keeps the traffic path and policy enforcement closer to the customer environment, which is why it better fits strict localisation requirements. Cloud-routed designs can simplify access and operations, but they may insert an additional jurisdiction, processing layer, or dependency that must be justified. If that extra path cannot be proven compliant, it becomes a governance problem, not just a network design choice.
Workload sensitivity also changes the answer. A low-risk application may tolerate shared cloud mediation, but systems carrying regulated data, residency constraints, or tightly bounded blast-radius expectations usually cannot. In practice, the more the workload depends on provable locality and deterministic control, the less attractive cloud mediation becomes.
What actually needs to be proven before you choose cloud routing
Cloud-routed ZTNA is only defensible when the organisation can show that the provider’s control plane, data path, and failover behaviour do not violate the workload’s obligations. That proof should cover where traffic is inspected, where session metadata is stored, who can access logs, and what happens during regional failover or service degradation.
For sensitive workloads, the important detail is not whether the cloud route is “secure” in the abstract, but whether its residency, retention, and support model are compatible with the workload’s constraints. If any of those elements are opaque, the architecture may still function, but it is hard to defend to auditors, legal teams, or internal risk owners.
Direct routing reduces some of that uncertainty by removing an intermediary processing hop, but it does not remove the need for policy, logging, or strong access control. It simply narrows the number of places where the organisation must trust a third-party path.
Why this is a zero trust design decision, not a convenience decision
Zero trust is meant to minimise implicit trust and make access decisions observable, bounded, and continuously enforceable. That is why Zero Trust Identity Guide is useful here: it frames routing as part of the policy enforcement model, not just a transport preference. For sensitive workloads, routing should support least privilege, clear enforcement points, and a predictable control plane.
Workload identity also matters because the route is only one part of the trust story. If the workload itself authenticates through strong, bounded identity, the organisation can make routing decisions with more confidence. The SPIFFE workload identity specification is a good reference for how identity, attestation, and trust bundles support service-to-service access without making the network path the only control.
For teams standardising on zero trust architecture, the relevant question is whether the chosen route preserves continuous verification and policy enforcement where they are needed. NIST SP 800-207 Zero Trust Architecture remains the clearest external baseline for that design choice.
Risk and Threat Considerations
Cloud routing increases exposure when the provider path becomes a concentration point for jurisdictional, logging, or availability risk. For sensitive workloads, the main failure mode is not usually a dramatic compromise, it is a compliance gap caused by traffic, telemetry, or failover moving through a path the organisation cannot fully explain or evidence.
Failure mechanism: A cloud-mediated route introduces an extra dependency that can shift data processing, log handling, or outage recovery into an environment that does not meet residency or control requirements.
Impact: The workload may remain available, but the organisation can lose defensibility over where sensitive traffic was handled, which can create audit findings, contractual breaches, or forced architecture changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Least Privilege Access | ZTNA routing must preserve policy-enforced least privilege for sensitive workload access. |
| Recommendation — Enforce least-privilege access at the policy enforcement point for sensitive workloads. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Routing choice affects where traffic is mediated and how information flow is controlled. |
| AU-2 — Audit Events | The answer depends on provable logging and traceability across normal and failover paths. | |
| Recommendation — Constrain sensitive traffic paths with enforced information-flow controls. Define and retain audit events for access and routing decisions. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | The routing model is a network security design choice affecting control and exposure. |
| A.5.23 — Information security for use of cloud services | Cloud-routed ZTNA creates cloud-service dependency and jurisdictional control considerations. | |
| Recommendation — Select a routing design that preserves the required network security boundary. Validate cloud-service controls, residency, and responsibility before approving cloud routing. | ||
Practitioner Guidance
Decision rule: If the workload has explicit localisation, retention, or supervisory constraints, prefer direct routing unless the cloud path is fully provable against those obligations. If the cloud design is chosen, require documented evidence for inspection location, log residency, and failover behaviour before approving production use.
What to verify: Confirm that the routing model matches the workload’s risk classification, that the provider cannot silently move enforcement outside the approved jurisdiction, and that operational logging remains complete under failure conditions. Do not treat vendor assurances as sufficient if you cannot independently trace the traffic path.
What good looks like: The chosen route is aligned to the workload’s sensitivity, the control owner can explain exactly where policy is enforced, and the organisation can prove that normal and failover paths preserve the same compliance posture.
Practitioner takeaway: For sensitive workloads, routing is part of the control boundary, so the safer design is the one whose enforcement path, evidence trail, and failure modes you can actually defend.
Related resources from NHI Mgmt Group
- What breaks when organisations cannot see sensitive data and vulnerable workloads across cloud services?
- Why do regulated organisations often prefer on premise AI for sensitive workloads?
- What should organisations do after moving workloads to the cloud to keep sensitive data under control?
- How should organisations decide between public, private, and hybrid cloud for sensitive workloads?