GDPR data sovereignty and ZTNA routing risk for enterprises

At a glance

What this is: Appgate argues that cloud-routed ZTNA can undermine GDPR compliance when vendor-managed PoPs move personal data or session metadata across borders.

Why it matters: IAM and security teams need routing decisions to reflect data transfer rules, because access control alone does not prevent sovereignty failures when identity metadata leaves jurisdictional boundaries.

Context

GDPR-related access design is not only about who can reach a resource, but also about where the associated data and metadata travel on the way there. Cloud-routed ZTNA can satisfy encryption and authentication requirements while still creating cross-border processing risk if vendor-controlled infrastructure brokers the session outside the relevant jurisdiction.

For identity and access teams, this is a governance problem as much as a network problem. Routing choices affect whether personal data, session identifiers, and authentication metadata remain under the organisation’s legal and operational control, so sovereignty has to be treated as part of the access architecture, not a separate compliance review.

Key questions

Q: What breaks when ZTNA traffic is brokered through vendor-controlled PoPs under GDPR?

A: The compliance assumption that secure transport equals lawful processing breaks down. If personal data, session metadata, or identifiers pass through infrastructure in another jurisdiction, the organisation may trigger a cross-border transfer even when the payload is encrypted. The practical failure is architectural: the access service becomes an extra processor the privacy team did not intend to add.

Q: Why can encrypted access still create GDPR transfer risk?

A: Encryption protects confidentiality, but GDPR also governs where personal data is processed and transferred. If a ZTNA relay, logging layer, or authentication path handles identifiable metadata outside the EEA, the organisation can still have a transfer issue. The risk is not decryption, it is jurisdictional processing.

Q: How should security teams evaluate ZTNA routing choices for sovereignty?

A: They should review the full access path, including PoPs, telemetry, and identity integrations, against the organisation’s approved processing regions. The decision criterion is whether the architecture keeps both payloads and metadata under customer governance, not whether the session is technically secure.

Q: What is the difference between direct-routed and cloud-routed ZTNA for compliance?

A: Direct-routed ZTNA keeps session traffic on customer-controlled paths and lets the organisation choose where controllers and gateways live. Cloud-routed ZTNA brokers traffic through vendor infrastructure, which can introduce additional jurisdictions and data transfer obligations. For GDPR, that difference matters because the routing layer itself can change the compliance posture.

Technical breakdown

Why vendor-controlled ZTNA PoPs create sovereignty risk

Many ZTNA products place points of presence between the user and the protected resource so the service can inspect policy, broker the connection, and optimise performance. That relay model is operationally convenient, but it also means traffic metadata, session identifiers, and sometimes routing information pass through infrastructure the customer does not control. Under GDPR, that can qualify as processing or transfer even if the payload is encrypted. The technical issue is not whether the connection is secure in transit, but whether the architecture introduces an additional jurisdictional processor into the path.

Practical implication: Treat routing architecture as a compliance control and map every brokered hop to the jurisdictions it introduces.

Why encryption does not remove GDPR transfer obligations

Encryption protects confidentiality, but it does not erase the fact that personal data can still traverse non-EU infrastructure. GDPR Chapter 5 focuses on where personal data is processed and whether transfers outside the EEA have an adequate legal basis, not just on whether outsiders can read the payload. Session metadata, device identifiers, and authentication events can be personal data if they relate to an identifiable person. That makes architecture reviews incomplete when they stop at encryption and ignore the control plane, telemetry path, and vendor-managed routing layer.

Practical implication: Review control-plane and telemetry paths alongside payload protection when assessing cross-border transfer exposure.

Direct routing as a jurisdictional control pattern

Direct-routed ZTNA changes the trust boundary by removing the third-party relay layer and letting the customer place controllers and gateways in approved regions or on-premises. That does not remove the need for strong authentication, logging, or policy enforcement, but it does reduce unnecessary movement of personal data across borders. In governance terms, it turns sovereignty from an assumption into an architectural property that can be documented and audited. The design aligns better with data minimisation and accountability because fewer intermediaries handle the session.

