The Top IAM Misconfigurations That Lead to Breaches

Identity misconfigurations are rarely dramatic. Nobody deliberately grants a service account domain administrator rights or leaves a legacy authentication protocol enabled indefinitely. These things happen because someone needed to unblock a project, the change worked, and nobody came back to narrow it.

The result is that most environments accumulate a predictable set of identity weaknesses, and attackers know exactly which ones to look for. The techniques used against them are documented, widely available, and require no novel capability. What makes them effective is not sophistication; it is that the conditions persist for years because removing them is nobody's priority and nothing breaks while they remain.

This post covers the misconfigurations that show up most consistently in real intrusions, why each one is exploitable, how to find it in your environment, and what closing it actually involves.

Why These Persist

Understanding the mechanism helps prevent the recurrence.

Excess access breaks nothing. Nobody files a ticket because they have more permissions than they need. Reduction has to be driven proactively or it does not happen.

Rotation carries operational risk. Rotating a credential embedded in systems nobody has fully mapped can break production. Teams learn this once and become understandably reluctant to try again.

Ownership evaporates. The person who created a service account has changed roles or left. Without an owner, nobody can decide whether a permission can safely be removed.

Legacy exists because something depends on it. Every legacy protocol still enabled has at least one application behind it, and finding that application is work nobody scheduled.

Identity spans teams. Directory services, cloud identity, and SaaS platforms are frequently owned by different groups, so nobody sees the combined picture.

Organizations wanting a clear view of which of these apply to them can establish that baseline with FoxRadar360 rather than assuming their identity provider's default reporting surfaces the problems.

Misconfiguration One: Incomplete MFA Coverage

The most consequential and the most common.

What It Looks Like

Multi-factor authentication deployed to the general user population but not enforced on service accounts, break-glass accounts, legacy protocol paths, or specific applications granted exceptions during rollout. Or deployed everywhere with fallback methods left active.

An account with a strong factor and an active SMS recovery option is protected at the strength of SMS, because that is the method an attacker will target.

Why It Is Exploited

Brute-force and credential-spraying attacks run continuously against every exposed authentication endpoint. They succeed only where the password is weak and the second factor is absent, and attackers systematically probe for the paths where enforcement lapsed.

Push notifications and one-time codes are also defeated routinely now, through fatigue attacks and real-time relay through adversary-in-the-middle phishing infrastructure. Coverage that stops at push-based MFA is incomplete in a different way.

How to Find It

Enumerate every authentication path, not every user: VPN, remote desktop gateways, webmail, administrative portals, API authentication, and legacy protocols. For each, confirm enforcement and check the exception list, which is usually longer than expected and rarely reviewed.

What to Do

Enforce phishing-resistant, origin-bound authentication on administrative accounts and remote access first, close fallback methods as you go, and document any remaining exception with an owner and an expiry date.

Misconfiguration Two: Standing Privileged Access

What It Looks Like

Administrators holding elevated rights continuously rather than requesting them when needed. Often combined with administrators using the same account for daily work and privileged tasks.

Why It Is Exploited

An attacker who compromises an administrative account at any moment finds full administrative capability. With just-in-time elevation, the same compromise outside an active window yields ordinary user permissions.

This single control shrinks the exploitable window from permanent to minutes and is among the highest-value changes available.

How to Find It

Enumerate members of every privileged group and role across on-premises directory, cloud platforms, and SaaS administration. Compare against who actually performs privileged actions, using access activity data where the platform exposes it.

What to Do

Separate administrative accounts from daily-use accounts. Move the highest-privilege roles to time-bound elevation with automated approval against policy for routine cases, so friction does not drive workarounds. Provide genuine break-glass access with heavy logging and mandatory after-the-fact review.

Misconfiguration Three: Permission Accumulation Through Role Changes

What It Looks Like

Someone moves from finance to operations and receives operations access on top of retained finance access. Repeated over several moves and several years, this produces permission sets nobody would approve if presented fresh.

Why It Is Exploited

