How should organisations modernise IGA when identity risk spans multiple business applications and cloud systems?

Modern IGA should centralise governance across applications, automate routine checks, and maintain real-time visibility into who has access to what. The goal is to replace manual reviews and fragmented controls with continuous governance, so access decisions are based on current risk and business context instead of stale spreadsheets or periodic point-in-time attestations.

Why This Matters for Security Teams

When identity risk spans SaaS, cloud, and internal applications, IGA stops being a periodic review exercise and becomes a control plane problem. Manual certifications cannot keep pace with account sprawl, inherited entitlements, or changes driven by automation. That gap is visible in NHIMG research: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which means access governance is often working from incomplete data rather than current reality. The pattern is especially dangerous when business applications each maintain their own local role model.

Modernisation matters because inconsistent identity data creates false confidence. A user may look compliant in one system while retaining dormant access in another, or a machine identity may remain active long after the workflow that created it has changed. Current guidance from the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs both point toward continuous visibility and governance as the practical answer. In practice, many security teams encounter access drift only after an audit finding, not through deliberate governance.

How It Works in Practice

Modern IGA should aggregate identity and entitlement data from every authoritative source, then normalise it into a common governance layer. That means pulling joiner, mover, and leaver events from HR, privilege data from PAM, app roles from SaaS platforms, cloud entitlements from hyperscalers, and API or service account inventory from infrastructure tooling. The goal is not just reporting. It is to make access state actionable so reviews, approvals, and remediation can be automated at scale.

Practitioners usually need four capabilities working together:

• Identity correlation across human and non-human accounts so the same person or workflow is not tracked separately in each tool.
• Continuous entitlement monitoring so privilege changes are detected between review cycles.
• Policy-driven certification workflows that route exceptions to the right owner instead of sending blanket attestations.
• Automated remediation for stale, orphaned, or excessive access, especially where secrets and service accounts are involved.

The strongest programmes also add business context. Access to a finance app, a production cloud subscription, or a CI/CD token should be assessed differently based on data sensitivity, function, and blast radius. That is why the NIST control family in NIST SP 800-53 Rev. 5 Security and Privacy Controls remains relevant: it supports consistent access enforcement, accountability, and review discipline across diverse systems. NHIMG’s Top 10 NHI Issues shows why this matters: excessive privilege and poor rotation are not edge cases, they are the default failure mode when identity governance is fragmented.

These controls tend to break down when organisations keep app-specific role models, because the governance layer cannot reliably reconcile who owns which entitlement or whether a change in one system should trigger revocation in another.

Common Variations and Edge Cases

Tighter governance often increases integration and review overhead, requiring organisations to balance control depth against the complexity of legacy platforms. That tradeoff is real when the environment includes home-grown applications, multiple cloud tenants, or workloads that create ephemeral identities faster than human teams can review them. Best practice is evolving, but there is no universal standard for how much entitlement data must be centralised before modern IGA is considered effective.

Some environments should prioritise governance by risk tier rather than by complete system coverage. For example, production systems, regulated data stores, and privileged automation paths should be unified first, while lower-risk collaboration tools can follow later. In hybrid estates, local application owners still need accountability for access decisions, but the central IGA layer should enforce policy consistency and keep a single audit trail. NHIMG’s 52 NHI Breaches Analysis underscores a practical lesson: fragmented ownership and delayed revocation are common traits in real incidents, not theoretical weaknesses. Organisations that modernise IGA successfully usually start with the highest-risk identity paths, then extend governance outward as data quality improves.

Related resources from NHI Mgmt Group

• Why do organisations move identity governance from on premises systems to cloud platforms?
• Why do organisations with low identity maturity face higher security and business risk?
• Should organisations modernise ERP governance before moving systems to cloud applications?
• Who is accountable when access risk spans multiple business applications?