Data sovereignty risks in cloud-routed ZTNA and access control

At a glance

What this is: Cloud-routed ZTNA can shift access sessions through third-party infrastructure and create data sovereignty risk, even when the underlying traffic is encrypted.

Why it matters: IAM and security teams need proof that access paths stay inside required jurisdictions, because routing choices can create compliance exposure independent of policy intent.

Context

Data sovereignty is not just a privacy issue. It is a governance constraint that requires organisations to know where access sessions travel, which infrastructure handles them, and whether those paths remain inside the right legal jurisdiction.

ZTNA is meant to reduce trust in the network path, but cloud-routed designs can reintroduce a hidden intermediary. That matters to IAM and identity governance because access policy alone does not prove where data was processed or relayed.

For organisations operating across regulated regions, the practical question is whether the access architecture can demonstrate jurisdictional control end to end. In that sense, cloud routing turns sovereignty into an identity and access governance problem, not only a network design choice.

Key questions

Q: What breaks when cloud-routed ZTNA is used in sovereign data environments?

A: The control assumption that access enforcement and data residency are the same thing breaks first. A cloud broker can relay an authorised session through foreign infrastructure, which means the organisation may satisfy authentication requirements while still violating local data-location rules. The result is a governance failure, not just a networking inefficiency.

Q: Why does ZTNA routing matter for compliance and accountability?

A: Because regulators care about where data is processed as well as who can reach it. If a cloud broker relays the session, the organisation may not be able to demonstrate that the data stayed inside the required legal boundary. That shifts ZTNA from a pure access problem into a governance and evidentiary one.

Q: How should security teams validate ZTNA sovereignty controls?

A: They should validate the full session path, not only the access decision. That means mapping broker locations, checking failover routes, reviewing logs that show where traffic was processed, and confirming that legal and architectural controls match for every regulated application. If the path cannot be proven, the sovereignty control is incomplete.

Q: Should organisations prefer direct-routed or cloud-routed ZTNA for sensitive workloads?

A: 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.

Technical breakdown

Why cloud broker ZTNA creates sovereignty exposure

Cloud-routed ZTNA commonly inserts a vendor-controlled broker or point of presence between the user and the target resource. The session may be authenticated locally, but the traffic path is not local if the broker sits in another country or region. That means the data path, metadata handling, and often the operational control point are outside the customer’s jurisdictional boundary. Encryption in transit protects confidentiality, but it does not change where the session traverses or which legal regime can apply to that relay.

Practical implication: Map every ZTNA relay point to a jurisdiction before you treat the architecture as compliant.

Why direct routing changes the access-control model

Direct-routed ZTNA removes the external relay and sends the session from user to resource without backhauling through a vendor cloud. Architecturally, that shifts enforcement to the edge while preserving the customer’s control over the path itself. This matters because sovereignty requirements are about both authorisation and data location. A policy that allows access is not enough if the traffic still transits an unapproved region.

Practical implication: Prefer architectures that keep the access path inside customer-governed infrastructure when jurisdictional control is a hard requirement.

How claims-based access supports contextual sovereignty decisions

Claims-based access uses identity, device, and contextual attributes to decide whether a session should proceed. In a sovereignty context, those same controls can be used to tie access not only to who and what is requesting it, but also to where the access is occurring from and which conditions are acceptable. The governance value is that policy can express regional constraints directly instead of relying on network architecture assumptions.

Practical implication: Bind access decisions to jurisdiction-aware policy conditions rather than assuming network placement will enforce them.

NHI Mgmt Group analysis

Cloud-routed ZTNA creates a jurisdictional control gap, not just a performance trade-off. The architecture can satisfy access policy while still violating sovereignty rules if sessions traverse vendor infrastructure in the wrong region. That makes the control question broader than authentication or segmentation. Practitioners should evaluate where the path is enforced, not only where the policy is written.

Jurisdictional proof becomes part of identity governance when access brokers handle the session. If a vendor-controlled PoP relays traffic, the organisation must be able to evidence data location as part of access assurance. That pushes sovereignty into IAM and GRC territory, especially for regulated workloads and cross-border user populations. Practitioners should treat path evidence as audit evidence.

Data path sovereignty: this is the control problem the article exposes, where the legal location of the access path matters as much as the entitlements behind it. The concept is distinct from least privilege because a perfectly scoped session can still cross an impermissible border. Practitioners should make jurisdictional routing a design requirement, not an after-the-fact compliance check.

Direct routing is the cleaner architecture when legal locality is a hard requirement. It reduces the number of parties and geographies touching the session, which narrows sovereignty exposure and simplifies auditability. That does not eliminate the need for contextual access policy, but it removes a structural source of compliance ambiguity. Practitioners should prefer direct paths for workloads subject to localisation rules.

Cloud routing can complicate Zero Trust rather than complete it. Zero Trust assumes strong verification and explicit policy, but sovereignty requirements add a separate constraint on where the trust enforcement path may operate. The result is a governance overlay on top of access control. Practitioners should test ZTNA designs against both security and residency obligations before deployment.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Data path sovereignty: organisations should now treat the access route itself as a governed asset. If a security control can forward sessions through another jurisdiction, the architecture is creating a compliance risk that policy text alone cannot cure.

Sovereignty-heavy programmes need evidence at the routing layer, not only at the entitlement layer. That shifts part of the audit burden toward network path assurance, logging, and design review for any ZTNA service that uses third-party relays.

Where identity governance and access delivery converge, the practical test is simple: can the organisation prove the session never left the approved jurisdiction? If not, the control is incomplete.

For practitioners

• Inventory every ZTNA relay path Document the exact countries and cloud regions used by each access broker, PoP, and failover path before you treat the deployment as sovereignty-compliant.
• Require jurisdiction-aware routing controls Set policy so regulated sessions are only permitted when the access path stays inside approved jurisdictions and no vendor backhaul is involved.
• Evidence the access path for auditors Capture routing, relay, and region data as part of access logs so compliance teams can prove where sensitive sessions were processed.
• Align ZTNA design with data residency rules Map residency obligations for GDPR, CCPA, India, and sector-specific rules to the access architecture before rollout, not after exceptions appear.

Key takeaways

• Cloud-routed ZTNA can create a sovereignty problem even when authentication and encryption are working as intended.
• The core risk is not only exposure in transit, but the inability to prove that access sessions stayed inside the required jurisdiction.
• Practitioners should assess routing, logging, and residency evidence together before accepting ZTNA designs for regulated workloads.

Key terms

• Cloud-routed ZTNA: 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.
• Data Sovereignty: Data sovereignty is the principle that information remains subject to the control, governance, and legal expectations of the organisation or jurisdiction that owns it. In identity programmes, it becomes a control question about who can authorise, revoke, and evidence access as systems cross borders.
• Direct-Routed Access: An access architecture where traffic is enforced inside the customer boundary instead of being backhauled through a shared cloud broker. The value is tighter operational control, lower external exposure, and a clearer trust boundary for high-sensitivity or regulated environments.
• Claims-Based Authentication: Claims-based authentication uses signed identity statements, or claims, to tell an application who the user is and what they can access. It shifts the access decision to the trust relationship and token validation process rather than the application collecting credentials itself.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps practitioners connect identity controls to the broader security and compliance decisions their programmes depend on.