Your access controls passed the audit. Your segregation of duties matrix looks clean. But if you're making these identity governance mistakes, you've built a compliance facade over exploitable attack paths.
Here's the problem: many organizations treat identity governance as a one-time compliance task. You document who has access to what, certify it quarterly, and check the box for ISO/IEC 27001 Annex A 5.15 (Access Control) and SOC 2 CC6.1 (Logical and Physical Access Controls). Then you move on. Meanwhile, attackers exploit the gaps between your documented controls and your actual identity posture. Recent threat intelligence shows the median time between initial compromise and access being handed to an attack operator is just 22 seconds.
These mistakes persist because identity governance spans organizational boundaries. It requires coordination between security engineering, IT operations, application owners, and business units. When no single team owns the complete picture, blind spots multiply.
Mistake 1: Ignoring Machine and AI-Agent Identities
Why it happens: Your identity governance program was designed for human users. You've got processes for onboarding employees, periodic access reviews, and termination procedures. Service accounts, API keys, and AI agents don't fit this model, so teams manage them ad hoc.
The real consequence: Unmanaged machine identities become privilege escalation vectors. For example, your development team might create service accounts with broad database access for a CI/CD pipeline. No one documents these accounts in your identity inventory or reviews their permissions. When a developer leaves, their personal credentials are revoked, but the service account they configured persists with excessive privileges. An attacker who compromises that pipeline now has a direct path to production data.
For ISO/IEC 27001 compliance, Annex A 5.18 (Access Rights) requires regular access rights reviews. If your review process doesn't include non-human identities, you're not meeting the control objective.
The specific fix: Extend your identity inventory to include all identity types. Start with a discovery phase using your privilege access management (PAM) tools, secrets management platforms, and cloud IAM APIs to enumerate service accounts, API keys, bot accounts, and AI agents. Document ownership for each non-human identity. Assign a responsible individual who will answer for its purpose and permissions. Build machine identities into your quarterly access certification process with the same rigor you apply to human accounts.
Mistake 2: Relying Solely on Authentication Logs
Why it happens: You're collecting authentication events in your SIEM. You've set alerts for failed login attempts and impossible travel scenarios. It feels like you're monitoring identity security.
The real consequence: Authentication monitoring tells you when someone tries to use credentials. It doesn't tell you when credentials are exposed, when privileges are escalating, or when attackers are mapping your identity infrastructure to create attack paths. You're watching the door after the attacker's already inside studying your floor plan.
This gap matters for SOC 2 CC7.2 (System Monitoring). The criterion requires you to detect anomalies and indicators of compromise. If your monitoring stops at authentication events, you're missing identity-layer threats.
The specific fix: Implement identity threat detection and response (ITDR) capabilities that monitor identity stores, privilege changes, and entitlement modifications. Configure alerts for suspicious patterns like privilege escalation outside change windows, service account authentication from unexpected locations, or bulk permission grants. Integrate ITDR telemetry with your security operations workflow so identity anomalies trigger investigation, not just logging.
Mistake 3: Documenting Ownership Without Enforcing Accountability
Why it happens: You've assigned application owners in your asset inventory. You've mapped data stewards to sensitive systems. On paper, every resource has an owner. But when you need someone to justify why a contractor still has admin access six months after their project ended, no one responds.
The real consequence: Access reviews become rubber-stamp exercises. Reviewers approve everything because they don't understand the context, don't have time to investigate, or assume someone else verified it. Excessive privileges accumulate. Attackers exploit these dormant high-privilege accounts because they're less likely to trigger alerts than active accounts.
This undermines ISO/IEC 27001 Annex A 5.18 and SOC 2 CC6.2 (Logical Access Controls), both of which require timely modification or removal of access rights when no longer needed.
The specific fix: Make ownership operationally meaningful. When you assign an application owner, document their specific responsibilities: quarterly access certification, approval of new access requests, and investigation of anomalous activity. Track completion rates for access reviews by owner. Escalate incomplete reviews to their management chain. If an owner consistently fails to complete reviews, reassign ownership to someone who will engage. Build this accountability into job descriptions and performance evaluations for technical leads and product managers.
Mistake 4: Fragmenting Identity Governance Across Disconnected Tools
Why it happens: You've got an identity provider for SSO, a PAM solution for privileged access, a cloud IAM for your AWS environment, a separate system for database credentials, and spreadsheets for everything else. Each tool solves a specific problem. None of them talk to each other.
The real consequence: You can't answer basic questions about your identity posture. Who has production database access? You'd need to check four systems and reconcile the results manually. How many identities have both cloud admin rights and VPN access? You don't know. Attackers exploit these visibility gaps by chaining privileges across disconnected systems to create attack paths you never modeled.
This fragmentation makes it nearly impossible to demonstrate the "integrated approach" required by ISO/IEC 27001 Clause 4.4 (Information Security Management System).
The specific fix: Implement an identity security posture management layer that aggregates data from your disconnected identity systems. This doesn't mean replacing your existing tools. It means building a unified view that can answer cross-system questions about privilege accumulation, orphaned accounts, and policy violations. Use this aggregated view to drive your risk assessment process. When you identify excessive privilege combinations, feed those findings back to the individual systems for remediation.
Mistake 5: Prioritizing Remediation by Severity Instead of Exploitability
Why it happens: Your vulnerability scanner flags every service account with a non-expiring password as "High" severity. Your access review identifies 200 users with excessive permissions. You start remediating alphabetically or by severity score because you need to show progress.
The real consequence: You spend weeks rotating credentials for service accounts that authenticate only within isolated development environments while ignoring the internet-facing service account with cloud admin rights. Attackers don't care about your severity scores. They exploit the weaknesses that give them the fastest path to their objective.
The specific fix: Prioritize identity risks based on attack path analysis. Map which identities have access to your most sensitive assets. Identify which of those identities have external exposure, excessive privileges, or weak authentication. Remediate the combinations that create exploitable attack paths first. A medium-severity finding on a highly privileged account with network exposure outranks a high-severity finding on an isolated low-privilege account. Document your prioritization logic in your Risk Treatment Plan so auditors understand why you sequenced remediation this way.
Prevention Checklist
Use this checklist quarterly to catch these mistakes before they become incidents:
- Your identity inventory includes human, machine, and AI-agent identities with documented owners
- Access reviews cover all identity types and track completion by owner with escalation for non-response
- Your monitoring strategy includes ITDR capabilities, not just authentication logs
- You can answer cross-system questions about privilege combinations without manual reconciliation
- Your risk register prioritizes identity risks by attack path exploitability, not just severity scores
- Service accounts and API keys have documented business justification and defined lifespans
- Your incident response playbook includes procedures for identity-layer compromise
- You've tested your ability to revoke access across all systems within your defined RTO
Identity governance isn't a compliance artifact. It's the foundation of your detective and preventive controls. Get it wrong, and you're just documenting the attack surface you're handing to adversaries.
