SSH and Intragen partnership reframes data sovereignty for IAM teams

At a glance

What this is: SSH Communications Security and Intragen are positioning data sovereignty as an IAM, PAM, and secrets-governance problem that spans jurisdictions, clouds, and on-premises environments.

Why it matters: For IAM teams, this is a reminder that identity control, credential governance, and access accountability have to survive cross-border operating models, not just local deployments.

By the numbers:

• 25% of Fortune 100 companies rely on SSH’s solutions.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.

👉 Read SSH Communications Security's partnership note on data sovereignty and IAM

Context

Data sovereignty in IAM means keeping control over identities, credentials, and access decisions even when data, systems, and administrators span multiple jurisdictions. This partnership lands in a governance gap that many enterprise identity programmes still treat as a legal or infrastructure issue rather than an identity control problem.

The practical challenge is not the encryption layer alone. It is whether IAM, PAM, and secrets management can preserve auditability, least privilege, and revocation authority when workloads move between on-premises estates and trusted cloud environments, especially in regulated sectors.

That makes the topic relevant to human identity programmes, NHI governance, and emerging autonomous access models alike. The same control question repeats across all three: who retains effective authority over the credential, the session, and the data path when operational control is distributed?

Key questions

Q: How should security teams govern identities in cross-border cloud environments?

A: Security teams should govern identities in cross-border cloud environments by treating access, privilege, and credential custody as one control chain. That means lifecycle rules, revocation authority, and audit evidence must remain consistent across jurisdictions. If those controls fragment, sovereignty becomes a policy claim rather than an enforceable operating model.

Q: Why do IAM and PAM matter to data sovereignty programmes?

A: IAM and PAM matter because sovereignty is only real when the organisation can prove who accessed data, limit how privileged access is used, and revoke it quickly when conditions change. Without that control, data may remain encrypted while access remains effectively uncontrolled.

Q: What breaks when secrets management is separated from identity governance?

A: When secrets management is separated from identity governance, credentials can outlive approvals, regions, or vendor relationships. That creates a mismatch between who is supposed to control access and who actually can. The result is weak revocation, poor auditability, and higher risk in distributed estates.

Q: Who is accountable when data sovereignty controls fail?

A: Accountability should sit with the teams that own identity lifecycle, privileged access, and secret custody, not just with infrastructure or legal teams. If access is spread across cloud, on-premises, and third-party operations, governance needs one owner for the full access chain, including evidence and revocation.

Technical breakdown

Data sovereignty as an identity control problem

Data sovereignty is often discussed as where information resides, but identity teams have to treat it as a control-plane issue. If access to data crosses borders, the identity that authorises access, the credential that proves it, and the logs that record it may all sit in different jurisdictions. That creates tension between legal control, operational control, and audit control. IAM and PAM are the mechanisms that make sovereignty enforceable in practice, because without revocation, session control, and entitlement traceability, sovereignty is only a policy statement.

Practical implication: Map sovereignty requirements to identity controls, not just hosting locations, and verify that revocation and audit trails remain under your authority.

Why IAM, PAM, and secrets management have to work together

IAM establishes who or what should get access, PAM limits how high-risk access is used, and secrets management governs the credentials that make machine and human access possible. In a cross-border environment, those functions cannot be separated cleanly, because a credential without lifecycle control or a privileged session without tight scope can defeat the sovereignty objective. The architectural point is simple: sovereignty fails when identity proof, privilege elevation, and secret custody are managed as disconnected systems instead of one governance chain.

Practical implication: Review whether IAM, PAM, and secrets handling share the same offboarding, approval, and audit model across regions and cloud estates.

Zero Trust and quantum-safe encryption in sovereign architectures

Zero Trust is relevant here because sovereignty depends on continuous verification, not implied trust in the network or hosting location. Quantum-safe encryption adds a forward-looking confidentiality layer, but it does not solve entitlement sprawl or privilege persistence. The combination only matters if identity proof remains strong, sessions are continuously constrained, and access decisions are re-evaluated as data moves. That is why sovereign architecture is as much about access governance as it is about cryptography.

Practical implication: Use Zero Trust principles to validate every access path and treat encryption as complementary to, not a replacement for, identity governance.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Data sovereignty is an identity governance problem before it is a legal or hosting problem. The article frames sovereignty as control over identities, credentials, and data paths across jurisdictions, and that is the right ordering. If IAM cannot preserve authority over who can access what, then sovereignty becomes geographically distributed but operationally fragile. Practitioners should treat sovereignty controls as part of identity architecture, not as a compliance overlay.