Practical implication: Prefer access paths that keep routing, logging, and policy enforcement inside customer-controlled jurisdictions where possible.

NHI Mgmt Group analysis

Cloud-routed access has become a sovereignty control problem, not just a performance choice. When a ZTNA service brokers traffic through vendor-managed infrastructure, the organisation inherits an additional processing location that may sit outside the intended legal boundary. That makes data-transfer governance part of the access design itself. Practitioners should evaluate routing topology with the same seriousness they apply to identity assertions and logging paths.

Encryption-first thinking is insufficient when the route itself is the compliance event. GDPR does not only care about whether content is readable in transit. It also cares about whether personal data, session metadata, and identifiers are processed or transferred through non-EEA infrastructure. The governance gap is the assumption that secure transport equals compliant transport, which is not true when a third-party relay is in the path.

Data sovereignty is an access-architecture property that must be designed, not promised. The article’s core message is that jurisdictional control can be preserved only when customers control the route, the gateway placement, and the processing geography. That is especially important for organisations operating across the EU and other regulated regions, where routing decisions can create accountability gaps even before any incident occurs.

Identity metadata is now part of the sovereignty surface. User identity, device context, and session telemetry often travel with the request, which means identity governance and privacy governance overlap at the routing layer. That creates a named concept worth tracking: routing sovereignty gap, the point where secure access succeeds technically but fails legally because the path leaves the intended jurisdiction. Teams should assess this gap explicitly in every ZTNA design review.

Zero trust implementation cannot be considered complete until the broker path is jurisdictionally constrained. A solution may still meet least-privilege goals while violating transfer requirements if its intermediate processing path is uncontrolled. For identity architects, the practical conclusion is clear: access policy, authentication, and sovereign routing have to be designed as one control plane.

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

Routing sovereignty gap: access programmes now need to treat the relay path as part of privacy governance, because jurisdictional exposure can arise even when the application owner believes the session is encrypted and under control. Teams that only validate policy enforcement will miss the legal significance of brokered access flows.

For multinational deployments, the practical risk is cumulative: one access pattern for the EU, another for the U.S., and a third for APAC can create inconsistent audit evidence and weak transfer governance. The better model is to define approved processing geographies first, then choose ZTNA routing patterns that stay inside them.

For practitioners

• Map every ZTNA broker hop Inventory the points of presence, relays, and telemetry paths that handle user sessions, then identify which jurisdictions they operate from and which data elements they process.
• Require customer-controlled routing paths Prioritise architectures that let you place controllers and gateways in your own regions or on-premises so session flows do not rely on vendor-managed detours.
• Classify session metadata as governed data Include identifiers, device context, and authentication telemetry in your GDPR data maps so reviews cover more than the application payload.
• Document transfer safeguards for each access region Tie each region-specific deployment to the legal basis, retention policy, and audit evidence needed to show that personal data stays within approved boundaries.

Key takeaways

• Cloud-routed ZTNA can create GDPR exposure by moving session-related data through infrastructure outside the intended jurisdiction.
• The key control failure is assuming that encrypted transport alone satisfies cross-border transfer requirements.
• Direct-routed architectures reduce sovereignty risk by keeping routing and processing under customer governance.

Key terms

• 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.
• Zero Trust Network: A Zero Trust Network is a network security approach that does not trust users, devices, or traffic by default. Every connection is continuously verified using identity, device posture, context, and policy before access is granted. It assumes breach, limits lateral movement, and treats network access as conditional rather than implicit.
• Vendor-Controlled Point of Presence: A vendor-controlled point of presence is a service location used to relay or broker traffic between users and resources. It can introduce additional jurisdictions into an access flow, which makes routing design relevant to privacy, transfer rules, and auditability.
• Session Metadata: Session metadata is the contextual information generated while access is being established or maintained, such as user identifiers, device posture, timestamps, and routing details. It can be regulated data under privacy law when it relates to an identifiable person or reveals their behaviour.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management through a practitioner-led curriculum. It is designed for teams that need to connect identity controls to broader security and compliance decisions.