Accumulated access determines blast radius. It is the difference between a compromised account reaching one system and reaching six departments' data.

How to Find It

Compare entitlements against role definitions. Look specifically at long-tenured employees and anyone who has changed roles more than once. Identify toxic combinations, such as the ability to both create and approve payments.

What to Do

Make role change trigger a full entitlement reset against the new role rather than an additive grant. This single process change removes a large share of standing exposure across the whole organization.

Add automatic revocation of access unused for a defined period, with a fast reinstatement path so the control does not create resentment.

Misconfiguration Four: Over-Permissioned Service Accounts

What It Looks Like

Service accounts granted domain administrator rights or broad cloud permissions because narrowing them required knowing exactly what the application needed, and nobody had time to work it out.

Why It Is Exploited

Service accounts have no second factor, rarely rotate, and often have passwords set years ago. They are also frequently discoverable through directory enumeration, and their permissions make them a direct path to privilege.

Kerberoasting and similar techniques specifically target service accounts precisely because this pattern is so reliable.

How to Find It

Enumerate service accounts and their group memberships and role assignments. In cloud environments, use access activity data showing which permissions have actually been exercised. Anything unused for ninety days is a removal candidate.

Check password age and whether the account has ever been used interactively.

What to Do

Assign a named human owner to every service account. Narrow permissions based on observed usage. Replace passwords with managed service accounts or workload identity federation where the platform supports it, since removing the stored credential entirely is stronger than protecting it.

Misconfiguration Five: Legacy Authentication Protocols Left Enabled

What It Looks Like

Basic authentication, older mail protocols, NTLM, and other legacy paths that bypass conditional access policies, MFA enforcement, and modern logging.

Why It Is Exploited

These paths exist specifically because they predate modern controls. An attacker who finds one has an authentication route that ignores every policy layered on top, and password spraying against legacy endpoints remains highly productive.

How to Find It

Query authentication logs for protocol and client application. Legacy usage is almost always present in environments that believe they disabled it, and the volume tells you which applications still depend on it.

What to Do

Identify the dependent applications, migrate or replace them, then disable the protocol. Where a genuine dependency remains, restrict it to specific accounts and source addresses, monitor it closely, and set a date for removal rather than treating the exception as permanent.

Misconfiguration Six: Stale and Orphaned Accounts

What It Looks Like

Accounts belonging to departed employees, contractors whose engagement ended, and systems decommissioned years ago, all still enabled and often still holding meaningful access.

The mover and leaver processes usually fail differently. Leavers get disabled in the primary directory while cloud-native and SaaS identities remain active.

Why It Is Exploited

Dormant accounts are attractive because their unusual activity is unlikely to be noticed by a user who no longer exists, and their credentials may appear in breach dumps without anyone rotating them.

How to Find It

Report on accounts with no authentication in ninety days, reconcile the directory against current HR records, and check each cloud platform and major SaaS application separately rather than assuming directory deprovisioning propagated.

What to Do

Automate deprovisioning across every identity system, not just the primary directory. Disable dormant accounts on a defined schedule with a simple reactivation path. Treat unattributable accounts as findings requiring investigation.

Misconfiguration Seven: Ungoverned Application Consent

What It Looks Like

Users able to grant third-party applications access to organizational data without administrative approval, and existing grants that were approved once and never reviewed.

Why It Is Exploited

Consent-granted access persists through password resets and MFA changes, which makes it one of the more durable persistence mechanisms available. Attackers use it both by socially engineering users into approving malicious applications and by compromising legitimate integration providers.

The permissions requested are usually broader than the integration needs, because vendors request what their fullest configuration requires.

How to Find It

Enumerate every connected application across each SaaS platform, with the scopes granted, who approved it, when, and whether it is still in use. Expect to find applications nobody recognizes and grants belonging to tools the organization stopped using.

What to Do

Restrict who can authorize applications, with a fast approval route so people do not seek workarounds. Revoke unused grants. Alert on new authorizations and scope expansions rather than reviewing periodically, since the window between a malicious grant and bulk extraction is short.

