Top 10 IGA Mistakes: The Errors That Undermine Access Governance and Their Fixes

Identity governance and administration (IGA) programmes rarely fail because the platform is missing a feature; they fail because the processes around it let access drift away from what the business actually approved. This page ranks the ten IGA mistakes that most often leave organisations with leavers who still have access, movers who keep every entitlement they ever held, and access reviews that certify everything. For each one you get the symptom, how to detect it in your own environment and the fix. The recommendations draw on the NSA and CISA Enduring Security Framework guidance on identity and access management, NIST SP 800-53 Rev. 5 and the OWASP Non-Human Identities Top 10. It is written for identity architects, IGA programme owners, auditors and the executives who sponsor them. To place your programme on a scale first, read the Identity Governance Maturity Model; this page is the list of what to fix.

The Top 10 at a glance

1. Running IGA as a technology project with no business owners
2. Trusting an incomplete or unreliable source of identity data
3. Ignoring movers, so privileges accumulate
4. Treating "disable the directory account" as the whole leaver process
5. Governing only the applications behind single sign-on
6. Access reviews that certify everything
7. Role explosion, or roles copied from existing users
8. Checking segregation of duties only at review time
9. Leaving non-human identities outside governance
10. Never reconciling approved access against actual access

1. Running IGA as a technology project with no business owners

IGA gets bought by the identity team, deployed by integrators and then handed to nobody. The platform can route an approval or a review, but only an application owner or data owner can say whether "AP_INVOICE_APPROVER_L2" is appropriate for a given person. The NSA and CISA guidance puts this squarely on application and data owners: they should be able to review and reconcile access periodically. NIST CSF 2.0 GV.RR-02 asks for cybersecurity roles, responsibilities and authorities to be established and enforced, which in IGA terms means every application and every privileged entitlement has a named owner.

Detect it: pick twenty entitlements at random and ask who owns each one and what it allows. If the answer is "the identity team" or "we would have to ask the vendor", the programme has no business ownership. Another signal is review campaigns routed to IT staff because the business owner field is empty.

Fix: write a RACI for the programme: the business sponsor, the IGA platform owner, application owners, entitlement owners and line managers. Make "owner named and entitlements described in plain language" an exit criterion for onboarding any application. See the Entitlement Catalogue Guide.

2. Trusting an incomplete or unreliable source of identity data

Automated joiner and leaver processing is only as good as the record that drives it. The NSA and CISA guidance describes building identity records from recruiting, HR and personnel security systems and creating accounts from that data. The mistake is assuming the HR system holds everyone. Contractors, agency staff, interns, volunteers, partners and auditors often sit in procurement, a spreadsheet or nowhere, so their accounts are created by hand and never leave on time.

Detect it: join active directory and identity provider accounts to the authoritative sources by employee or person ID. Every account with no match is either a non-human identity, a person outside your source of truth, or an orphan. Count accounts for non-employees with no end date.

Fix: define an authoritative source for each population (HR for employees, a vendor management or sponsor register for contractors and guests) and make an end date mandatory for every non-employee record, with the sponsor asked to renew before it passes. Data quality rules, such as no record without a manager and no future-dated leaver left unprocessed, belong in the IGA platform, not in a report someone reads monthly.

3. Ignoring movers, so privileges accumulate

Joiners and leavers get automated first because they are easy to see. Movers, people who change team, location or role, are where access piles up. The NSA and CISA guidance states that long-term users tend to accumulate privileges as their roles change, and recommends that a mover event both grants the access the new role needs and removes the access it no longer needs. NIST SP 800-53 PS-5 Personnel Transfer makes the same point: review and confirm ongoing need for current access when someone is reassigned.

Detect it: compare each user's entitlement count with the median for their job code or peer group. People in the top few per cent are almost always long-serving movers. Also count mover events in the last year and how many produced a removal.

Fix: process a mover as a leaver from the old role plus a joiner to the new one, with a defined grace period (30 days is an illustrative starting point) during which the old manager can request an extension with a reason. Trigger a targeted review of the person's access by the new manager at the end of the grace period. The Joiner-Mover-Leaver Guide covers the full event model.

4. Treating "disable the directory account" as the whole leaver process

Disabling the directory account stops new single sign-on logins. It does not end sessions already open, accounts held locally in SaaS or legacy applications, personal access tokens, API keys the person created, shared passwords they knew or signing keys they could reach. The NSA and CISA guidance lists former employees whose access was not turned off as an insider threat category and says accounts and privileges must be promptly terminated, with the governance system keeping a record of all access tied to the individual. NIST SP 800-53 PS-4 Personnel Termination asks for system access to be disabled within a defined time, authenticators and credentials to be revoked, and the person's access to information they controlled to be retained by the organisation.

