SAMA, ADGM and DFSA compliance exposes identity control gaps

At a glance

What this is: This is an identity and compliance analysis of how SAMA, ADGM, and DFSA expectations expose weaknesses in long-lived credentials, fragmented privileged access, and auditability across sovereign cloud environments.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that centralise access decisions, prove revocation, and produce evidence across cloud, on-premises, and third-party environments.

👉 Read Teleport's analysis of SAMA, ADGM, and DFSA identity requirements

Context

In sovereign cloud environments, the core problem is not only where data sits. The harder issue is whether identity, privileged access, and audit trails can be governed consistently enough to satisfy financial regulators across Saudi Arabia and the UAE.

The article focuses on cloud service providers operating under SAMA, ADGM, and DFSA requirements, where access control is expected to be demonstrable, centrally managed, and tightly limited. That places IAM and PAM design directly inside the compliance conversation, rather than treating them as back-end engineering choices.

For identity teams, the practical challenge is that long-lived credentials, VPNs, bastions, and platform-specific access controls fragment the evidence chain. When governance has to span human users, privileged operators, third parties, and machine identities, compliance depends on traceable lifecycle control, not just technical reachability.

Key questions

Q: How should security teams implement just-in-time privileged access in cloud environments?

A: Start with the most sensitive administrative paths, then require approval, session bounds, and automatic expiry for each elevation event. JIT works best when it is paired with central policy, strong logging, and a clear offboarding path for temporary rights. The goal is to make privilege a short-lived state, not a persistent account property.

Q: Why do long-lived machine credentials increase cloud risk?

A: Long-lived machine credentials create standing privilege, which gives attackers a reusable access path if the secret is exposed. In cloud environments, that risk compounds because credentials are often copied into code, pipelines, and configuration files, making discovery and lateral movement faster once a single secret is found.

Q: What breaks when privileged access is split across multiple tools and platforms?

A: The evidence chain breaks first. Teams may still have policy, MFA, and logging in separate systems, but they lose a single view of who accessed what, when, and under what authorization. That fragmentation forces manual log stitching and weakens the defensibility of the audit package.

Q: Who is accountable when a third-party identity can reach critical infrastructure?

A: Accountability sits with the organisation that allows the trust path to exist and remain active. Security teams should require documented access ownership, test revocation, and verify that supplier access is auditable across the full lifecycle, not just at onboarding.

Technical breakdown

Why sovereign cloud compliance makes identity the control plane

Sovereign cloud compliance shifts the control problem from infrastructure location to access governance. In this model, identity becomes the control plane because regulators expect proof of who accessed what, under which approval, and with what privilege boundary. SAMA, ADGM, and DFSA all emphasise centralized access management, MFA, prompt revocation, and auditable activity. That means the architecture has to unify authentication, authorization, and evidence collection across environments that often evolved separately. The weak point is usually not policy language, but the gap between policy and the session-level artefacts auditors require.

Practical implication: map every privileged path to a single evidence chain before auditors ask for it.

How long-lived credentials and bastions break auditability

Long-lived credentials and bastion-based access models create governance drag because they extend the trust window beyond the task itself. Once a credential persists, it becomes harder to prove that access was approved for a specific purpose, used only within scope, and removed on time. In regulated environments, that undermines the expectation of prompt revocation and recurring access review. The same problem appears with platform-specific controls that do not produce consistent logs or centralised review data. For cloud service providers, the issue is not only exposure. It is the inability to demonstrate disciplined access lifecycle control across distributed platforms.

Practical implication: replace persistent access paths with short-lived, session-scoped controls that leave reviewable evidence.

Why unified identity layers matter for third-party and machine access

A unified identity layer matters because regulatory expectations do not stop at employee access. Third-party operators, service accounts, workloads, and AI agents all create identity events that must be approved, limited, and audited. When those identities are managed separately, the organisation loses visibility into privilege sprawl and cannot easily show which actor performed a sensitive action. That is especially important where regulators expect least privilege, MFA for privileged access, and traceable administrative behaviour. The technical challenge is not just federation. It is aligning access policy, lifecycle management, and logging so that every actor type is governed under the same evidence model.

Practical implication: treat non-human and third-party identities as first-class audit subjects, not exceptions.

Threat narrative

Attacker objective: The objective is to gain durable privileged access that is difficult to detect, govern, or prove compliant after the fact.

