IAM compliance gaps show why governance must go beyond access

At a glance

What this is: This is an analysis of why IAM can show access exists, while IGA is needed to prove that access is appropriate, reviewed, and remediated for audit purposes.

Why it matters: It matters because IAM and IGA are often conflated in practice, leaving audit teams with access data but not the evidence chain compliance frameworks expect.

Context

IAM compliance gaps appear when organisations treat access control as if it were the same thing as access governance. IAM answers who can log in and what they can reach, but audit teams usually need proof of approval, review, remediation, and removal.

In identity programmes, that means the control problem is not just access event management. It is the lifecycle evidence around who authorised access, when it was recertified, whether exceptions were approved, and whether excess privileges were actually removed.

Key questions

Q: What breaks when IAM is used without IGA oversight?

A: IAM can provision and enforce access correctly while still leaving the enterprise unable to prove that access remains appropriate. Without IGA, organisations lose the evidence layer for certifications, separation of duties, and lifecycle validation. The result is functional access control with weak governance assurance.

Q: Why do auditors care about governance evidence beyond access control?

A: Auditors are testing whether access was authorised for a valid business reason and whether it stayed aligned to policy. A user can have technically valid access and still create a compliance issue if no one can prove who approved it, when it was reviewed, or whether excess rights were removed after the role changed.

Q: How do organisations know whether access reviews are working?

A: Access reviews are working when they lead to timely removals, reduced exception volume, and role definitions that stop accumulating unused rights. If the same accounts keep reappearing with the same excess access, the review process is only producing paperwork. Evidence of change is the real success signal.

Q: What is the difference between IAM and IGA when teams are accountable for compliance?

A: IAM is responsible for making access work securely and efficiently, while IGA is responsible for proving that access remains appropriate, reviewed, and compliant. In practice, IAM answers who can get in and how, and IGA answers whether that access should continue. Mature programs need both, because operational access control alone does not satisfy governance obligations.

Technical breakdown

Why IAM satisfies access questions but not audit evidence

IAM is designed to authenticate users, assign roles, and enforce access at the point of login or request. It can show that a user belongs to a group, holds a role, or passed MFA, but that is only a snapshot of entitlements. Compliance reviews ask a different question: whether the access was approved for a business reason, reviewed at intervals, and corrected when it no longer matched the role. Without governance records attached to the access record, technically valid access can still be audit-invalid.

Practical implication: treat IAM as the enforcement layer and IGA as the evidence layer, or audit readiness will remain incomplete.

How access reviews and certification close the lifecycle gap

Access reviews, also called user access certification, add a decision layer around existing entitlements. A reviewer must confirm whether access is still needed, record approval or rejection, and trigger remediation when permissions are excessive. This matters because access often accumulates through role changes, contractor renewals, and one-off exceptions that never get cleaned up. Certification campaigns turn static permissions into governed outcomes, which is what auditors look for when they ask who reviewed the access and what changed afterward.

Practical implication: build recurring certification workflows for sensitive entitlements so every review produces a decision, a timestamp, and a removal path if needed.

Where segregation of duties and remediation tracking change the compliance picture

Segregation of duties, or SoD, checks whether one identity holds conflicting permissions that could enable fraud or operational abuse. IAM alone may assign the roles correctly from a technical perspective, yet still leave toxic combinations in place across finance, procurement, billing, or privileged administration systems. IGA adds policy checks, exception handling, and remediation tracking so teams can prove that risky combinations were found, reviewed, and resolved. That closes the loop between finding the problem and documenting the fix.

Practical implication: use SoD policy checks and remediation workflows together, because discovery without tracked removal still leaves an audit finding open.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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

NHI Mgmt Group analysis

IAM compliance gaps are governance failures, not authentication failures. The article’s core point is that an identity programme can be technically effective and still fail audit scrutiny if it cannot prove approval, review, and removal. That distinction matters because compliance teams are judging control evidence over time, not just access at a point in time. The practitioner conclusion is simple: access control does not equal access accountability.

IGA exists to turn entitlements into defensible evidence. Access reviews, certification, SoD checks, and remediation tracking are not optional extras on top of IAM. They are the mechanism that turns a valid role assignment into a provable governance outcome. For security architects, this means the programme boundary must include decision records and exception handling, not just provisioning logic.

Privilege creep is the hidden compliance debt inside otherwise working IAM estates. Users move roles, contractors age out, and privileged accounts persist long after the original justification has faded. The compliance problem is not always that the wrong person can log in. It is that the organisation cannot show why the permission is still there. The practitioner implication is to treat excess access as a lifecycle defect, not an isolated exception.

Audit-ready identity programmes need a named owner for every high-risk entitlement. When nobody owns review responsibility, evidence quality degrades into ticket scavenging and spreadsheet reconciliation. That is why governance accountability must sit with the business function closest to the risk, while IAM supplies the technical record. The practical conclusion is that ownership, not tooling alone, determines whether access can be defended in an audit.

Access governance must follow the same lifecycle logic across human, contractor, and privileged access. The source problem is not limited to one user category. If joiner, mover, and leaver events do not reliably trigger review and removal, compliance gaps will recur in every identity class that lacks lifecycle control. The practitioner conclusion is to align governance workflows to lifecycle events, not organisational convenience.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: Access Reviews and Certification Guide

What this signals

Governance evidence is becoming the real control plane for audit readiness. As enterprises add more SaaS applications, contractor access, and privileged roles, the gap between entitlement data and defensible evidence widens. Programmes that stop at provisioning will keep producing audit friction because they cannot show the approval, review, and remediation chain in one place.

Access lifecycle discipline is the difference between a working identity stack and a compliant one. The practical shift is to treat joiner, mover, and leaver handling as an evidence-producing process, not an HR afterthought. When lifecycle events reliably trigger review and removal, compliance findings become easier to prevent rather than explain away.

For practitioners

• Define access ownership for every high-risk entitlement Assign a business owner and a technical owner for sensitive applications, privileged roles, and regulated data access so review responsibility is never ambiguous.
• Run recurring access certification campaigns Schedule reviews for finance, healthcare, customer data, and administrative entitlements so reviewers can approve, reject, or exception-handle access with traceable evidence.
• Link joiner-mover-leaver events to access change workflows Trigger review or removal when users change roles, move departments, or leave so old access does not persist after the original justification ends.
• Automate segregation of duties policy checks Scan for conflicting entitlements across procurement, vendor setup, payment approval, payroll, and similar control pairs before those conflicts become audit findings.
• Track remediation to completion, not just detection Require every rejected entitlement or review exception to have a documented removal, an approved exception, or a closed remediation record with timestamps.

Key takeaways

• IAM alone can enforce access, but it cannot prove that access was approved, reviewed, and removed when no longer needed.
• The compliance risk is governance drift, where technically valid permissions accumulate without a clear evidence trail.
• A stronger programme pairs IAM enforcement with IGA certification, SoD checks, and remediation tracking.

Key terms

• Identity Governance and Administration (IGA): A framework of policies, processes, and technology to manage and govern digital identities and their access rights. Increasingly extended to cover non-human identities alongside human users.
• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Privilege Creep: Privilege creep is the gradual accumulation of access rights beyond what an identity actually needs. It usually happens when permissions are added for convenience and never removed. For NHIs, privilege creep expands blast radius and makes old credentials far more dangerous than their original purpose suggests.

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.