Common IAM Mistakes That Increase Security Risk

Most identity-related incidents do not begin with novel zero-days or sophisticated nation-state tooling. They begin with ordinary IAM mistakes that quietly accumulate over years and finally collide with a phishing email, a leaked secret, or a vulnerable web app.

This guide covers the IAM mistakes that show up again and again in real-world incident reports — including the CISA / NSA / FBI Top 10 Cybersecurity Misconfigurations advisory and the Verizon DBIR — and what to do about each.

---

1. Weak or Missing MFA

The mistake. MFA is enforced for some users (or some apps) but not all. Service accounts, break-glass accounts, legacy protocols, contractor accounts, and rarely used admin accounts often slip through.

Why it happens. Enforcement was rolled out per-application or per-group, with exceptions that were never closed.

Why it's risky. A single MFA gap is enough for credential stuffing, phishing, or password spraying to succeed against high-impact accounts.

Fix.

• Enforce phishing-resistant MFA (FIDO2 / passkeys) for all users.
• Block legacy authentication protocols (POP3, IMAP, basic auth, NTLMv1).
• Audit conditional access exclusions monthly.
• Protect break-glass accounts with hardware keys, offline-stored credentials, and high-priority alerting on every use.

---

2. Standing Privileged Access

The mistake. Admin rights — Domain Admin, Global Administrator, AWS Organization Admin, root, DBA — are always-on for the people who occasionally need them.

Why it's risky. A single phishing or token theft event hands the attacker permanent admin power.

Fix.

• Adopt Just-in-Time elevation (PIM, PAM, AWS Identity Center session) with approval and time limits.
• Aim for Zero Standing Privilege for human admins.
• Separate admin accounts from daily-use accounts.
• Require strong MFA on every elevation.

---

3. Overprivileged Service Accounts

The mistake. A service account is created with broad permissions ("just give it Domain Admin so it works"), no clear owner, no rotation, and is never reviewed.

Why it's risky. Service accounts often outlive their projects, have static credentials, run on multiple systems, and are rarely monitored. They are a top attacker target.

Fix.

• Inventory all service accounts; assign owners.
• Right-size permissions to actual usage.
• Vault and rotate credentials.
• Restrict interactive login.
• Move toward managed service accounts and workload identities.
• Decommission unused accounts.

---

4. Direct Permissions Instead of Roles or Groups

The mistake. Permissions are granted directly to users instead of via roles or groups.

Why it's risky.

• Effective access becomes invisible.
• Offboarding misses individual grants.
• Reviews can't keep up.

Fix.

• Enforce a "no direct grants" policy.
• Standardize on RBAC (or RBAC + ABAC) for authorization.
• Audit and remove existing direct grants.

---

5. Hidden Privilege Paths

The mistake. A user appears to have only standard access, but through nested groups, ownership, ACLs, or delegations they can become an admin.

Why it's risky. Traditional IAM tools show direct permissions, not paths. Attackers love what defenders can't see.

Fix.

• Use attack path analysis to map identity relationships.
• Flatten nested group structures.
• Audit ownership and delegation chains.
• Treat privileged paths the same as privileged direct access.

---

6. Weak Offboarding (Leaver) Process

The mistake. Accounts remain active days, weeks, or months after termination. SaaS apps not integrated with the IdP keep working. Active OAuth tokens are never revoked.

Why it's risky. Former employees retain access. Compromised credentials remain valid long after the person should have lost them.

Fix.

• HR-driven, same-day deprovisioning.
• Revoke active sessions and refresh tokens.
• SCIM-integrate every SaaS app possible.
• Reassign or rotate owned secrets and service accounts.
• Test deprovisioning by sampling departed users.

---

7. Privilege Creep on Mover Events

The mistake. When an employee changes role, new access is granted but old access is not removed.

Why it's risky. Long-tenured employees accumulate access nobody could justify, becoming the most attractive insider risk and phishing target.

Fix.

• Trigger automated re-evaluation on every role change.
• Remove old groups by default; require explicit justification to keep them.
• Run mover-triggered access reviews.

---

8. Shared Admin Accounts

The mistake. A handful of generic admin accounts (adm_admin, prod_root, super-user) are shared across the team.

Why it's risky. No accountability, hard to rotate, blast radius is everyone.

Fix.

• Per-person admin accounts.
• Vaulted, brokered access via PAM.
• Session recording for forensics.

---

9. Long-Lived Static Credentials

The mistake. API keys, access keys, and service account passwords with no expiration, hardcoded in code, configs, CI/CD, or cloud metadata.

Why it's risky. Once leaked (GitHub, logs, screenshots, backups, ex-employees) they can be used indefinitely.

Fix.

• Use short-lived, dynamically issued credentials (OIDC federation, AWS STS, GCP Workload Identity).
• Vault and rotate where dynamic isn't possible.
• Scan code, repos, logs, and configs for secrets.
• Rotate on personnel changes.

---

10. Tenant-Wide OAuth Consent

The mistake. Users (or admins) consent to third-party OAuth apps that request tenant-wide permissions (Mail.ReadWrite.All, Files.ReadWrite.All, Directory.ReadWrite.All).

Why it's risky. A compromised or malicious vendor app can read every mailbox or every file in the tenant.

Fix.

• Disable user-level consent for high-risk scopes; require admin approval.
• Maintain an enterprise-app inventory and review quarterly.
• Monitor for unusual consent grants and token use.
• Apply least-scope principle to your own internal apps.

---

11. Misuse of Built-in Cloud Roles

