MFA is the mitigation every audit asks about, yet attackers now routinely walk around it with session cookies, push fatigue and accounts that never had a second factor in the first place. MITRE ATT&CK lists M1032 Multi-factor Authentication against 48 techniques and sub-techniques in v20, more than most identity mitigations. This guide reads that mapping as a control owner would: which techniques MFA genuinely stops, which ones ATT&CK itself warns can bypass it, where non-human identities fall outside MFA altogether, and how to prove coverage. It is written for identity engineers, detection engineers and security architects. For choosing methods and rolling out FIDO2, see the Phishing-Resistant MFA Guide; this page does not repeat it.
Key takeaways
- M1032 mostly protects the moment of sign-in. Its strongest mappings are T1110 Brute Force, T1078 Valid Accounts and T1133 External Remote Services, where a stolen password alone stops being enough.
- ATT&CK names its own bypasses. The T1133 usage text tells defenders to be aware of T1111 Multi-Factor Authentication Interception, and T1621 exists precisely because push approvals can be spammed.
- Method matters more than presence. For T1539 Steal Web Session Cookie, ATT&CK says only a hardware token that binds the login domain prevents theft through proxies, which rules out codes and pushes.
- Machines cannot do MFA. Service accounts, API keys, OAuth clients and managed identities authenticate with a single secret or token, so M1032 has no reach there and other controls must carry the load.
- The gap is usually exclusions. Legacy protocols, break-glass accounts, vendor accounts and "temporary" exceptions are where real breaches enter, so coverage has to be measured per account and per protocol.
What M1032 is in ATT&CK v20
M1032 was created in June 2019; its page shows version 1.1, last modified 9 May 2025, with 48 entries (19 techniques and 29 sub-techniques). The description goes further than most mitigations and lists measures: enforcing MFA through the identity platform, Conditional Access for risky sign-ins and trusted devices, authenticator apps and hardware tokens, RADIUS or NPS to bring MFA to VPN and RDP logins, and SIEM alerting on failed MFA attempts and new device registrations. MITRE D3FEND relates M1032 to a single defensive technique, D3-MFA Multi-factor Authentication.
Techniques M1032 mitigates, by tactic
The table covers all 48 v20 mappings, grouped by parent technique. "How MFA helps" paraphrases ATT&CK's usage text.
| Tactic | Technique (mapped sub-techniques) | How MFA helps, per ATT&CK |
|---|---|---|
| Initial Access, Persistence, Privilege Escalation, Stealth | T1078 Valid Accounts (.001 Default, .002 Domain, .003 Local, .004 Cloud) | MFA across all account types, including default and local accounts, so a stolen password is not enough |
| Initial Access, Persistence | T1133 External Remote Services | Strong MFA for remote service accounts, while watching for T1111 interception |
| Initial Access | T1199 Trusted Relationship; T1669 Wi-Fi Networks | MFA for all delegated administrator accounts; two pieces of evidence to join Wi-Fi |
| Credential Access | T1110 Brute Force (.001 to .004 guessing, cracking, spraying, stuffing) | MFA, especially on externally facing services |
| Credential Access | T1621 MFA Request Generation | Replace simple push or one-click approvals with code entry or other out-of-band methods |
| Credential Access | T1539 Steal Web Session Cookie | Hardware tokens that bind the login domain prevent cookie theft through proxies |
| Credential Access, Discovery | T1040 Network Sniffing | Sniffed passwords lose value where MFA is enforced |
| Credential Access, Persistence, Defense Impairment | T1556 Modify Authentication Process (.001, .003, .004, .006, .007) | MFA policy that covers dormant accounts and devices, and fails closed on errors (T1556.006) |
| Persistence, Privilege Escalation | T1098 Account Manipulation (.001, .002, .003, .005, .006) | MFA for privileged accounts; MFA for CreateKeyPair and ImportKeyPair calls; MFA to register devices; MFA for cluster users |
| Persistence | T1136 Create Account (.001 to .003) | MFA for user and privileged accounts |
| Lateral Movement | T1021 Remote Services (.001 RDP, .004 SSH, .007 Cloud Services) | MFA on remote logons; for SSH, ATT&CK suggests passphrase-protected keys where MFA is not possible |
| Execution, Lateral Movement | T1072 Software Deployment Tools | MFA to isolate access to critical deployment systems |
| Defense Impairment | T1599 Network Boundary Bridging (.001), T1601 Modify System Image (.001, .002) | MFA for network device administrators, through TACACS+ or RADIUS |
| Collection | T1114 Email Collection (.002), T1213 Data from Information Repositories (.003 Code Repositories), T1530 Data from Cloud Storage | MFA on webmail, code repositories and cloud storage APIs |
| Impact | T1485 Data Destruction | MFA delete on cloud storage such as Amazon S3 buckets |
Prioritising the mapping
NHI Mgmt Group suggests working through the mapping in this order, because it follows where stolen credentials are used first:
- Internet-facing sign-in: T1133 VPN, VDI and remote access portals, T1078.004 cloud consoles and T1110 against anything exposed. The Change Healthcare breach began with a stolen credential on a Citrix remote access portal that, in UnitedHealth's own testimony, did not have MFA.
- Privileged and delegated administration: T1098, T1136, T1199 and T1072. Administrator, partner and deployment tool accounts get phishing-resistant methods first.
- Method upgrades: T1621 and T1539. Remove plain push approvals, then move high-risk users to FIDO2 or PKI.
- Registration and recovery: T1098.005 and T1556.006. Require MFA to register a new device or method, and block enrolment for inactive accounts.
- Infrastructure and data planes: T1599, T1601 through TACACS+ or RADIUS on network devices; T1485 with S3 MFA delete; T1213.003 on code repositories.
What M1032 does not stop
These bypass classes are why MFA presence alone is a weak coverage claim. Each links to the technique that describes it; this page describes them at the defensive level only.
| Bypass class | ATT&CK technique | Why MFA does not help | What covers it |
|---|---|---|---|
| Push fatigue | T1621 | The user approves a prompt they did not start | Number matching as a stopgap, then phishing-resistant MFA (CISA) |
| Real-time phishing proxy | T1557, T1111 | Codes and pushes are relayed to the real site | FIDO2 or PKI that binds the origin |
| Session or token replay | T1539, T1550 (.001, .004) | MFA happened before the token was issued; the token is then accepted alone | Short token lifetimes, device binding, session revocation |
| Authentication tampering | T1556.006 | An attacker with admin rights changes or disables the MFA policy | Alert on policy change, fail closed |
| Recovery and help desk reset | T1098.005 | A new factor is registered through social engineering | Verified recovery, MFA to register methods |
| Single-factor machine credentials | T1078, T1528, T1552 | API keys and tokens have no second factor | Workload identity, vaulting, rotation, conditional token policy |
Two live incidents show the first and third rows. In the Uber breach of 2022 a contractor received repeated approval requests until one was accepted. In CitrixBleed attackers replayed leaked session cookies, which CISA said let them bypass password requirements and MFA; patching alone did not invalidate sessions already stolen. See the MFA Fatigue and Bypass Guide for response detail.
Where identity fits: the NHI gap
M1032 assumes a person who can hold a key or tap a prompt. Service accounts, CI/CD tokens, OAuth clients, API keys and AI agents cannot, so every technique in the table stays fully open for them. Microsoft's documentation for Conditional Access for workload identities states that workload identities cannot perform multifactor authentication; for service principals the only grant control is Block access, policies apply only to single-tenant service principals registered in the tenant, managed identities are not covered, and Workload Identities Premium licences are needed to create or change those policies. Other platforms differ in detail but share the constraint.
Where MFA cannot apply, NHI Mgmt Group recommends these substitutes:
- Replace static secrets: use federated, short-lived credentials. See the Workload Identity Federation Guide.
- Constrain where tokens work: location and risk conditions for service principals, IP allowlists on API keys, audience-restricted tokens.
- Keep humans in the loop for privileged machine actions: ATT&CK's T1098.001 text suggests requiring MFA for CreateKeyPair and ImportKeyPair through IAM policies, so the human who creates a credential is verified even if the credential itself is single-factor.
- Find the exclusions: service accounts are often exempted from MFA policies by name. See How to Find Accounts Excluded From MFA and Conditional Access and the Service Account Security Guide.
How to implement M1032 against the mapping
- Inventory sign-in paths, not users. List every protocol that accepts a password: web SSO, VPN, VDI, RDP, SSH, IMAP and POP, SMTP AUTH, network device consoles, code repositories, cloud CLIs. Legacy protocols that cannot carry MFA must be blocked or isolated.
- Enforce in report-only first. Run Conditional Access or equivalent policies in report-only mode for one to two weeks and review who would fail.
- Turn on enforcement in rings: administrators, then remote access, then all staff, then partners and contractors (T1199).
- Upgrade methods. NIST SP 800-63B-4 states that verifiers shall offer at least one phishing-resistant option at AAL2 and that AAL3 requires a phishing-resistant authenticator; it treats OTPs and out-of-band methods as not phishing-resistant and restricts SMS and voice.
- Protect the factor lifecycle. Require MFA to register new methods or devices, and block enrolment for dormant accounts (T1098.005, T1556.006).
- Cover data and infrastructure planes. TACACS+ or RADIUS with MFA for network devices; S3 MFA delete where retention matters. AWS documents that MFA delete requires versioning, can only be enabled by the bucket owner's root account through the CLI or API, and cannot be used with S3 Lifecycle configurations.
- Roll back safely. Keep two monitored break-glass accounts with phishing-resistant factors, excluded from Conditional Access but alerted on every sign-in.
Detection and measurement
- MFA coverage by account type: human, privileged, partner, service, with service accounts reported separately (see MFA Coverage Measurement).
- Single-factor sign-in rate: share of successful sign-ins in the last 30 days that completed without a second factor, by protocol.
- Phishing-resistant share: percentage of privileged users whose only allowed methods are FIDO2 or PKI.
- Push denial and timeout bursts: count of users with several denied or unanswered prompts in a short window (T1621 signal).
- Method registration events: new methods registered from new devices or locations, reviewed within one business day (see How to Detect MFA Method Registration Abuse).
- Exception age: number and median age of MFA exclusions in the exception register.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | M1032 Multi-factor Authentication | 48 mapped techniques and sub-techniques |
| MITRE D3FEND | D3-MFA Multi-factor Authentication | Related defensive technique |
| NIST SP 800-53 Rev 5 | IA-2(1), IA-2(2), IA-2(8), IA-5 | MFA for privileged and non-privileged accounts, replay resistance, authenticator management |
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware are authenticated |
| NIST SP 800-63B-4 | AAL2 and AAL3 | Phishing-resistant options and requirements |
Common failure patterns
- One portal left out: a remote access gateway or legacy app outside the SSO policy, as in the Change Healthcare breach.
- Push without context: plain approve or deny prompts that train users to tap yes.
- Patched but not revoked: sessions issued before a fix stay valid, as CitrixBleed showed.
- Permanent exclusions: service, vendor and test accounts excluded "temporarily" for years.
- Weak recovery: help desk resets that register a new factor on a phone call.
- MFA counted as NHI control: coverage reports that include service accounts as "MFA exempt" rather than as a separate risk with its own controls.
Practitioner checklist
- Map each of the 48 v20 mappings to the systems and protocols that implement them.
- Block or isolate every protocol that cannot carry MFA.
- Remove plain push approvals; require number matching at minimum.
- Move administrators and partners to FIDO2 or PKI.
- Require MFA to register methods and devices; block enrolment for dormant accounts.
- Alert on MFA policy changes and on break-glass sign-ins.
- Revoke sessions after any identity or gateway compromise.
- Report machine identities separately and apply workload identity, vaulting and token conditions.
Standards and references
- MITRE ATT&CK: M1032 Multi-factor Authentication
- MITRE D3FEND: Multi-factor Authentication
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- CISA: Implementing Phishing-Resistant MFA
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- Microsoft Learn: Conditional Access for workload identities
- AWS: Configuring MFA delete
Related NHI Mgmt Group resources: Phishing-Resistant MFA Guide, MFA Fatigue and Bypass Guide, Conditional Access Guide, NHI Authentication Guide, M1031 Network Intrusion Prevention.