Notifications
Clear all
Topic starter
23/06/2026 9:12 pm
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.
NHIMG editorial — based on content published by SSH Communications Security: data sovereignty, sovereign cloud, and secure messaging control
Questions worth separating out
Q: How should security teams evaluate whether a cloud platform is truly sovereign?
A: Start by checking who controls the identity plane, the cryptographic keys, and the privileged administration workflow.
Q: Why do compliance approvals not guarantee data sovereignty?
A: Compliance can confirm that a control existed on paper, but it does not prove the organisation retained operational authority over the platform, keys, or support processes.
Q: What breaks when sensitive communications depend on foreign cloud platforms?
A: The main failure is control-plane dependence.
Practitioner guidance
- Map the sovereign trust boundary Document which entities can administer the platform, influence cryptographic keys, and execute recovery actions.
- Separate residency from control Verify whether data stored locally is still subject to foreign jurisdiction, provider support access, or externally managed admin workflows.
- Review privileged access to communications systems Apply PAM and access review discipline to messaging, collaboration, and secure communication platforms so that support staff, service accounts, and recovery operators are explicitly scoped and periodically recertified.
What's in the full article
SSH Communications Security's full article covers the operational detail this post intentionally leaves for the source:
- Specific details on the SalaX Secure Messaging deployment model and how it supports controlled hosting.
- The article's examples of sovereign cloud and supercomputing infrastructure in Italy and how they are positioned for national control.
- The vendor's explanation of encryption, identity assurance, and deployment flexibility in higher-security communication environments.
👉 Read SSH Communications Security's analysis of sovereign cloud control and secure messaging →
Data sovereignty and sovereign cloud controls: what IAM teams are missing?
Explore further
25/06/2026 2:22 am
Data sovereignty is an identity problem before it is a hosting problem. If the organisation does not control the privileged identities, keys, and administration paths around a platform, sovereignty is only a policy statement. Jurisdictional exposure becomes operational when access can be compelled, inherited, or mediated outside the intended boundary. The implication is that sovereignty programmes must be built around control of identity and privilege, not around deployment labels alone.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
A question worth separating out:
Q: Which controls matter most for sovereign messaging and AI workloads?
A: Focus on privileged access, key management, and deployment ownership. Those controls define whether the organisation can actually constrain who sees data, who can operate the system, and who can recover it. If those functions sit outside your governance model, the workload is not sovereign in practice.
👉 Read our full editorial: Data sovereignty gaps in sovereign cloud and secure messaging
