Legacy IAM leaves identity-centric attacks with too many gaps

At a glance

What this is: Zluri argues that legacy IAM leaves major gaps because modern attacks abuse stolen credentials, session state, fragmented identity records, and overprovisioned access rather than defeating perimeter-era login controls.

Why it matters: For IAM, IGA, PAM, and NHI teams, the article reinforces that access decisions must follow identity context and privilege scope, not stop at authentication success.

Context

Legacy IAM is a control model built around stable users, static credentials, and a network perimeter. That assumption breaks when attackers log in with stolen credentials, sessions are hijacked, and the same person appears differently across SSO, PAM, and other identity systems.

The identity governance problem is broader than authentication. Modern environments include contractors, vendors, service accounts, bots, APIs, and unmanaged devices, so fragmented records and group-based provisioning can leave hidden access paths and stale permissions in place.

Key questions

Q: What breaks when legacy IAM still stops at authentication?

A: Authentication-only IAM breaks when attackers reuse stolen credentials or session tokens, because the system accepts the login without evaluating whether the requested action fits the user’s device, behaviour, or privilege context. That allows legitimate-looking access to become lateral movement and data exposure. Modern identity control needs to decide more than whether a password was correct.

Q: Why do fragmented identity records increase risk in large organisations?

A: Fragmented identity records increase risk because defenders cannot reliably tell which accounts belong to the same person, task, or workload. That weakens visibility, creates gaps in access governance, and makes it harder to spot misuse or excessive privilege. In large environments, the problem scales faster than manual reconciliation, so unresolved identity sprawl becomes an operational and security liability.

Q: How should security teams reduce overprovisioned access in IAM?

A: Security teams should replace broad group membership with task-aware, context-aware provisioning that ties access to responsibility, sensitivity, and current need. That reduces the chance that a compromised account can use excess privilege to browse systems or escalate. Least privilege works only when entitlement design is specific enough to limit the blast radius of compromise.

Q: What should teams do when identities span SSO, PAM, and lifecycle tools?

A: Teams should build a reconciled identity source that matches records across systems before making offboarding or access review decisions. Without reconciliation, one system can deactivate an identity while another keeps it alive. That is an accountability problem as much as a technical one, because no single control view can prove access has actually ended.

Technical breakdown

Why authentication-only IAM fails after login

Legacy IAM can confirm a credential, but that is not the same as deciding whether the action should be allowed. In cloud and SaaS environments, a stolen password, token, or session cookie can still look legitimate to the access layer because the system is not continuously reasoning over device, location, behaviour, or privilege context. That gap matters because modern identity attacks rarely need to break authentication. They need to reuse it. Once the session exists, attackers can blend into normal traffic, pivot across applications, and operate without triggering a simple login failure.

Practical implication: teams need authorization and risk evaluation to happen beyond the initial sign-in event.

How fragmented identity data creates hidden access paths

When SSO, MFA, PAM, and lifecycle systems each keep separate identity records, the result is not just duplication. It is inconsistent identity state. One system may know a user by one alias, another by a different alias, and a legacy IAM layer may fetch both without reconciling them into a single authoritative record. That weakens joiner-mover-leaver processes, because offboarding, role change, and entitlement review can miss one of the records. The attack surface is therefore not only the account itself but the administrative confusion around it.

Practical implication: identity correlation and offboarding must be based on a reconciled identity source, not vendor-by-vendor records.

Why overprovisioned groups undermine least privilege

Group-based provisioning was efficient when roles were simpler and access sets were smaller. In modern environments, it often assigns permissions by department instead of by task, risk, or sensitivity. That creates standing excess access, which turns a normal user account into a useful pivot point once an attacker is inside. The problem is not merely that users have too much access. It is that broad groups make privilege boundaries coarse, so the access model cannot distinguish a finance intern from a finance manager or a temporary contractor from a trusted employee.

Practical implication: entitlement design should move from broad groups toward task-aware, context-aware provisioning.

Threat narrative

Attacker objective: The attacker aims to turn legitimate-looking identity state into persistent access, lateral movement, and privilege expansion inside the environment.