The mistake. Defaulting to Owner, Contributor, Editor, AdministratorAccess, or *:* policies because they "just work."

Why it's risky. A single compromised identity inherits broad cloud control.

Fix.

• Build custom least-privilege roles per workload.
• Use cloud IAM analyzers (AWS Access Analyzer, GCP Recommender, Azure PIM insights) to right-size.
• Monitor for policy drift.

---

12. Inconsistent Identity Across Systems

The mistake. Different identity stores per app, no central IdP, local accounts everywhere.

Why it's risky. Offboarding is incomplete by definition. MFA is unevenly enforced. Audit is impossible.

Fix.

• Federate everything to one primary IdP.
• Use SAML/OIDC for SSO.
• Keep break-glass local accounts only where strictly required.

---

13. Stale and Orphaned Accounts

The mistake. Accounts of former employees, abandoned contractors, decommissioned services, and forgotten test users still exist — sometimes still privileged.

Why it's risky. They're invisible attack surface. No one will notice if they're used.

Fix.

• Continuously detect stale and orphaned identities.
• Disable, then delete after a grace period.
• Reassign ownership of any active service accounts before deletion.

---

14. Failure to Monitor Identity Activity

The mistake. Sign-in logs, role changes, privilege escalations, OAuth consents, and PAM sessions go unwatched.

Why it's risky. Attackers operate undetected for weeks or months.

Fix.

• Send all identity logs to SIEM.
• Alert on: impossible travel, MFA fatigue, new device, mass downloads, privileged role activations, unusual OAuth consents.
• Tune detections based on environment baselines.

---

15. Treating Non-Human Identities as Out of Scope

The mistake. IAM programs focus only on humans. Service accounts, workloads, OAuth apps, AI agents, and bots are managed ad hoc, if at all.

Why it's risky. NHIs typically outnumber humans by 10× or more and frequently hold privileged access. They're the modern attacker's preferred target.

Fix.

• Treat NHIs as first-class IAM citizens.
• Inventory, ownership, lifecycle, least privilege, vaulting, monitoring.
• Include NHIs in access reviews, attack path analysis, and PAM.

---

16. Missing Separation of Duties

The mistake. One person can both initiate and approve a sensitive action (payment, code deployment, user creation).

Why it's risky. Enables fraud, mistakes, and insider abuse.

Fix.

• Define SoD policies for sensitive workflows.
• Detect toxic role combinations during access reviews.
• Enforce SoD checks in workflow tools and IGA.

---

17. Skipping Access Reviews

The mistake. Access reviews are skipped, delayed, or rubber-stamped.

Why it's risky. Privilege creep, stale entitlements, and SoD violations accumulate undetected.

Fix.

• Risk-based, context-rich reviews (see What is Access Review?).
• Quarterly reviews for privileged and sensitive access.
• Auto-remediate revocations.

---

18. Trusting the Network Perimeter

The mistake. Apps and services trust requests from the corporate network without re-authenticating.

Why it's risky. Once attackers are inside the network (via VPN compromise, supply-chain, etc.), they can move freely.

Fix.

• Adopt Zero Trust principles.
• Re-authenticate and re-authorize at the application layer.
• Use device posture, identity, and behavior in authorization decisions.

---

19. Ignoring AI Agent Identity

The mistake. AI agents are deployed with shared credentials, broad scopes, no human-in-the-loop, and no separate identity per agent.

Why it's risky. Agentic workflows can take destructive actions at machine speed; misuse or prompt injection can amplify damage.

Fix.

• Issue a unique identity per agent.
• Scope tools and actions tightly.
• Require human approval for sensitive actions.
• Log agent actions and monitor for anomalies.

---

20. No Attack Path Analysis

The mistake. Security teams measure IAM in terms of users, groups, and policies — but not the paths attackers can take through them.

Why it's risky. Real breaches almost always exploit a chain of legitimate-looking permissions, not a single broken control.

Fix.

• Continuously map identity attack paths to Tier 0 assets.
• Prioritize fixes by impact, not just by misconfiguration count.
• Re-run analysis as the environment changes.

---

Quick Self-Check

• Is phishing-resistant MFA enforced everywhere, including legacy and break-glass?
• Are admin rights JIT, with no standing privilege?
• Are service accounts inventoried, owned, and right-sized?
• Are hidden privilege paths analyzed regularly?
• Is offboarding same-day, including session and token revocation?
• Are mover events fully processed (removals + additions)?
• Are OAuth apps and tenant-wide scopes under review?
• Are NHIs and AI agents covered by IAM?
• Are SoD policies defined and enforced?
• Are identity logs monitored and alerted on?

If any of these is "no" or "we're not sure," that's where the next incident is most likely to start.

---

How Forestall Helps

Most of the mistakes above are known — the challenge is finding all the places they exist. Forestall continuously analyzes identities, groups, devices, applications, and cloud resources across your environment to surface:

• Overprivileged human and non-human identities.
• Hidden privilege paths and toxic combinations.
• Stale, dormant, and orphaned identities.
• OAuth apps and AI agents with excessive scope.
• Recurring patterns that indicate structural weaknesses, not one-off bugs.

This turns the long list of "common IAM mistakes" into a prioritized, measurable, fixable backlog.

---

Conclusion

You don't need to defend against every possible attack technique. You need to fix the small number of IAM mistakes that consistently turn limited access into full compromise. Each of the items above is well-understood, well-documented, and well within reach of a focused security program.

Start with the ones that affect privileged accounts, service accounts, and identity attack paths — those are where impact concentrates. Then build the continuous monitoring and review practices that prevent the same mistakes from coming back.