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 management problem centered on keeping control of identities, credentials, and critical data across jurisdictions.

Why it matters: IAM teams need to treat sovereignty as a control-continuity issue because access governance becomes weaker when operational ownership, cloud location, and regulatory jurisdiction diverge.

By the numbers:

• 25% of Fortune 100 companies rely on SSH’s solutions.

Context

Data sovereignty means keeping control over where data is governed, who can access it, and which legal and operational boundaries apply. In this article, the issue is not just storage location. It is whether IAM, PAM, and secrets management still enforce control when identities and credentials are used across cloud providers, on-premises environments, and jurisdictions with different regulatory expectations.

That matters because many identity programmes still assume a relatively stable operating boundary. Once cloud deployment, compliance requirements, and cross-border access all converge, identity governance has to carry more of the burden of proving control continuity. The article frames the partnership as an attempt to reduce that gap by combining Zero Trust, quantum-safe encryption, and IAM expertise.

For IAM leaders, the practical question is whether access control, privilege management, and secret handling remain auditable and enforceable when the legal and technical chain of custody is fragmented. That is a typical challenge for regulated and distributed environments, not an edge case.

Key questions

Q: What breaks in IAM when data sovereignty spans multiple cloud providers and jurisdictions?

A: The main break is control continuity. If identity issuance, privilege elevation, and secret custody are split across providers or legal domains, teams may still have policy on paper but lose practical authority over access. That creates gaps in auditability, revocation, and accountability, especially when third parties help operate the environment.

Q: Why does data sovereignty increase the importance of PAM and secrets management?

A: Because sovereignty depends on who can actually exercise control, not just where the data is stored. Privileged access and secrets are the operational mechanisms that determine whether authority stays with the organisation when systems move across jurisdictions. Without tight governance, the sovereignty claim becomes mostly contractual.

Q: What are the signs that cross-border IAM governance is too fragmented?

A: Common warning signs include unclear ownership of identity operations, inconsistent privilege review across regions, duplicated secrets controls, and inability to prove who can revoke access in each environment. If compliance, cloud, and IAM teams cannot answer those questions quickly, the governance model is already fragmented.

Q: How should organisations separate identity governance from identity management?

A: Identity governance should own policy, role design, access certification, exception handling, and audit evidence. Identity management should own provisioning, authentication, directory updates, and routine access maintenance. Separating the two helps teams see whether they have only operational control or also defensible oversight. The test is whether each control can be assigned to one clear owner and measured independently.

Technical breakdown

Why data sovereignty changes IAM control boundaries

Data sovereignty changes the boundary problem for IAM because identity controls no longer sit inside one administrative or legal domain. When data, users, and infrastructure span multiple cloud providers and countries, access assurance depends on whether policy, privilege, and audit evidence travel with the workload. IAM, PAM, and secrets management become control planes for jurisdictional trust, not just authentication and authorisation layers. The real technical issue is preserving the chain from identity issuance to access use to revocation when each step may cross a different operational boundary.

Practical implication: Map where identity decisions are made, where secrets are stored, and where access is observed across every jurisdiction.

How Zero Trust and secrets management support control continuity

Zero Trust is relevant here because it assumes no implicit trust based on network location or hosting model. That matters when data sovereignty requirements force teams to prove that access is still governed even after assets move between on-premises systems and trusted cloud environments. Secrets management is equally central because tokens, keys, and certificates are the practical proof of access authority. If those credentials are not tightly governed, the sovereignty claim is only contractual, not operational. The technical test is whether access can be continuously constrained, rotated, and revoked without depending on the physical location of the workload.

Practical implication: Treat credential lifecycle and trust boundaries as part of the sovereignty design, not as separate hygiene tasks.

Why privilege management becomes a sovereignty control

Privileged access management is the enforcement layer that decides whether sovereignty is retained in practice or lost through overbroad administrator reach. In distributed environments, the highest risk is often not raw data movement, but privileged operators and service accounts retaining access after the business context changes. That is especially relevant where IAM transformation is being accelerated through managed services or external partners. The control challenge is to ensure elevated access remains narrow, time-bound, and traceable even when the infrastructure owner, the identity operator, and the compliance owner are not the same party.