1. Entry occurs through long-lived credentials, over-broad platform access, or third-party paths that are difficult to centralise across sovereign environments.
2. Escalation follows when privileged access is reused across systems without session-level limitation, MFA enforcement, or prompt revocation.
3. Impact appears as failed auditability, weak segregation of admin activity, and inability to prove compliance with regulator-defined access controls.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Identity governance, not data locality, is the real compliance battleground. The article correctly frames sovereign cloud rules as an access and evidence problem rather than a storage-only problem. SAMA, ADGM, and DFSA all care about who can act, how access is approved, and whether the activity can be proven later. That means identity architecture is now part of regulatory design, not a separate operational layer. Practitioners should treat access traceability as a control objective in its own right.

Persistent credentials create compliance debt that auditors eventually collect. Long-lived credentials, shared accounts, and bastion patterns extend the period in which access must be trusted without fresh proof. In regulated environments, that trust window is too wide to defend cleanly. The implication is that lifecycle discipline matters as much as policy intent, because governance fails when access outlives the session or the business need.

Third-party and machine identities must be governed with the same seriousness as human privileged users. The article points to unified identity for users, machines, workloads, and AI agents, which reflects where the market is heading. Once a non-human actor can touch regulated systems, the question is not whether it is automated, but whether it is attributable, limited, and revocable. Teams that still separate these identity classes will struggle to produce a coherent audit story.

Compliance evidence is becoming a runtime property, not a documentation exercise. Regulators in these markets are effectively asking for proof at the point of access, not after a quarterly control review. That shifts the burden onto identity systems that can enforce JIT access, record sessions, and centralize logs across heterogeneous infrastructure. The practitioners’ challenge is to make evidence continuously available instead of reconstructing it manually after the fact.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• That visibility gap is why the NHI Lifecycle Management Guide matters when access reviews, revocation, and audit evidence must survive regulatory scrutiny.

What this signals

Identity evidence is becoming a board-level compliance signal. For CSPs targeting regulated markets, the next maturity step is not another point control. It is proving that privileged access, third-party access, and non-human access can all be traced through a single lifecycle model. When access decisions are session-scoped and centrally logged, regulators can verify control intent instead of infer it from policy documents.

The practical shift is toward treating access reviews as operational proof, not periodic admin work. That means aligning PAM, NHI governance, and audit logging so that the evidence required for SAMA, ADGM, and DFSA is produced by design, not reconstructed after the fact.

Runtime controls will increasingly define compliance posture. As sovereign cloud expectations harden, organisations that still rely on persistent credentials and platform-specific exceptions will struggle to show control consistency. The organisations that can continuously revoke, attribute, and review access will have a stronger path to market entry and lower audit friction.

For practitioners

• Map every privileged access path to an audit owner Document who approves, who reviews, and who can revoke access for each privileged path, including third parties and machine accounts. If a path cannot be assigned a single accountable owner, it is already outside a regulator-friendly governance model.
• Replace persistent administrative access with session-scoped access Use just-in-time elevation, short-lived certificates, and per-session MFA so privileged access expires with the task. That reduces standing access and makes the approval record match the actual session window.
• Centralize logs across cloud, on-premises, and third-party paths Require a single reviewable trail for approvals, authentication events, privilege use, and revocation outcomes. If logs live only inside individual platforms, evidence collection will remain fragmented at audit time.
• Treat service accounts and AI agents as governed identities Put non-human identities into the same lifecycle discipline as human users, including provisioning, access review, and offboarding. Regulators will not care that an actor is non-human if it can still access regulated systems.
• Test revocation against real operational scenarios Validate that privileged access can be removed quickly during offboarding, incident response, or vendor change. If revocation depends on manual cleanup across multiple tools, the control is not operationally credible.

Key takeaways

• SAMA, ADGM, and DFSA expectations turn identity governance into a compliance control, not just an internal security practice.
• Long-lived credentials and fragmented access tooling create evidence gaps that are difficult to defend during audits.
• CSPs that centralize lifecycle control, short-lived access, and audit trails will be better positioned to meet sovereign cloud requirements.

Key terms

• Sovereign Cloud: A cloud deployment designed to keep data, operations, and governance within a defined jurisdiction or control boundary. In practice, sovereignty is only as strong as the identity controls that govern who can access the environment, how access is approved, and how quickly it can be revoked.
• Session-Scoped Access: Session-scoped access is permission that exists only for a defined task or time window and is expected to end when the task ends. For NHI governance, it reduces lingering authority and makes AI-driven activity easier to review, revoke, and investigate when behaviour changes.
• Access evidence chain: The linked record of approval, authentication, privilege use, and revocation that proves access was controlled properly. For regulated environments, the evidence chain is as important as the policy itself because auditors need to verify what happened, not just what was intended.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.

👉 Teleport's full article covers compliance detail on access control, auditability, and sovereign cloud operations

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.