Teams should treat routing as part of the access control decision, not just a network optimisation. If a ZTNA service brokers sessions through foreign infrastructure, the architecture may create sovereignty exposure even when the user and resource are local. The safer approach is to localise enforcement, logging, and traffic handling within the required jurisdiction.
Why zero trust routing and sovereignty cannot be treated separately
When data sovereignty rules limit where traffic may pass, zero trust cannot stop at authentication and authorisation. The access path itself becomes part of the control boundary. If a security broker, inspection service, or session relay exits the required jurisdiction, the organisation may satisfy the logical trust model while still violating the routing constraint that governs the data path.
This is especially important where NIST SP 800-207 Zero Trust Architecture is implemented through centralised policy enforcement. The principle still holds, but the placement of policy decision and enforcement points must respect jurisdictional requirements, not only identity assurance and least privilege.
Teams should therefore model route locality as a security property, not a transport detail. That means deciding where sessions are brokered, where logs are written, where packet inspection occurs, and where metadata is stored, because each of those handling points can create cross-border exposure even if the application workload remains in the right region.
What design choices usually determine whether the architecture is compliant
The practical question is not whether the environment uses zero trust, but whether the control plane and data plane stay inside the allowed boundary. A ZTNA deployment can still be acceptable if it localises enforcement and telemetry, uses regional points of presence, and avoids routing that depends on foreign intermediaries for session establishment or logging.
Workload and service identity controls are often part of the answer when service-to-service access is in scope. Guide to SPIFFE and SPIRE is useful where teams need locally verifiable workload identity, mTLS, and trust bundles without pushing trust decisions outside the jurisdiction. That pattern helps preserve the zero trust model while keeping enforcement close to the protected system.
For broader programme design, Zero Trust Identity Guide and Remote Access Identity Guide both reinforce the same operational point: identity-centric access works best when the policy, posture, and session path are engineered together. If the policy is jurisdictionally sound but the relay is not, the deployment is still misaligned.
How to judge whether a cross-border hop is a real problem
The decisive factor is what crosses the boundary and whether that crossing is necessary for the access decision. In some designs, only encrypted control messages traverse external infrastructure, which may be acceptable if the regulatory regime permits it and no regulated data, logs, or recoverable metadata leave the region. In others, the broker sees usernames, device posture, session context, or application payloads, which makes the routing path much harder to defend.
Zero trust also interacts with identity governance. IAM and IGA Basics matters here because the organisation must know which identities, entitlements, and policy decisions are in play before it can prove that access was confined to the required jurisdiction. If teams cannot show where decisions were made and where evidence was retained, they will struggle to demonstrate compliance after an audit or incident.
That is why architecture reviews should trace the full request path, not just the endpoint trust relationship. The question is whether the access workflow can be completed, observed, and investigated without any mandatory cross-border handling. If the answer is no, the design needs regional enforcement, regional logging, or a different access pattern altogether.
Risk and Threat Considerations
Cross-border routing creates a sovereignty failure mode when a control intended to reduce trust expansion also expands the jurisdictional footprint of the session. The risk is not only regulatory, it is also operational, because the organisation may lose control over where sensitive metadata, inspection records, or session artefacts are processed and retained.
Failure mechanism: The brokered access path, logging plane, or inspection service routes through infrastructure outside the permitted jurisdiction, so the access control decision depends on infrastructure that violates the data residency or sovereignty constraint.
Impact: The organisation can end up with a compliant-looking access policy but an unlawful or ungovernable traffic path, creating audit findings, contractual breach, and avoidable exposure if logs, context, or session data are disclosed or retained abroad.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Routing and jurisdictional handling are part of enforcing where access flows may go. |
| AU-12 — Audit Record Generation | Local logging is central when sovereignty rules constrain where records may be processed. | |
| SC-7 — Boundary Protection | ZTNA brokers and relays define the trust boundary and must stay within the permitted path. | |
| Recommendation — Enforce jurisdiction-bound information flows for ZTNA traffic and session handling. Generate audit records within the required jurisdiction for access and session events. Constrain session routing and inspection paths to approved boundary points. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | The access decision must account for identity and location-related policy constraints. |
| PR.DS-01 — Data-at-Rest is Protected | Sovereignty concerns often extend to where logs and session data are stored. | |
| Recommendation — Bind access decisions to jurisdictional policy before permitting session establishment. Keep stored logs and session artefacts within approved regional controls. | ||
Practitioner Guidance
What to verify: Confirm the exact components that touch the session, including policy decision points, enforcement points, log sinks, and support tooling. If any of them are outside the approved jurisdiction, treat the design as non-compliant until the data path is proven otherwise.
Decision rule: If routing locality is part of the legal or contractual requirement, choose a regional ZTNA pattern that keeps session establishment, inspection, and telemetry local. If the vendor cannot bound those functions regionally, use a different architecture rather than accepting a “trust the tunnel” argument.
Practitioner takeaway: For sovereignty-constrained environments, zero trust succeeds only when the access decision and the traffic path are co-designed; separating them usually creates the very exposure zero trust was meant to reduce.
Related resources from NHI Mgmt Group
- What is the difference between JIT access and Zero Trust for NHIs?
- How should security teams implement Zero Trust when access data is fragmented?
- How should security teams combine cloud workload risk data with access context to improve zero trust decisions?
- How should security teams implement zero-trust security in SuperApps that handle payments, messaging, and personal data?