Misconfiguration Eight: Weak Account Recovery

What It Looks Like

Help desk password and MFA reset procedures that rely on information an attacker can research: employee ID, manager name, date of birth, or recent activity.

Why It Is Exploited

Recovery is frequently the softest path into an otherwise hardened environment. Social engineering aimed at support staff has been the documented entry point in numerous significant intrusions, and it bypasses every authentication control by design.

How to Find It

Read the actual procedure your service desk follows, not the documented policy. Test it. Have someone attempt a reset using only publicly available information and see how far they get.

What to Do

Require verification that an attacker cannot research: a callback to a known number, verification through an already-enrolled factor, or manager confirmation through an independent channel. Make it explicitly acceptable for staff to refuse and escalate. Log and monitor reset activity, particularly clustering.

Misconfiguration Nine: Federation and Trust Left Unreviewed

What It Looks Like

Federation between on-premises directory and cloud providers, between clouds, and into SaaS platforms, configured during a project and never audited afterward. Directory synchronization services holding privileged access on both sides.

Why It Is Exploited

Compromise of an identity provider grants access everywhere it federates, which is frequently everywhere. Synchronization identities are high-value and often escape the scrutiny applied to domain controllers.

How to Find It

Produce a current map of which identity systems trust which others and what each trust permits. Most organizations cannot do this without investigation, which is itself the finding.

What to Do

Assign an owner to every trust relationship. Review scope and remove what is no longer needed. Protect synchronization identities with the same rigor as domain administrators. Monitor for federation configuration changes, which are rare, planned, and attributable when legitimate.

Detecting Exploitation When Prevention Fails

Some of these will persist longer than anyone wants, which makes detection the compensating control.

The signals worth instrumenting: service accounts authenticating interactively, authentication through legacy protocols, MFA method registration or removal, conditional access policy modifications, privileged group membership changes outside change windows, dormant accounts becoming active, new application consent grants, and authentication from infrastructure inconsistent with normal patterns.

These are among the highest-fidelity alerts available in any environment because they have few benign explanations. Correlating them with endpoint and cloud activity is what turns an unusual login into a detected intrusion, and it is central to how FoxRadar360 approaches identity coverage rather than treating identity as an isolated log source.

A Practical Remediation Sequence

Attempting everything at once stalls. This order delivers the most reduction earliest.

Enumerate first. Privileged accounts, service accounts, authentication paths, application grants, federation trusts, and dormant accounts. You cannot prioritize what you have not measured.

Close MFA gaps on administrative and remote access, including fallback methods.

Disable legacy authentication paths, with documented, time-bound exceptions for genuine dependencies.

Fix account recovery, since it undermines everything above if left weak.

Move top-tier privilege to just-in-time elevation.

Narrow service account permissions using observed usage, and assign owners.

Restrict application consent and revoke unused grants.

Automate deprovisioning across every identity system, and make role change trigger entitlement reset.

Key Takeaways

The identity weaknesses that appear in breach reports are not exotic. They are the accumulated residue of reasonable decisions made under time pressure: an exception granted during rollout, a permission broadened to unblock a deployment, a legacy protocol left enabled because something depended on it, a service account nobody dared to touch.

They persist because excess access breaks nothing, rotation carries operational risk, ownership evaporates when people move on, and identity spans teams so nobody sees the whole picture. Attackers exploit them because they are reliably present and require no novel capability to use.

The corrective work is mostly enumeration followed by narrowing. Find every authentication path and close the MFA gaps including fallbacks. Find the standing privilege and make it time-bound. Find the service accounts and narrow them against observed usage. Find the legacy protocols and the application grants and the dormant accounts, and remove what nothing depends on.

Where prevention lags, detection compensates, and the identity signals worth instrumenting are unusually high fidelity because legitimate systems rarely produce them.

None of this requires replacing your identity platform. It requires deciding that the surface attackers use most deserves attention proportional to that fact, and assigning someone to own the reduction. To review which of these misconfigurations exist in your environment and whether their exploitation would be detected, start a conversation with the team at FoxRadar360.