The breach reports that come out in the second half of 2026 share an awkward pattern: most of the compromised organizations had MFA deployed. Multi-factor authentication is mature enterprise technology in 2026 — the credential class is settled (phishing-resistant FIDO2, passkeys, hardware keys, deviceless cards), the operational reality is broadly deployed, and the regulatory framing now expects it as baseline. And yet breaches keep happening.
The reconciliation isn't that MFA failed. In most of these incidents, MFA didn't fail at all — the attacker never tried to defeat it. The attack patterns that produced the compromise were ones MFA was never structurally designed to address. Four attack patterns recur in the 2026 incident-pattern data, and all four share the property that defeating MFA isn't the path: toxic entitlement accumulation, insider misuse, shadow admin accounts, and privileged session abuse.
This piece is the 2026 enterprise reference on the gap MFA structurally cannot close — and on the IGA layer above MFA that closes it. Strong MFA is the precondition for everything else; that's not in doubt. The reference architecture we'll walk through is what gets layered above the MFA precondition. The companion pieces cover the layers in detail. The Phishing-Resistant MFA piece covers the credential layer this composes with. The Adaptive Authentication piece covers the session-level risk evaluation that runs alongside. The Continuous Authentication piece covers the post-sign-in assurance evaluation. On the CGov side, the Best IGA Solutions buyer guide covers the IGA layer this piece centers on, the ITDR piece covers the detection layer that complements it, and the ISPM piece covers the preventive posture audit. This piece is the bridge between the credential layer (ICC's territory) and the entitlement layer (CGov's territory).
Four attack patterns, one structural property — they don't require defeating MFA. MFA fires cleanly. The attack succeeds anyway. The gap is at the entitlement layer.
What MFA is for, and what it isn't for
MFA is the credential-layer control. The authentication ceremony establishes that the right user is presenting the right credential class at this moment. When MFA is phishing-resistant — passkeys, hardware FIDO2 keys, smart cards, the Identity Challenge Card for deviceless segments — the ceremony defeats the credential-class attacks an attacker would otherwise use: password compromise, password spray, credential stuffing, push-bombing, prompt-bombing, OAuth consent abuse on weakly bound flows, session-cookie theft of phishable classes.
The architectural value is real and worth defending. MFA-deployed organizations are substantially harder to compromise via the credential-attack path than non-MFA-deployed organizations. The CISA "phishing-resistant MFA" guidance, the NIST 800-63B Rev. 4 reauthentication requirements, the EO 14028 federal access requirements — the regulatory framing in 2026 reflects MFA's load-bearing role at the credential layer. None of this piece argues against MFA. The point is what MFA isn't.
MFA is not entitlement evaluation. The ceremony doesn't know what resources the user should be able to access; it only knows the user is the user. Whether the user should be in the system they just authenticated to is a different question — the entitlement question — answered by a different layer.
MFA is not behavioral evaluation. The ceremony doesn't know whether this session is going to be used the way the user normally uses sessions; it only knows the user is the user right now. Whether the post-authentication session behaves like the user — or like an attacker who just compromised the user's session — is a different question, answered by a different layer.
MFA is not inventory. The ceremony doesn't know what accounts exist in the environment; it only knows about the accounts that authenticate. The shadow admin account that no human ever uses is invisible to MFA, because it never produces an MFA event.
The four attack patterns this piece is about live entirely in the territory MFA doesn't cover. The reconciliation between "MFA was deployed" and "the breach happened anyway" is that the attack didn't go through MFA's territory at all.
What MFA catches vs what IGA catches
| Attack pattern | Caught by MFA | Caught by IGA |
|---|
| Password theft / credential stuffing | ✓ | — |
| Phishing of standing credentials | ✓ phishing-resistant class only | — |
| Push-bombing / MFA fatigue | ✓ with proper UX hygiene | — |
| OAuth consent grant abuse | ✓ partial — depends on app registration controls | ✓ via app catalog + entitlement review |
| Toxic entitlement accumulation | ✗ — user passes MFA cleanly | ✓ SoD rules + recertification |
| Insider misuse | ✗ — insider authenticates legitimately | ✓ behavioral baselining + risk-weighted review |
| Shadow admin accounts | ✗ — no MFA event fires | ✓ inventory audit + ISPM posture |
| Privileged session abuse | ✗ — MFA fired hours ago | ✓ session monitoring + ITDR detection |
| Privileged credential theft | ✓ when MFA is required | ✓ vaulting + just-in-time elevation |
| Service account abuse | ✗ — service accounts often bypass MFA | ✓ NHI governance + credential rotation |
| Federation broker compromise | ✗ partial | ✓ via federation trust audit |
| Stolen session cookie | ✓ if token binding deployed | ✓ via behavioral session evaluation |
The pattern in the table is clear. MFA owns the credential-attack column. IGA owns the entitlement and inventory columns. The mature 2026 architecture composes both, because neither owns the full pattern set.
Attack pattern 1: toxic entitlement accumulation
The most common attack pattern in 2026 breach reports has nothing to do with the attacker doing anything sophisticated. It's just that a user, over years of role changes and project assignments, accumulated entitlements that the system never reconciled. The user is legitimate. The MFA ceremony is legitimate. The combination of access the user can now reach is illegitimate, but no single grant ever crossed a policy line that anyone noticed.
The pattern looks like this. A user joins as an analyst with read-only access to financial reports. The user is promoted to senior analyst and gains read-write access to a different reporting tool — the analyst-tier access is never removed. The user joins a Sarbanes-Oxley audit project and gets temporary access to general ledger detail — the temporary access is never expired. The user moves to the treasury team and gets payment-initiation entitlements — the prior team's entitlements remain. Three years in, the user has analyst access plus senior-analyst access plus audit-project access plus treasury access. Any one of those alone is fine. The combination produces a segregation-of-duty violation that lets the user originate, approve, and reconcile a payment to themselves.
The MFA layer can't help. The user authenticates legitimately every time. The audit log shows clean ceremonies all the way through. The exploitation, when it happens, looks like normal authenticated activity — because that's exactly what it is.
The IGA layer catches this through two mechanisms. Segregation-of-duty rules, evaluated at the entitlement-grant moment and at recertification cycles, flag combinations that shouldn't coexist. Periodic certification campaigns surface accumulated entitlements that no longer have current business justification. The combination produces backlog the IGA layer remediates. Without the IGA layer, the toxic accumulation just keeps growing — and when it's eventually exploited, the breach report says "MFA was deployed" because MFA was deployed.
The Best IGA Solutions piece on CGov covers the IGA platforms that handle this layer. The Avatier post on revolutionizing access certification audits covers the operational approach to certification campaigns specifically.
Attack pattern 2: insider misuse
The insider is by definition someone who passes MFA legitimately. The credential class is sound. The ceremony fires cleanly. The audit log records exactly what the audit log was designed to record. None of that is the security question for insider threats.
The security question is whether the post-authentication behavior is consistent with what the insider should be doing — or whether the legitimate authentication is being used to do something illegitimate. A treasury operator with valid credentials can issue valid payments; an insider with the same credentials can issue valid-looking payments to accomplices. A database administrator with valid credentials can perform routine maintenance; an insider with the same credentials can exfiltrate the production dataset. The authentication is identical in both cases.
The IGA layer catches insider misuse through three mechanisms. Least-privilege baseline — the insider should have only the entitlements their current role actually requires, so the attack surface is bounded to that scope. Behavioral baselining — the insider's normal usage pattern is established, and deviations (sudden bulk data queries, unusual time-of-day activity, geographic anomalies) get flagged. Risk-weighted certification — high-impact entitlements (financial-system, PHI/PII access, admin privileges) get certified more frequently and with more scrutiny than routine entitlements. The combination doesn't eliminate insider risk, but it bounds the scope and produces detection.
The ITDR piece on CGov covers the behavioral-detection layer that extends IGA's baseline approach. The PAM piece covers the privileged-access-specific patterns where insider misuse risk concentrates.
Attack pattern 3: shadow admin accounts
The third pattern is the one MFA is most fundamentally unable to address. Shadow admin accounts — accounts with administrative privileges that no longer correspond to any active human user — exist in nearly every enterprise environment of meaningful size. They get created during integrations, migrations, vendor implementations, one-off projects. They get used briefly. They get forgotten. They remain in the directory, with administrative privileges, with credentials that may or may not have ever rotated, with no owner, with no MFA enrollment because nobody enrolls them.
When attackers find shadow admin accounts — through credential spraying, breach-corpus matches, insider knowledge, OSINT on legacy integrations — the result is immediate privileged access. The attacker authenticates as the shadow admin. No MFA event fires because no MFA was enrolled. The administrative actions proceed unobserved because nobody is watching an account that nobody knew existed.
The MFA layer literally cannot catch this. The architectural assumption of MFA is that there's a user to enroll. Shadow admin accounts are precisely the accounts where that assumption fails.
The IGA inventory layer is the right control. The catalog of accounts in the environment should match the catalog of accounts that have business justification. Accounts that exist in target systems but not in the IGA catalog are by definition shadow accounts. Accounts in the catalog that no longer have active owners are orphans. The ISPM piece on CGov covers the posture-audit layer that surfaces this specific finding category. The Service Account Governance / NHI piece covers the parallel inventory for service accounts and AI agents.
When MFA gets deployed in an environment with unresolved shadow admin accounts, the breach risk from shadow admin doesn't go down — MFA didn't touch the relevant layer. The risk only goes down when the inventory layer catches up.
Attack pattern 4: privileged session abuse
The fourth pattern is the most architecturally subtle. A legitimate user authenticates with strong MFA. The credential class is phishing-resistant. The ceremony is sound. A session is established. Then — through cookie theft, token theft, browser compromise, malware on the user's device, supply-chain compromise of a browser extension — the attacker captures the authenticated session and rides it. The user doesn't notice. The IdP doesn't notice. The MFA event fired hours or days ago and is no longer in the path.
The attack happens in the territory after authentication, which means MFA is not the relevant control. The relevant controls are the post-authentication behavioral evaluation and the entitlement-level constraints on what the captured session can actually do.
The IGA layer constrains the blast radius. If the user's standing entitlements are narrowly scoped (the least-privilege baseline), the captured session is correspondingly bounded. If high-impact actions require step-up to a fresh credential ceremony (continuous authentication), the captured session can't perform those actions without triggering re-authentication. If service accounts and privileged accounts are isolated from human session reuse (vaulting, just-in-time elevation), the captured session can't pivot to elevated privilege.
The ITDR layer detects the abuse. Behavioral baselining establishes what the user normally does in their authenticated sessions. The captured session, even if technically valid, will behave differently — different navigation patterns, different query patterns, different time-of-day activity, different data-access shapes. ITDR catches the divergence and either alerts or terminates the session.
The Continuous Authentication piece covers the assurance re-evaluation pattern that extends MFA's session-establishment evaluation into post-session-establishment territory. The ITDR piece covers the detection layer for post-authentication behavioral anomalies.
The MFA + IGA + ITDR composition
The 2026 reference architecture composes three layers, not one. MFA is the credential layer — it answers "is this the right user with the right credential class right now." IGA is the entitlement layer — it answers "should this user have this access, and if not, when will that change." ITDR is the detection layer — it answers "is the authenticated session behaving the way the user normally would."
Each layer addresses attack patterns the others cannot. MFA-only architectures leave the four patterns this piece describes uncovered. IGA-only architectures leave the credential-attack patterns uncovered. ITDR-only architectures leave the entitlement and inventory questions uncovered. The composition is what produces the complete envelope.
The architectural test in 2026 is whether each layer is operationally mature, not whether each layer exists on paper. A deployed IdP with MFA configured but no certification campaigns running is the MFA layer without the IGA layer. A deployed IGA platform with workflows defined but no behavioral analytics watching sessions is the IGA layer without the ITDR layer. The breach risk concentrates in the layer that's missing — which is why "we have MFA" alone isn't the answer the 2026 breach reports are looking for.
The Avatier integration history is worth noting here as context. The Avatier Password Management Now Works with DUO integration shipped years ago — Avatier's MFA integration depth is mature. Avatier Identity Anywhere Lifecycle Management provides the IGA layer the architecture this piece describes composes with. The platform supports both the credential layer and the entitlement layer in one architecture, with integration into the detection layer for end-to-end coverage.
The reference path
Deploy MFA at the credential layer with phishing-resistant credentials as baseline (the Phishing-Resistant MFA piece covers this layer in detail). For deviceless workforces, the Identity Challenge Card provides the FIDO2 ceremony without smartphone dependency.
Compose the IGA layer above the MFA layer. Run certification campaigns that catch toxic entitlement accumulation. Build segregation-of-duty rules that flag accumulated combinations. Maintain the identity catalog so shadow accounts surface. Recertify high-impact entitlements more frequently than routine entitlements.
Add the ITDR layer beside the IGA layer. Build behavioral baselines per user. Watch for session-level anomalies that suggest captured-session abuse. Extend the detection envelope to cover post-authentication patterns the credential layer can't.
Build the ISPM posture-audit layer that catches what the operational layers miss. The ISPM piece covers the preventive posture-audit category that surfaces shadow accounts, drifted configurations, and dormant entitlements before they're exploited.
Compose all four into one architecture. MFA + IGA + ITDR + ISPM is the 2026 reference. The four layers together cover the attack surface that any one of them covers only partially.
The breach reports of late 2026 and 2027 will continue to share the awkward pattern of compromised organizations with MFA deployed. The reconciliation will keep being the same: MFA was deployed, MFA worked, the attack didn't go through MFA's territory. The architectural answer is to stop expecting MFA to do work it was never designed to do — and to compose the layers above it that close the gap.
Strong authentication is necessary. It's never sufficient. Make sure the rest is in place.
