Data sovereignty risks in cloud-routed ZTNA and access control

At a glance

What this is: Cloud-routed ZTNA can introduce data sovereignty risk by sending sessions through vendor infrastructure outside the required jurisdiction.

Why it matters: IAM and security teams must validate where access traffic actually flows, because sovereignty failures can turn an access-control design choice into a compliance and trust problem.

By the numbers:

• GDPR fines can reach up to 4% of global annual turnover.

👉 Read Appgate's analysis of data sovereignty risk in cloud-routed ZTNA

Context

Data sovereignty means access paths and processing locations must stay within the jurisdiction that governs the data, not just within the organisation's policy boundary. For IAM programmes, that turns routing, broker placement, and policy enforcement into governance issues, because the control plane can affect where regulated data is processed.

The article argues that cloud-routed ZTNA can undermine that requirement by sending sessions through vendor-controlled infrastructure in another region. That matters for identity and access teams because the access decision and the data path are no longer the same thing, which makes sovereignty proof part of access governance rather than a separate compliance check.

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 do encrypted sessions still create data sovereignty risk?

A: Encryption protects content, but sovereignty regimes also care about where traffic is terminated, inspected, and relayed. If a session passes through infrastructure in the wrong jurisdiction, the organisation may have handled data outside its permitted boundary even when no one can read the payload. That distinction is central for compliance and audit evidence.

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: Who is accountable when ZTNA routing violates residency requirements?

A: Accountability usually sits across security, networking, privacy, and legal teams, because the failure is architectural and regulatory at the same time. Security owns the access design, networking owns the routing model, and privacy or legal owns the residency interpretation. Organisations need a clear control owner before deploying brokered access at scale.

Technical breakdown

Cloud-routed ZTNA and jurisdictional data paths

Cloud-routed ZTNA uses a broker or point of presence to terminate and relay sessions before they reach the protected resource. That architecture can simplify connectivity, but it also means the session path may traverse infrastructure in a different jurisdiction than the user or application. For sovereignty regimes, the routing path itself becomes part of the regulated handling of data, even when payloads remain encrypted. The issue is not only interception risk. It is the fact that metadata, session handling, and sometimes inspection all occur outside the required legal boundary.

Practical implication: map every ZTNA relay point to a jurisdiction and treat broker placement as a compliance control.

Why encryption does not solve data residency

Encryption protects confidentiality in transit, but it does not change where the traffic is processed, relayed, or jurisdictionally handled. Data sovereignty laws often care about location and legal control, not only exposure to third parties. A session can therefore remain encrypted and still create a residency problem if it crosses borders through infrastructure the organisation does not control. For identity teams, this means access architecture must prove geographic and contractual control over the session path, not just authenticate the user and device.

Practical implication: separate cryptographic protection from residency assurance in your design and audit evidence.

Direct-routed access as a governance pattern

Direct-routed ZTNA keeps the session path between the user and the protected resource without backhauling through a vendor cloud. That reduces the number of jurisdictions involved and makes it easier to demonstrate that data stayed within the intended boundary. In governance terms, it also tightens the relationship between access policy and data path, which is what sovereignty programmes need. The key is not zero trust as a slogan, but whether the architecture preserves customer control over where access is terminated and relayed.

Practical implication: prefer access designs that preserve customer-controlled routing where sovereignty obligations are strict.

NHI Mgmt Group analysis

Cloud-routed access has become a sovereignty control problem, not just a networking choice. When access brokers sit in vendor-controlled regions, the organisation can lose practical control over where regulated traffic is handled. That weakens the evidence chain needed for auditors and regulators, especially when legal requirements focus on data location as much as confidentiality. Practitioners should treat ZTNA pathing as part of access governance, not deployment convenience.

Jurisdictional routing is the missing named concept in many ZTNA decisions. The article exposes a jurisdictional routing gap, where the policy says one thing and the session path does another. That gap matters because compliance teams often validate destination access while overlooking intermediary processing locations. The control question is whether the architecture can prove the path stayed inside the required boundary. Practitioners should demand path-level assurance, not only policy-level assurance.