IAM, PAM, and secrets management break down when they are governed as separate domains. The partnership message points to a real enterprise pattern: identity, privilege, and credential custody often live in different control stacks. That separation weakens revocation, session governance, and evidence quality when systems span on-premises and cloud boundaries. The practical conclusion is that sovereign access cannot be assured if lifecycle control is fragmented.

Cross-border control demands a stronger notion of accountability than most access models provide. The moment a credential or session can be used across regions, the question is no longer just who has access, but who can still prove and revoke that access when jurisdiction changes. This is a Zero Trust and NHI governance issue at the same time, and it will become more visible as regulators scrutinise digital sovereignty claims.

Quantum-safe encryption protects data, but it does not solve governance debt. Encryption reduces exposure of content, yet entitlement sprawl, over-privilege, and unclear session ownership still create operational risk. That means enterprises can be technically encrypted and still politically or operationally non-sovereign. Practitioners should not confuse stronger cryptography with complete control over access authority.

Named concept: sovereign identity control plane. This article points to a governance model where identity, privilege, and credential management are treated as the control plane for data sovereignty. That concept matters because it shifts the discussion from location-based trust to enforceable authority over access wherever the data travels. Teams should use that framing when designing cross-border IAM programmes.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• For a broader identity baseline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle patterns that also matter when access crosses borders.

What this signals

Sovereign identity control plane: enterprises will increasingly judge data sovereignty by whether IAM, PAM, and secrets management can enforce the same authority across cloud regions and legal boundaries. That shifts the programme conversation from platform placement to control continuity, which is where most governance debt becomes visible.

The operational signal is that encryption alone will not satisfy auditors, regulators, or incident responders if revocation and evidence remain fragmented. Teams should expect more scrutiny of cross-border access chains, especially where privileged sessions and machine identities can traverse multiple environments without a single control owner.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, sovereignty programmes need to include delegated access and third-party identity paths, not just internal users and workloads.

For practitioners

• Inventory cross-border access paths Identify every identity, service account, and privileged workflow that can reach data across jurisdictions, then document where approvals, logs, and revocation controls actually sit. The goal is to expose any gap between legal ownership and operational authority.
• Unify lifecycle control for IAM, PAM, and secrets Align provisioning, elevation, rotation, and offboarding so that credentials cannot outlive the policy domain that created them. If a credential can move faster than your governance process, sovereignty is already weakened.
• Test revocation under jurisdiction change Run scenarios where access must be withdrawn while a session is active in another region or cloud tenant. Validate whether your controls can terminate the session, revoke the secret, and preserve evidence without relying on manual intervention.
• Apply Zero Trust to sovereign data flows Require continuous verification for every access path that touches regulated or cross-border data, including privileged admin pathways and machine identities. Pair that with explicit trust boundaries for cloud and on-premises estates.

Key takeaways

• Data sovereignty fails as an identity control problem when IAM, PAM, and secrets governance do not preserve authority across jurisdictions.
• Cross-border access can remain technically encrypted while still being operationally non-sovereign if revocation and auditability are fragmented.
• Practitioners should align identity lifecycle controls to the data path, because sovereignty depends on enforceable access authority, not just hosting location.

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.
• Sovereign Identity Control Plane: A sovereign identity control plane is the combined IAM, PAM, and secrets-management layer that enforces authority over access regardless of where data is hosted. It matters because sovereignty fails when credentials, sessions, and audit trails are governed in separate places.
• Cross-Border Access Chain: A cross-border access chain is the sequence of identity, privilege, and credential events that allows a user, service, or admin session to reach data across jurisdictions. It is the unit practitioners should assess when testing revocation, logging, and accountability.
• Trusted Cloud Environment: A trusted cloud environment is a cloud setting that an organisation permits for sensitive workloads under defined governance and security conditions. The trust exists only when identity controls, session limits, and evidence retention remain consistent with policy.

Deepen your knowledge

Data sovereignty, IAM, PAM, and secrets governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a cross-border identity model, it is worth exploring.

This post draws on content published by SSH Communications Security: the partnership with Intragen on data sovereignty, IAM, PAM, and zero trust. Read the original.