The Coupang breach shows the cost of a leaver process that stops at human accounts. According to government findings summarised on that page, a developer who left at the end of 2024 still held a token signing key that was never revoked or rotated, and used it to forge access tokens and query customer data from April to November 2025, with about 33.7 million accounts reported affected.

Detect it: take last quarter's leavers and search for their email address or employee ID in the admin console of each major SaaS application, the code hosting platform, the cloud providers and the password manager. Any hit is a leaver failure. Separately list secrets and keys created by, or accessible to, recent leavers that have not been rotated since their exit date.

Fix: make the leaver process an inventory of everything tied to the person, not one action. Revoke sessions and refresh tokens, disable local application accounts, transfer ownership of non-human identities, and rotate any shared or high-value secret the person could read. The Employee Offboarding Security Checklist is a per-leaver template for this.

5. Governing only the applications behind single sign-on

Programmes start with the applications that have connectors and SCIM support, then stall. The applications left over are often the riskiest: ERP and finance systems with their own user tables, HR and payroll, line-of-business systems, databases, and operational technology. If those are outside IGA, joiners, movers, leavers and reviews skip them entirely.

Detect it: compare the IGA application catalogue with the CMDB or the list of applications in scope for SOX, PCI DSS or regulatory audit. The percentage of in-scope applications governed by IGA is the single best coverage metric. Ask auditors which applications produced user access findings last year.

Fix: onboard disconnected applications with whatever fulfilment is available: a nightly account file for visibility and reviews, plus ticket-based provisioning and deprovisioning with a service level and closed-loop confirmation. Prioritise by risk, not by ease of integration. The Entitlement Catalogue and Application Onboarding Guide sets out a repeatable onboarding pattern.

6. Access reviews that certify everything

A quarterly campaign that asks a manager to approve 900 line items with cryptic entitlement names produces an approve-all click, not a decision. Auditors increasingly test the quality of reviews, not just their completion: an ISACA guide to verifying user access reviews describes requesting justification for questionable access, keeping records of responses and documenting the remediation that followed. NIST SP 800-53 AC-6(7) Review of User Privileges asks for privileges to be reviewed at a defined frequency and reassigned or removed when no longer needed, which only works if reviewers actually remove things.

Detect it: measure approval rate per reviewer, median time per decision and the number of campaigns closed with zero revocations. A reviewer approving 100% of several hundred items in under ten minutes is a finding. So is a campaign where revoked access was never actually removed from the target system.

Fix: review less, better. Exclude birthright access granted by policy, focus campaigns on privileged, sensitive and out-of-pattern entitlements, show last-used dates and peer comparison beside each item, and add event-driven micro reviews after a move or a long absence. Close the loop by checking that revocations reached the target. See the Access Reviews Guide and the Access Review Checklist.

7. Role explosion, or roles copied from existing users

Role-based access control is meant to simplify, and the NSA and CISA guidance recommends role-based group assignments to support least privilege. Two opposite mistakes break it. Mining roles straight from current access copies years of privilege creep into the role model. Creating a new role for every exception produces role explosion, where there are more roles than people in some teams and nobody can review what a role contains.

Detect it: count roles per hundred users, roles with a single member and roles not reviewed in the last year. High numbers of single-member roles mean the model has become a list of exceptions.

Fix: design business roles top down from job functions with the business owner, use mined data to validate and to spot outliers rather than to define the role, and give each role an owner and a content review cycle. Keep roles coarse and handle genuine exceptions as time-bound individual requests. The Role Mining and Role Design Guide goes deeper, and the Authorisation Models Guide covers when attributes beat roles.

8. Checking segregation of duties only at review time

NIST SP 800-53 AC-5 Separation of Duties asks organisations to identify and document duties that need separating and to define access authorisations that support that separation. Many programmes write an SoD rule set and then only run it as a detective report during the annual review. By then a person may have created and approved their own payments for months. The NSA and CISA guidance recommends using SoD policy rules to find and remove risky combinations of privileges.

Detect it: count SoD violations found by detective scans that were not flagged at request time, and the number of open mitigated violations with no compensating control owner or expiry.

Fix: define rules at the business activity level (for example, create supplier and approve payment) and map them to entitlements in each application. Check the rules preventively when access is requested, so the approver sees the conflict, and detectively every night. Every accepted violation needs a compensating control, an owner and an expiry date. The Segregation of Duties Guide and the Segregation of Duties Matrix Template help build the rule set.

9. Leaving non-human identities outside governance

Service accounts, API keys, OAuth applications, automation identities and AI agents now outnumber people in most environments, yet many IGA programmes govern only workforce accounts. The NSA and CISA guidance says service and system accounts should be created or granted privileges only through approved, documented change requests, and should get the same entitlement policies, monitoring and access reconciliation as user accounts. The OWASP Non-Human Identities Top 10 (2025) ranks NHI1 Improper Offboarding and NHI5 Overprivileged NHI among the leading risks.

