Why does Identity and Access Management fail even when MFA is on?

MFA hardens only one of the four controls that make up Identity and Access Management: authentication. Authorization, lifecycle and monitoring stay open, and that is where valid-credential intrusions live. Verizon's 2025 DBIR puts credential abuse at about 22% of initial access, and CrowdStrike found 79% of 2024 detections used no malware at all.

Why MFA stops attacks but not intrusions

Microsoft's Digital Defense Report 2024 counts more than 600 million identity attacks against its customers every day, and more than 99% of them are password-based: spray, stuffing, replay. Against that flood, multi-factor authentication is close to a solved problem. Microsoft's identity team has argued for years that an account with MFA enabled is more than 99% less likely to be compromised by automated attacks, and nobody serious disputes it.

The number hides a category error, though. MFA is an authentication control. It answers one question, whether the party presenting the password owns the account, and it answers it once, at login. An intrusion is not a login. It is everything that happens after a login succeeds, using an identity the login never questioned.

Hold one worked example in mind for the rest of this piece: a service account created years ago for a nightly backup job, with a password that has never rotated and an exclusion from the MFA policy because a script cannot approve a push notification. Nothing about that account is exotic. Most directories hold dozens like it. Watching how it fares against each of the four IAM controls explains how an MFA rollout can be complete while the building stays open.

What are the four controls inside Identity and Access Management?

Identity and Access Management is the discipline that answers one question for every request a system receives: who is asking, and are they allowed. NIST SP 800–63–4 keeps the parts deliberately separate. Identity proofing establishes that a person exists before an account is created; authentication verifies that a returning subject is that person; federation carries the verified claim to other systems. Practitioners fold those into four operational controls.

Authentication proves the identity: password, MFA, passkey. Authorization decides what the proven identity may do, through roles, groups and permissions. Lifecycle creates the account when someone joins, changes it when they move, and removes it when they leave. Monitoring watches the identity after the login, because a valid session can still do invalid things.

Every product you have bought in this space sits inside one of those four boxes, and budgets tilt heavily toward the first. That is rational up to a point: authentication is where the automated volume lands, and it is the control with the best-measured return. The trouble is that the other three are not optional extras. They are the same system. A directory with strong authentication and weak authorization is a bank vault with a steel door and an open loading dock.

The backup account has already told you which door it will use. It cannot pass the first one, so it was excused from it.

Which identities does your MFA policy not cover?

When a team says MFA is on, it means MFA is on for the accounts the team was thinking about: employees with a phone in their pocket. The population that can log in is larger. Service accounts run jobs. Break-glass administrators exist precisely to work when the MFA provider is down. Legacy protocols such as SMTP basic auth or NTLM do not carry a second factor. Printers, scanners and appliances authenticate with whatever they were configured with on install day. Contractors get accounts before anyone enrols them.

In a mature directory the non-human identities usually outnumber the human ones, and almost none of them can hold a phone. So every MFA policy grows an exclusion list, and every exclusion is an account that authenticates with a password alone.

That is where the numbers meet the mechanism. The Verizon 2025 Data Breach Investigations Report puts credential abuse at roughly 22% of initial access, the single most common way into an organisation year after year. Those are not MFA bypasses in the technical sense. They are logins against accounts MFA never met.

Our backup account has a password sitting in a configuration file, and configuration files get pasted into tickets and wikis to help a colleague. Once that string is known, the domain controller has no second question to ask. The first door was never closed for this identity, because it was never built for it.

How does privilege creep turn a backup account into an admin?

A backup account needs to read files. Over years, it collects more. Someone adds it to a help desk group to close a ticket on a Friday; the ticket closes and the membership stays. A migration project grants it write access to a share and nobody revisits the grant when the project ships. This is privilege creep: access accumulates one reasonable decision at a time, and nobody is paid to sweep.

The consequence is that authorization, the second control, quietly stops matching the job. An attacker holding the account does not need to escalate. One query for the account's group memberships, and one more for what those groups can reach, returns a map: file servers, the ticketing system, and the ability to reset any non-admin user's password. Nobody decided that. It happened, the way it happens in every directory older than its administrators.

Least privilege is the control that closes this door, and it is unpopular for an honest reason: enforcing it means telling a working system no, and a working system has friends. Quarterly access reviews that rubber-stamp existing grants do not count. The useful version is narrower: for each non-human account, the set of permissions it actually exercised in the last ninety days, and nothing else.

Why disabling the user does not disable the identity

Lifecycle is usually described as joiner, mover, leaver. Teams are good at joiner, because a new hire complains on day one if the account is missing. They are slow at mover, because nobody complains about keeping access. They forget leaver entirely for anything without a badge photo.

Return to the backup account. The engineer who built the job leaves. Their user account is disabled the day they go, exactly as the process says. Their service account is untouched, because on paper it was never theirs. It belonged to a project, and projects do not get exit interviews. The result is an orphaned identity: a credential that outlives every human who understood it.

Orphaned accounts suit an intruder for a reason that is easy to miss. It is not only that nobody will disable them. It is that nobody is left who knows what their normal behaviour looks like, so nothing they do can register as abnormal. The IBM Cost of a Data Breach Report 2024 puts the average stolen-credential breach at 292 days from first access to containment. Nine and a half months is what an identity with no owner buys an attacker.

What does monitoring miss when every login succeeds?

Most security tooling is built to alert on failure: a wrong password, a blocked file, a malware signature, a brute-force burst, impossible travel between two countries. A valid identity doing permitted things trips none of it. The CrowdStrike 2025 Global Threat Report found that 79% of the detections it recorded in 2024 involved no malware at all; adversaries logged in with valid credentials and worked by hand.

That is what the fourth door, monitoring, has to see. The backup account reading the finance share in the small hours, from a workstation subnet it has never touched, moving ten times its usual volume, is four separate anomalies. None is a failure. Together they describe a valid identity behaving like a stranger. Identity threat detection and response, ITDR, is the discipline that asks the log that question: new source, new hour, new privilege, new volume, judged against a baseline per identity rather than a rule per attack. Most teams have the log. What they lack is the question.

Closing the four doors is not expensive, which is why it is so often left undone. The Microsoft report makes the case for the first door; the other three are a matter of hygiene. Inventory every identity that can log in, human or not; enrol the humans and put the machines behind a managed secret with a short rotation. Cut standing privilege to the job the account does this quarter. Give every non-human account a living owner, and retire it the day that owner leaves. Watch valid sessions for behaviour that does not fit the identity. Then run the backup account through each door again, and see which one still opens.

This article expands on our video "Why does Identity and Access Management fail even when MFA is on?" — watch it here.

Source: Microsoft Digital Defense Report 2024.