Identity and access management produces more audit findings than almost any other control area, and the same ten issues account for most of them. Whether the audit is a SOX IT general controls review, an ISO/IEC 27001 certification audit, a PCI DSS assessment or an internal audit of access management, auditors test the same things: that access is granted on approval, removed on time, reviewed properly, separated where it must be and strongly authenticated where it is privileged. This list explains each common finding, what the auditor actually tests, why the finding matters beyond the audit, and how to fix the process so it does not recur. It is written for IAM leads, control owners and the internal audit and GRC teams who work with them.
The Top 10 at a glance
The ten identity audit findings raised most often, what auditors test for each, and how to fix the process, mapped to NIST SP 800-53, ISO 27001 and CSF 2.0. Each item is explained below with what to fix first.
| # | Finding | What the auditor usually samples | Primary control reference |
|---|---|---|---|
| 1 | Leavers' access not removed on time | HR termination list against account disable dates | NIST SP 800-53 PS-4, AC-2 |
| 2 | Dormant and orphaned accounts | Accounts with no recent sign-in or no matching HR record | AC-2(3) |
| 3 | Ineffective user access reviews | Review population, reviewer, evidence of removals | AC-6(7) |
| 4 | Movers keep old access | Role changes against entitlements after the move | PS-5 |
| 5 | Segregation of duties conflicts | Users holding conflicting roles in finance or change systems | AC-5 |
| 6 | Excessive standing privileged access | Admin group membership and its approvals | AC-6(5) |
| 7 | MFA gaps and exclusions | Privileged and remote users without MFA; policy exclusions | IA-2(1) |
| 8 | Unowned service accounts and NHIs | Owner, purpose, credential age, interactive use | IA-5, AC-2 |
| 9 | Shared and generic accounts | Accounts used by more than one person | IA-4 |
| 10 | Uncontrolled emergency access | Break-glass usage, alerting and testing evidence | AC-2, AU-6 |
1. Leavers' access not removed on time
The issue: accounts of people who have left stay enabled for days or weeks, or are disabled in the directory but not in applications with local accounts.
Why it matters: a former employee or contractor with working credentials is a direct insider risk. In the Coupang breach, a former engineer's unrevoked signing key was used to expose 33.7 million accounts, and the Ledger Connect Kit compromise started from a former employee's npm access that was never removed.
What auditors test: a sample of leavers from the HR system, compared with the date each account was disabled in the directory and in each in-scope application, against the policy deadline (commonly same day or within 24 hours for involuntary leavers).
What to do: drive deprovisioning from the HR system of record, cover non-federated applications with a ticketed checklist, and revoke tokens, keys and sessions, not just passwords. See the Joiner-Mover-Leaver Guide.
2. Dormant and orphaned accounts
The issue: enabled accounts with no sign-in for months, and accounts with no matching person or owner.
Why it matters: nobody notices when a dormant account is used, which makes it ideal for an attacker. CIS Controls v8.1 Safeguard 5.3 asks for dormant accounts to be deleted or disabled after 45 days of inactivity where supported.
What auditors test: a full directory extract with last sign-in dates, matched against HR and contractor records.
What to do: set an inactivity threshold and automate the disable step. Microsoft's guidance for Entra ID suggests 90 to 180 days as a starting window, uses the last successful sign-in time (which requires Entra ID P1 or P2 to read through Graph), and warns that last sign-in alone does not prove the account is unneeded. Remember that a non-interactive sign-in such as a token refresh is still activity. See Orphaned and Dormant Accounts.
3. Ineffective user access reviews
The issue: reviews happen, but the population is incomplete, reviewers approve everything, reviewers certify their own access, or removals requested in the review are never actioned.
Why it matters: the review is the detective control that catches failures in findings 1, 2, 4 and 5. If it is a rubber stamp, those failures persist and the audit finding becomes a control deficiency.
What auditors test: completeness of the population (the extract was complete and accurate), reviewer independence, timeliness, and evidence that every "revoke" decision resulted in a change.
What to do: generate review data directly from systems, show reviewers entitlement descriptions and last-used dates, block self-review, and track removals to closure. Risk-based frequency works better than reviewing everything quarterly. See the Access Reviews Guide and the Access Review Checklist.
4. Movers keep old access
The issue: people who change role gain new access and keep the old, so long-serving staff accumulate entitlements.
Why it matters: privilege creep produces both excessive access and segregation of duties conflicts, and it is one of the issues the NSA and CISA advisory AA23-278A lists under improper separation of privilege.
What auditors test: a sample of transfers, comparing access before and after the move with the new role's approved profile.
What to do: treat a move as a leave plus a join for birthright access, give the old manager a time-limited sign-off for anything retained, and use role-based provisioning so the role change itself removes access. See the Role Mining and Role Design Guide.
5. Segregation of duties conflicts
The issue: one user can, for example, create a vendor and approve its payment, or develop code and deploy it to production.
Why it matters: SoD conflicts in financial systems are a classic SOX deficiency because they allow fraud or error without a second person. In IT, a developer with production deployment rights bypasses change control.
What auditors test: a rule set of conflicting roles run against current assignments, and approval evidence for any mitigated exceptions.
What to do: maintain a documented SoD matrix, check it at request time rather than only at review, and record compensating controls (such as a reviewed transaction report) for unavoidable conflicts. See the RBAC Role Matrix Template.
6. Excessive standing privileged access
The issue: too many permanent members of Domain Admins, Global Administrator or cloud owner roles, often without documented approval, and administrators using those accounts for daily work.
Why it matters: each standing privileged account is a target for credential theft, and AA23-278A highlights day-to-day use of elevated accounts as a recurring weakness.
What auditors test: membership of privileged groups and roles, approval for each, separation of admin and user accounts, and review evidence.
What to do: separate admin accounts, just-in-time elevation for cloud and directory roles, and a documented maximum for permanent administrators. See the PAM Maturity Model and the Cloud PAM and CIEM Guide.
7. MFA gaps and exclusions
The issue: MFA is "enforced", but privileged accounts, legacy protocols, specific applications or excluded groups still allow password-only access.
Why it matters: the Change Healthcare breach began with one remote access login that did not require MFA. Exclusion groups tend to grow quietly after migrations and incidents.
What auditors test: the MFA policy configuration, the membership of every exclusion, and sign-in logs showing single-factor successes.
What to do: keep a register of every exclusion with an owner and expiry date, block legacy authentication, and require phishing-resistant methods for administrators. See How to Find Accounts Excluded From MFA and Conditional Access and the MFA Exception Register Template.
8. Unowned service accounts and NHIs
The issue: service accounts, application registrations, API keys and cloud access keys with no named owner, no documented purpose, passwords or secrets that never rotate, and sometimes interactive sign-in.
Why it matters: these identities often outnumber people and hold broad rights, yet sit outside joiner-mover-leaver processes and access reviews. The Dropbox Sign breach ran through a compromised back-end service account.
What auditors test: an inventory of non-human accounts with owner, purpose, credential age and last use; increasingly, whether they are in access review scope at all.
What to do: assign owners, include NHIs in reviews, deny interactive logon, replace static secrets with managed identities or federation, and use cloud tooling such as AWS IAM Access Analyzer unused access findings (unused roles, access keys, passwords and permissions) to find what can be removed. See How to Run an Access Review for Service Accounts and the NHI Ownership Guide.
9. Shared and generic accounts
The issue: accounts such as "admin", "support" or "finance-team" whose password is known to several people.
Why it matters: logs cannot show who acted, leavers still know the password, and the account cannot be reviewed against a single person's role.
What auditors test: account naming patterns, accounts without an HR link, and password change history after team changes.
What to do: replace with named accounts where possible; where a shared account is unavoidable, vault it with check-out, session recording and rotation after each use.
10. Uncontrolled emergency access
The issue: break-glass accounts exist but nobody knows when they were last used, sign-ins are not alerted, or they have never been tested.
Why it matters: they are highly privileged and excluded from normal policy by design, so misuse is high impact and an untested account may fail in a real outage.
What auditors test: the list of emergency accounts, their authentication methods, alerting configuration and evidence of each use and test.
What to do: Microsoft's Entra guidance is a good baseline for any platform: at least two cloud-only accounts, phishing-resistant authentication using a different method from normal admin accounts, an alert on every sign-in, validation at least every 90 days, and a post-use review of each sign-in. See the Break-Glass Account Guide.
Mapping to OWASP and control frameworks
| Finding | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | NIST CSF 2.0 | OWASP NHI Top 10 (2025) |
|---|---|---|---|---|
| 1. Leavers | PS-4, AC-2 | A.5.18, A.6.5 | PR.AA-05 | NHI1 (for NHIs) |
| 2. Dormant and orphaned | AC-2(3) | A.5.16, A.5.18 | PR.AA-01 | NHI1 |
| 3. Access reviews | AC-6(7), AC-2 | A.5.18 | PR.AA-05 | Not specific |
| 4. Movers | PS-5 | A.5.18 | PR.AA-05 | Not specific |
| 5. SoD | AC-5 | A.5.3 | PR.AA-05 | Not specific |
| 6. Privileged access | AC-6(5) | A.8.2 | PR.AA-05 | NHI5 |
| 7. MFA gaps | IA-2(1) | A.8.5 | PR.AA-03 | Not specific |
| 8. Service accounts and NHIs | IA-5, AC-2 | A.5.16, A.5.17 | PR.AA-01 | NHI5, NHI7, NHI10 |
| 9. Shared accounts | IA-4 | A.5.16 | PR.AA-01 | NHI9 |
| 10. Emergency access | AC-2, AU-6 | A.8.2 | PR.AA-05 | Not specific |
CIS Controls v8.1 covers the same ground in Control 5 (Account Management) and Control 6 (Access Control Management), including dedicated administrator accounts and MFA for administrative access. For audit evidence covering machine and agent identities specifically, see Audit Readiness for AI Agents and NHIs.
Where to start
- Fix the data first: most findings trace back to an incomplete account inventory or a weak link between HR records and accounts. Reconcile directory, application and HR data before redesigning processes.
- Automate leavers: HR-triggered disablement closes finding 1 and shrinks findings 2 and 9.
- Run the cheap reports monthly: dormant accounts, privileged group membership, MFA exclusions and break-glass sign-ins can all be produced from existing logs. Fix what they show before the auditor arrives.
- Rebuild the access review: complete populations, no self-review, usage data for reviewers, and closure tracking for every revoke.
- Bring NHIs into scope: assign owners and include service accounts in reviews; auditors are increasingly asking.
- Track repeat findings: report the number of findings repeated from the previous audit, time to remediate, and percentage of leavers disabled within policy as standing KPIs.
Standards and references
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- CIS: Control 5 Account Management
- NSA and CISA: AA23-278A Top Ten Cybersecurity Misconfigurations
- Microsoft: How to manage inactive user accounts in Microsoft Entra ID
- Microsoft: Manage emergency access admin accounts in Microsoft Entra ID
- AWS: IAM Access Analyzer findings
Related NHI Mgmt Group resources: Access Review Requirements Map, Identity Governance Maturity Model, Top 10 Penetration Test Findings, NHI Governance Maturity Model.