Practical implication: Review privileged access paths for cross-border, cross-provider, and third-party administration exposure.

NHI Mgmt Group analysis

Data sovereignty is now an identity governance problem, not only a legal or hosting question. The article correctly places IAM, PAM, and secrets management at the center of sovereignty because control over data is only meaningful if control over access survives jurisdictional and cloud fragmentation. That shifts the discipline from where data sits to who can act on it, when, and under which authority. Practitioners should treat sovereignty as an access-governance outcome, not a location statement.

Control continuity is the named concept this partnership exposes. Sovereignty fails when organisations can no longer prove that identity authority, privilege scope, and secret custody remain consistent as workloads move across providers and regions. The issue is not whether encryption exists, but whether access controls remain bound to the same governance model after deployment changes. Practitioners need to design for continuous control continuity across the full identity lifecycle.

Cross-border cloud use makes privilege drift a sovereignty risk. Once infrastructure, operations, and compliance obligations are split, standing privilege and unmanaged administrator pathways become evidence that sovereignty has weakened in practice. That is why PAM cannot be treated as a separate control from IAM in distributed estates. The practitioner conclusion is that privilege scope must be governed with the same rigor as data residency claims.

Secrets management becomes part of regulatory credibility when data moves across jurisdictions. The article’s emphasis on critical data and trusted cloud environments shows that tokens, keys, and certificates are part of the sovereignty story, not just implementation details. If those credentials are loosely owned or poorly rotated, the organisation has lost practical control even if its policy says otherwise. The implication for teams is to align secrets governance with their sovereignty and compliance model.

IAM transformation programmes should be judged by whether they reduce authority fragmentation. The partnership reflects a market where regulated organisations want fewer seams between identity operation, access enforcement, and compliance reporting. That is a useful signal for practitioners because the next phase of identity maturity is not more tooling alone, but clearer authority lines across internal teams and external service providers. Teams should assess whether their current operating model can still answer who controls access when the environment spans multiple jurisdictions.

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: Ultimate Guide to NHIs — Regulatory and Audit Perspectives

What this signals

Control continuity: sovereignty programmes fail when access authority cannot be shown to persist across cloud providers, jurisdictions, and operating partners. Identity teams should assume that residency claims are only as strong as their privilege revocation and credential custody model.

For regulated organisations, the next governance step is to join IAM, PAM, and secrets management into one control narrative. That makes it easier to demonstrate who can grant, use, and remove access when data crosses legal boundaries.

Zero Trust is useful here because it removes the assumption that location implies trust. The practical test is whether access decisions remain enforceable after the workload or data set leaves the original administrative domain.

For practitioners

• Define sovereignty as an access-control requirement Document which identity, privilege, and secret-control decisions must remain under your organisation’s authority regardless of cloud location or hosting model.
• Trace cross-border identity control paths Map where identities are issued, where privileges are elevated, and where credentials are stored or rotated across each jurisdiction and provider.
• Review third-party administrative reach Check whether external IAM, PAM, or managed service partners can still enforce or bypass privileged access decisions after the environment moves to another domain.
• Align secrets governance with residency rules Verify that token, key, and certificate ownership, rotation, and revocation remain auditable when critical data is handled across borders.

Key takeaways

• Data sovereignty in this article is really about whether identity and privilege control remain intact when operations span clouds and jurisdictions.
• The strongest evidence is the article's focus on IAM, PAM, and secrets management as the mechanisms that preserve control over critical data.
• Teams should assess control continuity first, because a sovereignty claim that cannot be enforced through access governance will not hold up operationally.

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 Continuity: Control continuity is the ability to preserve a security or governance control while the underlying tool, process, or platform changes. In practice, it means the control still works after migration, retirement, or replacement without losing visibility, traceability, or policy enforcement.
• Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines, typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
• Privilege Access Management: Privilege Access Management is the discipline of controlling and monitoring elevated access to critical systems and data. It governs how privileged accounts, credentials, sessions, and commands are issued, used, recorded, and revoked, so administrative power is limited, traceable, and aligned to policy, risk, and operational need.

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.