1. Entry begins when the attacker uses phishing, credential stuffing, session hijacking, or Kerberoasting to obtain valid identity information rather than force a perimeter breach.
2. Credential access follows through theft of usernames, passwords, access tokens, or session cookies that the legacy IAM layer still accepts as legitimate.
3. Escalation and lateral movement happen as the attacker uses that trusted identity state to browse systems, access sensitive data, and expand privileges without triggering meaningful authorization checks.
4. Impact occurs when fragmented records, unmanaged identities, and overprovisioned access let the attacker remain hidden while moving deeper into the environment.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Stryker Microsoft Intune Wiper Attack: Compromised Microsoft Intune credentials enable wiper attack wiping 200,000 Stryker devices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Legacy IAM is built on a perimeter-era assumption that identity proves trust once at login. That assumption fails when the adversary’s entry point is stolen identity material rather than network intrusion. The result is a control plane that treats authenticated presence as sufficient evidence of legitimacy. The implication is that access governance now has to evaluate identity state continuously, not just admit the session.

Identity fragmentation is now a governance problem, not just a directory problem. When one person exists in multiple systems under different records, lifecycle controls stop being deterministic. Offboarding, recertification, and role change processes can complete against one record while another remains active. That creates a stale-access window that legacy IAM cannot reliably close, and the implication is that identity reconciliation is now part of security assurance.

Overprovisioned group assignment creates identity blast radius. A broad access group does not merely grant extra convenience. It expands the set of actions a compromised account can perform once credentials are stolen. In practice, this means least privilege fails at design time when access is modelled by department instead of by task and sensitivity. The implication is that privilege scope must be engineered as a constraint, not inherited from static group membership.

Modern identity attacks exploit authorization gaps more than authentication failures. The article’s core point is that legacy IAM still treats authentication as the finish line. In reality, the attacker’s advantage begins after the login succeeds, when risk signals, device posture, session behaviour, and entitlement scope are no longer being meaningfully evaluated. The implication is that identity security has shifted from proving who someone is to proving what they should be allowed to do right now.

Identity-centric attack resilience depends on visibility across human and non-human identities. The article correctly notes contractors, vendors, service accounts, bots, and APIs as part of the active identity surface. That is important because the same governance weakness often spans all of them: fragmented records, static access, and weak lifecycle closure. The implication is that identity programmes should be designed as one control system across human IAM, NHI governance, and privileged access, not three disconnected efforts.

What this signals

Identity context is now the boundary of access control. A login event alone tells you little about whether the request should be allowed, especially when the same identity can appear across SSO, PAM, lifecycle, and non-human account systems. Programmes that still treat authentication success as the main control signal will keep missing post-login abuse.

Legacy IAM exposes an identity blast radius problem. Broad groups, duplicate records, and stale accounts turn one compromised identity into many reachable systems. Security teams should expect attackers to exploit the widest access path that governance allows, not the narrowest one that policy intended.

Human IAM and NHI governance now need shared identity reconciliation. The article’s contractor, vendor, service account, bot, and API examples point to one operational reality: access reviews and offboarding fail when identity state is scattered. Mature programmes should connect entitlement lifecycle, privilege management, and account inventory across all identity types.

For practitioners

• Audit identity visibility across all account types Map employees, contractors, vendors, service accounts, bots, and APIs into a single inventory so hidden access paths are not left outside governance.
• Add authorization controls after authentication Require post-login checks for device posture, session context, and risk signals before granting sensitive actions or elevated access.
• Reconcile fragmented identity records Match and merge duplicate identity records across SSO, MFA, PAM, and lifecycle tools so offboarding and recertification target every active account.
• Replace broad groups with task-based access Use context-aware provisioning so access maps to role, responsibility, and sensitivity instead of department-wide permission bundles.
• Review stale access after identity changes Treat role changes, exits, and vendor offboarding as high-risk events that can leave one identity record active when another is removed.

Key takeaways

• Legacy IAM is vulnerable because it treats successful authentication as a sufficient trust signal even when attackers reuse stolen credentials or hijacked sessions.
• Fragmented identity records and broad group-based access create stale permissions and hidden access paths that attackers can exploit.
• Identity security now depends on reconciled records, post-login authorization, and least-privilege access models that reflect current context.

Key terms

• Identity context: The entitlement, ownership, and purpose information that explains why an action occurred and whether it was expected. For security operations, identity context turns raw alerts into decisions by showing which human or non-human identity acted and what it was allowed to do.
• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
• Identity Reconciliation: The process of comparing authoritative identity records with live access data to find mismatches, missing owners, or stale entitlements. It is the operational bridge between inventory and governance, and it is essential when hidden access may exist outside the normal provisioning path.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.