How should cloud-first organisations build identity governance when legacy IGA tools do not fit their environment?

Cloud-first organisations should design identity governance around the systems they actually run, not around legacy Windows-centric assumptions. That means mapping applications, cloud platforms, and collaboration tools into one control model, then enforcing joiner mover leaver processes, access review, and policy-based approvals across them. The goal is consistent governance with enough automation to keep pace with change.

Why This Matters for Security Teams

Legacy IGA products were built around directory-centric enterprises where HR, Active Directory, and on-prem applications defined the identity model. Cloud-first organisations live in a different reality: SaaS apps, cloud control planes, service accounts, API keys, and automation pipelines all create entitlements outside the old joiner mover leaver flow. That mismatch leaves governance fragmented, slow, and often blind to high-risk access.

This is why modern identity governance has to be control-driven rather than platform-driven. The operating model should map to the systems actually in use, then apply consistent lifecycle, approval, and review rules across humans and NHIs. NHIMG’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which makes governance failures scale fast when access is not systematically managed. Current guidance from NIST Cybersecurity Framework 2.0 supports this broader control view rather than a tool-specific one.

In practice, many security teams discover their identity program is incomplete only after a cloud permission sprawl event, not through a planned governance design.

How It Works in Practice

Cloud-first identity governance starts by inventorying where identity decisions actually happen: SSO, cloud IAM, SaaS admin consoles, CI/CD systems, privileged access tooling, and NHI secret stores. From there, organisations define one policy model for access request, approval, review, and revocation, even if the enforcement points differ by platform. That usually means integrating the legacy IGA workflow where it still adds value, but not relying on it as the sole source of truth.

For humans, the core processes remain joiner mover leaver, periodic access review, and role-based approvals. For NHIs, the control model should extend to workload identities, API keys, certificates, and service accounts with short-lived credentials wherever possible. The aim is to reduce standing access and make governance measurable across both interactive and machine identities. NIST SP 800-53 Rev 5 helps here because its access control and audit requirements can be translated into cloud and SaaS enforcement points, not just directory administration.

A practical build-out often includes:

• Centralising entitlement data across cloud, SaaS, and infrastructure systems.
• Using policy-based approval workflows with context such as app criticality, data sensitivity, and privilege level.
• Automating deprovisioning and secret revocation when a user, workload, or service account changes state.
• Separating access review cadence by risk, so high-risk privileges are reviewed more frequently than routine access.

NHIMG’s Top 10 NHI Issues and Lifecycle Processes for Managing NHIs both reinforce the same operational point: governance fails when identities are created faster than they are reviewed, rotated, and retired. These controls tend to break down when organisations span multiple cloud tenants and SaaS admin models because entitlement data becomes inconsistent before reviews can complete.

Common Variations and Edge Cases

Tighter governance often increases administrative overhead, so organisations have to balance assurance against friction for platform teams and application owners. That tradeoff is especially visible when a cloud environment uses many ephemeral workloads, third-party integrations, or highly delegated admin rights.

There is no universal standard for how much legacy IGA should be retained versus replaced. Current guidance suggests preserving only the functions that remain dependable, such as policy orchestration and attestation, while shifting execution into cloud-native IAM, privileged access management, and secrets management layers. This is particularly important where legacy tooling cannot model non-interactive identities cleanly or cannot ingest fast-changing entitlement data in real time.

Another edge case is federated SaaS ownership. Business teams may control the application, security may control policy, and IT may control the source identity. In those environments, governance works best when ownership is explicit, approval paths are codified, and exceptions are time-bound. NHIMG’s Regulatory and Audit Perspectives is useful here because it frames the audit trail as a control outcome, not a reporting afterthought. The real failure mode is not lack of policy, but inability to prove who approved what, for which identity, and whether access was actually removed.

Related resources from NHI Mgmt Group

• What breaks when organisations separate identity governance and authorisation in cloud-first environments?
• How should organisations align identity governance with Zero Trust in a cloud-first and AI-driven environment?
• How should organisations approach identity governance when business applications, cloud infrastructure, and data access are all converging?
• How should organisations enforce identity governance across multi-cloud and AI-driven workflows?