TL;DR: Foreign jurisdiction, shared cloud control planes, and recent platform vulnerabilities are exposing the limits of formal compliance when sensitive communications sit outside sovereign control, according to SSH Communications Security. The real issue is not where data is labelled as stored, but whether infrastructure, keys, and access policies remain under operational control end to end.
At a glance
What this is: This analysis says sovereign cloud claims can fail when foreign jurisdiction, shared control planes, and weak operational control leave sensitive communications outside practical control.
Why it matters: IAM, PAM, and NHI teams need to treat data sovereignty as an access and control-plane problem, not just a hosting or compliance decision.
Context
Data sovereignty means more than choosing a local region or meeting a formal compliance checklist. If a cloud provider, its jurisdiction, or its control plane can still determine access, retention, or disclosure, sovereignty becomes conditional rather than operational.
The article argues that the gap is most visible for sensitive communications and documents, where control over infrastructure, cryptographic keys, and access policies matters as much as where the data sits. For practitioners, that means sovereignty has to be evaluated across the full identity and control path, not at the storage layer alone.
Key questions
Q: What breaks when sovereign cloud still depends on a foreign control plane?
A: Sovereign cloud loses practical meaning when the provider still controls access paths, policy enforcement, or legal disclosure points. Even with local hosting, the organisation may not control the decisions that matter most. That breaks the assumption that residency equals sovereignty and forces teams to verify who can really administer or compel access.
Q: Why do data residency and data sovereignty produce different risk outcomes?
A: Data residency only says where data sits. Data sovereignty asks who can govern, access, and legally compel that data throughout its lifecycle. The difference matters because a local region can still sit inside a foreign jurisdiction or a provider-managed control plane, leaving the organisation with location but not control.
Q: How should security teams evaluate sovereign messaging platforms?
A: They should check whether the organisation owns the keys, the identity binding, and the administrative control of the channel. Encryption matters, but it is not enough if the platform operator can still influence access or disclosure. A credible sovereign messaging model requires operational ownership, not just confidentiality features.
Q: When is a cloud deployment not truly sovereign even if it meets compliance requirements?
A: It is not truly sovereign when compliance is satisfied on paper but infrastructure, keys, or access policies remain outside the buyer's control. The warning sign is a model that depends on third-party administration or foreign legal reach for core decisions. In that case, compliance exists, but sovereignty remains conditional.
Technical breakdown
Why foreign jurisdiction breaks practical data sovereignty
Data sovereignty fails when legal control and operational control diverge. Even if data is stored in a domestic region, a provider subject to foreign law may still be compelled to disclose it, or may control the surrounding infrastructure and support layers that determine who can access it. That makes sovereignty a question of enforceable control, not a geographic label. For identity teams, the issue extends beyond the data object to the policies, keys, and administrative paths that govern it.
Practical implication: verify who can compel access, not just where data is hosted.
Shared control planes and third-party platforms in sovereign cloud
Sovereign cloud promises depend on whether the organisation actually owns the control plane, the keys, and the access policy decisions. When those functions remain in a third-party platform, the organisation may have localisation without sovereignty. This is especially weak for collaborative and messaging systems, because they combine content storage, authentication, encryption, and administrative access in one dependency chain. The result is a control boundary that looks sovereign on paper but remains externally governed in practice.
Practical implication: map which identity, key, and admin decisions stay external before treating a deployment as sovereign.
Why secure messaging needs operational control, not just encryption
End-to-end encryption helps protect message content, but it does not by itself solve jurisdiction, ownership, or administrative trust. If identity verification, key custody, or infrastructure administration are not fully under the organisation's control, the confidentiality guarantee is narrower than the sovereignty claim. Secure messaging for public-sector and critical environments therefore has to combine encryption with deployment ownership and tightly governed identity binding. In practice, sovereignty is about who can operate the channel, not only who can read the payload.
Practical implication: align messaging security with owned deployment, controlled keys, and strong identity binding.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Data sovereignty is being undermined by control-plane dependency, not just by where data is stored. The central flaw is that many organisations equate regional hosting with sovereign control, even when the provider still governs access, administration, or legal disclosure. That assumption fails whenever the control plane sits outside the buyer's authority. The practical conclusion is that sovereignty programmes need to measure who can actually compel or administer access, not who advertises local hosting.
Key management is the real sovereignty boundary for sensitive communications. If cryptographic keys, admin credentials, or policy decisions remain under a third-party's operational control, encryption becomes a privacy layer rather than a sovereignty guarantee. This is especially true for messaging and document-sharing systems, where identity, key custody, and routing are tightly coupled. Practitioners should treat key and access control ownership as the first test of whether a deployment is genuinely sovereign.
Formal compliance is not a substitute for operational control. A system can satisfy procurement, data residency, or regulatory checkboxes and still leave access exposed through foreign jurisdiction or provider-managed dependencies. That gap is not theoretical for public-sector, defence, and critical-infrastructure use cases. The lesson for IAM and PAM teams is to assess enforcement power, not just policy language, when approving cloud and messaging platforms.
Deployed sovereignty requires identity-bound trust, not platform trust. The article's strongest signal is that the question is shifting from where the data lives to who is authenticated, who administers the channel, and who can change the rules. That makes sovereign messaging and cloud controls part of the identity governance stack, not a separate procurement discussion. The implication is clear: control, custody, and accountability must line up end to end.
Named concept: sovereignty control gap. This is the gap between what a procurement contract or residency claim promises and what the operator can enforce in practice. It appears when jurisdiction, access policy, and key custody are split across organisations or countries. Practitioners should use this concept to test every sovereignty claim against actual control ownership.
What this signals
Sovereignty control gap: The most useful way to read this article is as a control-ownership test, not a hosting preference. If a cloud or messaging platform leaves key custody, identity policy, or administrative authority outside your organisation, sovereignty is only contractual.
For IAM and PAM teams, the immediate change is to include jurisdictional reach and admin custody in vendor due diligence. A platform that looks compliant can still fail the sovereignty test if foreign law or provider operations can override local intent.
For practitioners
- Audit sovereignty assumptions across the control plane Map which provider, region, legal regime, and admin domain can actually alter access, retention, or disclosure for sensitive communications.
- Separate residency from operational control Treat data locality as only one input. Confirm whether keys, identity policies, and administrative actions remain under your organisation's authority.
- Require owned key custody for sensitive messaging Use end-to-end encryption only where your organisation controls the key lifecycle and can revoke access without depending on the platform vendor.
- Review foreign-jurisdiction exposure in vendor contracts Check whether legal compulsion, support access, or subcontracted infrastructure can override the sovereignty posture you believe you have.
- Align messaging platforms to identity governance Tie administrator access, authentication, and change control to the same governance model you apply to privileged access in core systems.
Key takeaways
- Data sovereignty fails when legal reach, provider administration, or shared control planes sit outside the organisation's practical authority.
- The article's core warning is that local hosting and formal compliance do not guarantee control over keys, access policies, or disclosure decisions.
- Teams should evaluate sovereign cloud and secure messaging by custody, jurisdiction, and admin control, not by residency claims alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CSA Cloud Controls Matrix and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud sovereignty here hinges on who controls identity and administration in the cloud. |
| Recommendation — Review cloud IAM ownership so access decisions remain under your organisation's authority. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on who can grant, change, and enforce access in sovereign environments. |
| Recommendation — Apply PR.AA-05 to verify that access governance stays with the asset owner, not the platform operator. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party cloud and messaging dependencies create the sovereignty gap this article describes. |
| NHI-04 — Insecure Authentication | Secure messaging sovereignty depends on identity binding and authenticated channel control. | |
| Recommendation — Track third-party NHI dependencies and remove any external access path that can override local control. Strengthen authentication so only trusted identities can administer sovereign messaging channels. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article references platform compromise and data exposure as the practical threat pattern. |
| Recommendation — Map exposed cloud dependencies to credential access and exfiltration scenarios in your detection coverage. | ||
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.
- Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
- Key Custody: Key custody is the ownership and control of cryptographic keys across their lifecycle, including storage, rotation, emergency use, and retirement. Poor custody turns encryption into a weak barrier because any identity with key access can recover data that should have remained protected.
- Administrative authority: Administrative authority is the practical ability to modify policies, workflows, integrations, and reporting without waiting on a third party. In identity governance, it is a marker of real control because it determines whether the organisation can respond to risk, compliance, and business change on its own timeline.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org