Identity governance now extends into where the access broker lives. This is where IAM and ZTA intersect: authentication may be correct, but the access decision can still fail the sovereignty test if the relay architecture is wrong. For global enterprises, especially in regulated sectors, that means identity architecture choices can trigger legal exposure even when no data is visibly exfiltrated. Practitioners should align identity and network governance before standardising on a broker model.

Least privilege is necessary here, but it does not substitute for data-path control. The article's segment-of-one logic reduces unnecessary exposure, yet sovereignty obligations are independent of entitlement minimisation. A tightly scoped session can still violate residency rules if it traverses the wrong jurisdiction. The practical lesson is that least privilege and jurisdictional routing must be designed together, not treated as interchangeable controls.

What this signals

Jurisdictional routing will increasingly sit alongside least privilege in architecture reviews. As sovereignty rules expand across regions, practitioners will need to prove not just access intent but access geography. The practical shift is from policy-only governance to path-verifiable governance, with routing evidence becoming part of the control narrative rather than an afterthought.

The programme-level risk is that brokered access can create hidden compliance debt when teams optimise for deployment simplicity. Security architects should expect privacy, legal, and IAM stakeholders to ask for control evidence that links the access policy, the broker location, and the regulated data class in one chain of proof.

For practitioners

• Define jurisdiction-aware routing requirements Document which applications and data classes must never traverse foreign broker infrastructure, and make that requirement part of architecture approval.
• Inventory every ZTNA relay point Map vendor points of presence, inspection nodes, and failover paths to the jurisdictions they operate in, then compare that map with residency obligations.
• Test sovereignty evidence before go-live Validate that audit logs, network traces, and policy records can prove the session path remained within the required jurisdiction.
• Separate access policy from path assurance Require teams to show both who was authorised and where the traffic was processed, because an authorised session can still breach sovereignty rules.

Key takeaways

• Cloud-routed ZTNA can satisfy access policy while still failing sovereignty requirements if sessions traverse the wrong jurisdiction.
• The scale of the issue is regulatory, not just technical, because data-location obligations can carry fines and audit exposure even when traffic remains encrypted.
• Practitioners need path-level evidence, jurisdiction-aware routing, and control ownership across IAM, networking, and privacy teams.

Key terms

• Data Sovereignty: Data sovereignty is the requirement that data remains subject to the laws and governance rules of the jurisdiction where it is collected or processed. In practice, organisations must control both where data travels and who can legally handle it, not just whether it is encrypted or authenticated.
• Cloud-Routed ZTNA: Cloud-routed ZTNA is a zero trust access pattern where sessions are relayed through vendor-operated infrastructure before reaching the protected resource. It can simplify deployment, but it also introduces jurisdiction, latency, and control-path issues that matter in regulated environments.
• Direct-Routed Architecture: Direct-routed architecture sends the access session directly between the user and the destination resource without backhauling through an intermediary cloud broker. This approach reduces the number of jurisdictions involved in processing and makes it easier to demonstrate control over the session path.
• Jurisdictional Routing Gap: A jurisdictional routing gap exists when the access policy says a session is allowed, but the actual traffic path crosses a location that is not permitted under law or contract. It is a governance failure because the control decision and the data path no longer align.

What's in the full article

Appgate's full article covers the operational detail this post intentionally leaves for the source:

• Direct-routed ZTNA architecture details for teams comparing brokered and non-brokered session paths
• Claims-based access and contextual risk integration specifics for access policy design
• Deployment considerations across on-premises, hybrid, cloud, and edge environments
• Practical compliance positioning for organisations working under GDPR, CCPA, or local residency laws

👉 Appgate's full article covers the direct-routed architecture and compliance rationale in more implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and related access-control principles. It helps identity and security practitioners build the governance foundations that support regulated access architectures.