Detect it: count non-human identities with no named human owner, with no last-used date in the last 90 days, or with credentials older than your rotation policy. If you cannot produce the count at all, the inventory itself is the gap.

Fix: give every non-human identity an owner, a purpose, a linked application and a review cycle, and route owner changes through the leaver process so an NHI is never orphaned when its creator leaves. Highly privileged accounts belong in privileged access management as well; see the Top 10 PAM Mistakes. For the full non-human lifecycle read the NHI Offboarding and Decommissioning Guide and the Identity Governance for AI Agents Guide.

10. Never reconciling approved access against actual access

An IGA platform shows the access it granted. Administrators with console rights can still create accounts and add group members directly in the target system, and those changes never appear in the request history. The NSA and CISA guidance recommends maintaining an inventory of active accounts and privileges, reconciling account creation and changes against approved requests, and monitoring account creation events to identify unauthorised accounts. NIST SP 800-53 AC-2(4) Automated Audit Actions asks for account creation, modification, enabling, disabling and removal to be audited automatically, which supplies the raw data.

Detect it: run a full aggregation from each target and compare it with the IGA model. Count "rogue" accounts and entitlements with no matching request or policy, and dormant accounts with no sign-in for 90 days (an illustrative cut-off; set your own). In Windows domains, account creation (event 4720) and additions to security groups (4728, 4732, 4756) that do not match an IGA fulfilment record are worth alerting on.

Fix: schedule reconciliation for every connected application, at least daily for privileged systems, and decide per application whether out-of-band changes are reverted automatically or raised for review. Feed the same results to the security operations team. The Orphaned and Dormant Accounts guide covers the clean-up.

Measuring whether governance is working

Report these monthly to the programme sponsor. A falling number of rogue accounts and a rising revocation rate are better evidence of maturity than campaign completion percentages.

Mapping to OWASP

IGA is largely a process discipline, so the OWASP mapping is narrow: the non-human identity mistakes map to the OWASP Non-Human Identities Top 10 (2025), and the rest map better to NIST SP 800-53 and MITRE ATT&CK, where abuse of leftover access appears as Valid Accounts.

In NIST CSF 2.0 the programme sits mainly under PR.AA-01 (identities and credentials for users, services and hardware are managed) and PR.AA-05 (access permissions are defined in policy, managed, enforced and reviewed, following least privilege and separation of duties). In ISO/IEC 27001:2022 Annex A the relevant controls are 5.3 Segregation of duties, 5.15 Access control, 5.16 Identity management, 5.18 Access rights and 8.2 Privileged access rights. See the OWASP NHI Top 10 NHI1 Improper Offboarding Guide for the non-human side.

Where to start

If you can do only three things this quarter: run a leaver audit across SaaS, code platforms, cloud and secrets for last quarter's leavers and fix every hit (mistake 4); reconcile the five most sensitive applications against approved access and remove rogue accounts (mistake 10); and redesign the next review campaign around privileged and out-of-pattern access with revocation confirmed in target (mistake 6). Then tackle movers (mistake 3) and the non-human identity inventory (mistake 9).

Smaller organisations without a dedicated IGA platform can still apply most of these fixes with an HR-driven identity provider, SCIM provisioning for the main SaaS applications, a spreadsheet-backed review for the rest and a written leaver runbook. Larger and regulated organisations need preventive SoD, automated reconciliation for every in-scope application and an owner model that scales; if you are selecting or replacing a platform, use the IGA Buyer's Guide and the IGA RFP Template.

Practitioner checklist

• Every governed application and privileged entitlement has a named business owner and a plain-language description.
• Each person type (employee, contractor, guest, partner) has an authoritative source and every non-employee record has an end date.
• Mover events remove old-role access after a defined grace period, followed by a review by the new manager.
• The leaver process covers SaaS local accounts, tokens, API keys, shared secrets and signing keys, not only the directory.
• Coverage of in-scope applications is measured, and disconnected applications are onboarded with file or ticket fulfilment.
• Review campaigns are risk-based, show usage and peer context, and confirm that revocations reached the target.
• Business roles have owners and content reviews; single-member roles are tracked and reduced.
• SoD rules are checked at request time and nightly, and accepted violations have a compensating control, owner and expiry.
• Non-human identities are inventoried with owners, purpose and review cycles.
• Approved access is reconciled against actual access on a schedule, and out-of-band changes are reverted or reviewed.

Standards and references

• NSA and CISA: Identity and Access Management Recommended Best Practices for Administrators
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• OWASP: Non-Human Identities Top 10 (2025)
• ISACA: User Access Review Verification, A Step-by-Step Guide
• MITRE ATT&CK: Valid Accounts
• MITRE ATT&CK: Account Manipulation

Related NHI Mgmt Group resources: Identity Governance Maturity Model · Access Reviews Guide · Joiner-Mover-Leaver Guide · Segregation of Duties Guide · IAM and IGA Basics