A stolen password is only a working login if the password is the only thing the system asks for. D3-MFA Multi-factor Authentication is the MITRE D3FEND countermeasure that closes that gap: D3FEND defines it as "Requiring proof of two or more pieces of evidence in order to authenticate a user." It sits in the Harden tactic as a child of Agent Authentication, and D3FEND models it as a technique that uses the Credential artefact. This card explains what D3-MFA actually hardens, which ATT&CK techniques D3FEND relates it to, where it is implemented, how to prove it is working, and where it stops helping. It is written for identity engineers, detection teams and architects who already know what MFA is and want a precise view of its defensive reach. For the wider programme view, see the MFA Guide.
Key takeaways
- D3-MFA hardens the credential, not the session. It raises the cost of turning a stolen password into a login, but a session cookie or access token issued after MFA carries no second factor of its own.
- D3FEND relates it to a long list of credential techniques. The mapping runs through the shared Credential artefact, so treat it as "this control is relevant" rather than "this control blocks it outright".
- Factor type decides most of the value. CISA and NIST SP 800-63B both separate phishing-resistant authenticators (FIDO2/WebAuthn, PKI) from codes, push and SMS, which can be relayed or abused.
- Exclusions are where MFA fails in practice. Legacy protocols, break-glass accounts and service accounts that cannot answer a prompt are the paths attackers look for first.
- Verify with tests and coverage numbers, not policy screenshots. Run sign-in tests per protocol and per account class, and measure how many interactive sign-ins actually completed a second factor.
D3-MFA at a glance
| Field | D3-MFA Multi-factor Authentication |
|---|---|
| D3FEND ID | D3-MFA |
| Tactic | Harden |
| Parent technique | Agent Authentication (siblings: Biometric Authentication, Certificate-based Authentication, Password Authentication, Token-based Authentication) |
| Digital artefact | Credential (D3FEND: the technique "uses" a Credential) |
| What it changes | The authentication decision: a login needs evidence from two or more categories (know, have, are) before a session is issued |
| Typical implementation points | Identity provider and single sign-on, VPN and remote access gateways, cloud console sign-in, privileged access tools, operating system logon (smart card, platform authenticators) |
| Typical data sources for verification | Identity provider sign-in logs with authentication method detail, conditional access or policy evaluation results, MFA registration and method-change audit events |
| Effort | Moderate to enable; high to finish (legacy protocols, exceptions, recovery flows, non-interactive accounts) |
| Main limitation | Post-authentication artefacts (cookies, tokens) and non-human identities are outside its reach |
| Related ATT&CK mitigation | M1032 Multi-factor Authentication (D3FEND links M1032 to D3-MFA) |
How it works
D3FEND's knowledge base entry describes the mechanism simply: users present two or more credentials from different categories, something you know (a password or PIN), something you have (a smart card or phone) and something you are (a fingerprint). It also flags the main operational consideration: MFA configuration can vary across accounts and is sometimes left to users to switch on. The reference D3FEND cites for D3-MFA is the RSA Security patent for a token that combines a secret user code, a time-varying value and a PIN into a one-time code, which is the origin of the hardware OTP token.
What matters for defence is the strength of the second factor, because attackers adapt to whatever is deployed:
- Shared-secret codes (TOTP, HOTP, SMS, voice): the code is typed by the user, so an adversary-in-the-middle proxy can capture and relay it in real time. CISA lists SMS and voice as vulnerable to phishing, SS7 interception and SIM swap, and as a last resort only.
- Push approval: without number matching, push is open to push bombing (repeated prompts until the user accepts). CISA groups push with number matching with app-based OTP: still phishable, but resistant to push bombing.
- Phishing-resistant authenticators (FIDO2/WebAuthn, PKI smart cards): the private key signs a challenge bound to the relying party, so a credential presented to a look-alike site is useless to the real one. CISA calls phishing-resistant MFA "the gold standard" and names FIDO/WebAuthn as the only widely available option.
NIST SP 800-63B-4 turns these differences into assurance levels: AAL2 needs two distinct factors and verifiers must offer at least one phishing-resistant option (federal agencies must require it for their staff, contractors and partners), while AAL3 needs phishing-resistant cryptographic authentication with a non-exportable private key. The same document classes out-of-band authentication over the public telephone network (SMS and voice) as "restricted" and prohibits email for out-of-band authentication. Syncable passkeys are permitted at AAL1 and AAL2 but not at AAL3. See the Phishing-Resistant MFA Guide for authenticator selection.
Where identity and NHIs fit
D3-MFA is defined for users. Service accounts, API keys, CI/CD tokens and AI agents authenticate without a person at a keyboard, so they cannot answer a prompt. In practice this creates two problems. First, non-human accounts get excluded from MFA policies, and those exclusions are then reused by people or attackers. Second, the session and access tokens that MFA protects at issue time become standalone credentials afterwards. The hardening equivalent for workloads is a different D3FEND sibling, Certificate-based or Token-based Authentication, delivered through short-lived, federated credentials. See the How to Find Accounts Excluded From MFA and Conditional Access and the Workload Identity Federation Guide.
ATT&CK techniques D3FEND relates to D3-MFA
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-MFA; every row below is inferred through a shared digital artefact (checked November 2026).
D3FEND does not hand-map D3-MFA to ATT&CK. Every row below is an inferred relationship that D3FEND derives through shared digital artefacts: D3-MFA uses Credential, and its parent Agent Authentication strengthens User Account, so ATT&CK techniques that act on a Credential, a User Account or one of their sub-artefacts are related to it. The relation column shows which. D3FEND also lists Keychain under an ID that ATT&CK has since revoked; its ATT&CK v20 successor is T1555.001. Each ID was checked against ATT&CK v20 (D3FEND checked November 2026). The last column is NHI Mgmt Group's assessment of how much MFA changes the outcome in practice, not part of D3FEND.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What MFA changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1110.001, T1110.002, T1110.003 | Password Guessing, Password Cracking, Password Spraying | Sub-artefact: Password | Strong: a guessed or cracked password no longer completes an interactive login on protected paths |
| T1078.001, T1078.002, T1078.003, T1078.004 | Valid Accounts: Default, Domain, Local, Cloud Accounts | Sub-artefacts of User Account | Strong where enforced; none on paths that skip MFA (legacy protocols, excluded or service accounts) |
| T1003.003, T1003.005, T1003.008 | NTDS, Cached Domain Credentials, /etc/passwd and /etc/shadow | Sub-artefact: Encrypted Credential | Partial: dumped hashes still work on protocols that never ask for a second factor (for example NTLM pass-the-hash or Kerberos) |
| T1555.001 | Keychain | Sub-artefact: Encrypted Credential | Partial: limits reuse of harvested passwords against MFA-protected sign-ins |
| T1552 | Unsecured Credentials | Same artefact: accesses Credential | Partial: helps for human passwords found in files; no effect on API keys or tokens |
| T1558.001 | Golden Ticket | Sub-artefact: Kerberos Ticket Granting Ticket | Minimal: a forged Kerberos ticket is presented after authentication |
| T1606.001 | Web Cookies (Forge Web Credentials) | Sub-artefact: Session Cookie | Minimal: forged cookies represent an already-authenticated session |
| T1528, T1539 | Steal Application Access Token, Steal Web Session Cookie | Sub-artefact: Access Token, Session Cookie | Minimal at use time: the stolen artefact was issued after MFA; MFA only helps if the token theft starts with a password login |
| T1550.001, T1550.004 | Application Access Token, Web Session Cookie (Use Alternate Authentication Material) | Sub-artefact: Access Token, Session Cookie | Minimal: these techniques exist to bypass the authentication step |
| T1134.001, T1134.002, T1134.003 | Token Impersonation/Theft, Create Process with Token, Make and Impersonate Token | Sub-artefact: Access Token | Minimal: local access tokens act after logon |
| T1098.001, T1098.002, T1098.003 | Additional Cloud Credentials, Additional Email Delegate Permissions, Additional Cloud Roles | T1098.001 same artefact (creates Credential); others via User Account sub-artefacts | Partial: MFA or step-up on admin actions slows the attacker; added keys and secrets for apps bypass user MFA entirely |
| T1136.001, T1136.002, T1136.003 | Create Account: Local, Domain, Cloud Account | Sub-artefacts of User Account | Partial: new accounts are only blocked from use if registration also requires MFA |
| T1548.005 | Temporary Elevated Cloud Access | Sub-artefact: Cloud User Account | Partial: helps where elevation requires fresh MFA |
| T1087.001, T1087.002, T1087.004 | Account Discovery: Local, Domain, Cloud Account | Sub-artefacts of User Account | Indirect: limits which discovered accounts are usable |
| T1531 | Account Access Removal | Same artefact: modifies User Account | Indirect: protects the admin sign-ins used to lock others out |
Two techniques that target MFA itself are not in D3FEND's D3-MFA mapping but matter to anyone deploying it: T1621 Multi-Factor Authentication Request Generation (push bombing) and T1111 Multi-Factor Authentication Interception. See the MITRE ATT&CK T1621 Multi-Factor Authentication Request Generation and the MITRE ATT&CK T1111 Multi-Factor Authentication Interception. For the token techniques where MFA does least, see the MITRE ATT&CK T1539 Steal Web Session Cookie and the MITRE ATT&CK T1098.001 Account Manipulation.
Where it is implemented
| Enforcement point | What to configure | Typical gap |
|---|---|---|
| Identity provider and SSO | Policy requiring MFA for all interactive sign-ins, authentication strength or method restrictions per application and role | Applications not behind SSO, or SSO bypass via local accounts |
| Legacy and basic authentication protocols | Block protocols that cannot carry a second factor (basic authentication to mail and directory endpoints) | Old mail clients, scanners and scripts that keep the protocol enabled |
| Remote access (VPN, VDI, gateways) | MFA at the gateway, ideally through the identity provider | Appliance-local accounts and test portals |
| Cloud provider consoles and CLIs | MFA for root and administrative users, MFA conditions on role assumption where the platform supports it | Long-lived access keys that never see MFA |
| Privileged access tools | Step-up MFA at session checkout and for sensitive actions | Break-glass accounts kept outside the tool |
| Operating system logon | Smart cards or platform authenticators for administrator workstations and servers | Network logons (SMB, RDP with saved credentials) that accept a hash or ticket |
| Registration and recovery | MFA or verified identity to add or change a method, recovery codes held securely | Help desk resets that skip identity checks |
Recovery deserves its own design: if a method can be replaced with a phone call to the help desk, the attacker targets the help desk. See the How to Detect MFA Method Registration Abuse.
Implementation steps
- Inventory every authentication path. List each application, protocol and gateway, which identity store it trusts, and whether it can enforce a second factor. Include non-interactive accounts and break-glass accounts.
- Protect the highest-value targets first. Follow CISA's ordering: administrators, identity systems, email, remote access and file servers, with help desk and IT staff as early adopters of phishing-resistant methods.
- Run policies in report-only or audit mode. Most identity providers can evaluate a policy without enforcing it. Use a week or two of results to find users, devices and apps that would be blocked.
- Enforce in rings. Pilot group, IT, then business units. Keep a tested rollback: the ability to switch a policy back to report-only and a documented, monitored break-glass account.
- Retire weak factors. Turn on number matching for push, then move privileged users to FIDO2/WebAuthn or PKI. Keep SMS only where nothing else works, with an expiry date on the exception.
- Close the bypasses. Block legacy protocols, require MFA for method registration, and shorten session lifetimes for privileged roles in line with NIST's AAL3 guidance (overall reauthentication within 12 hours).
- Move non-human identities out of user policies. Replace service accounts that sit in MFA exclusion groups with workload identities or short-lived credentials, so exclusions shrink rather than grow. Track what remains in a register; see the MFA Exception Register Template.
How to verify it works
Policy configuration shows intent; tests and logs show effect. Verify on four fronts:
- Negative sign-in tests: with a test account and correct password, try each path (browser, mobile app, legacy protocol, VPN, CLI). Every interactive path should demand a second factor or refuse the protocol.
- Phishing-resistance test: in an authorised exercise, confirm that privileged users cannot complete sign-in with a relayable method (code or push) on applications that require phishing-resistant strength.
- Push bombing test: send repeated prompts to a test account and confirm number matching applies and that the identity provider raises an alert on prompt volume.
- Log review: confirm sign-in logs record the authentication method and the policy decision for each event, and that single-factor successes are rare and explained.
| Metric | What it shows | Target direction |
|---|---|---|
| Share of interactive sign-ins completed with MFA | Real coverage, not configured coverage | Near 100% for workforce; 100% for admins |
| Share of privileged accounts using phishing-resistant methods | Readiness against adversary-in-the-middle phishing | Rising to 100% |
| Accounts in MFA exclusion groups, by type (human, service, break-glass) | Size of the bypass surface | Falling; every entry with an owner and expiry |
| Single-factor successful sign-ins per week | Unprotected paths still in use | Falling toward zero |
| MFA method changes not preceded by a verified sign-in | Recovery and registration abuse | Zero, each one investigated |
| Denied or abandoned push prompts per user | Push bombing attempts | Alerts reviewed within the SOC's normal triage window |
For a worked measurement method across human and non-human identities, see MFA Coverage Measurement.
Limits, bypasses and failure patterns
- MFA missing on one platform: in the Snowflake breach, credentials harvested by infostealers opened about 165 customer accounts that had no MFA, so a username and password were the only check. Coverage has to include every SaaS tenant that holds data, not only the corporate SSO.
- Approval fatigue: in the Uber breach, an attacker holding a contractor's password, which Uber believes was bought on the dark web, repeated push requests until one was accepted. Number matching and phishing-resistant methods remove this path. See the MFA Fatigue and Bypass Guide.
- Session token theft after MFA: in CitrixBleed 2023, session cookies leaked from the appliance gave attackers authenticated sessions without a password or second factor, and patching did not invalidate cookies already taken. D3-MFA needs session controls beside it: token binding where available, short lifetimes and session revocation in incident response.
- Exclusions that never close: service accounts and "temporary" exceptions placed outside MFA policy accumulate and are rarely reviewed.
- Weak recovery: a strong factor is undone by a reset process that accepts a phone call or an email.
- Hash and ticket reuse inside the network: protocols such as NTLM and Kerberos accept material that never passes through the MFA prompt, which is why the mapping above shows only partial effect for credential dumping.
Framework mapping
| Framework | Reference | Relationship to D3-MFA |
|---|---|---|
| MITRE ATT&CK | M1032 Multi-factor Authentication | The ATT&CK mitigation D3FEND links to D3-MFA |
| NIST SP 800-53 Rev 5 | IA-2(1), IA-2(2) | Multi-factor authentication to privileged and non-privileged accounts |
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware are authenticated |
| NIST SP 800-63B-4 | AAL2 and AAL3 | Assurance levels that define how strong the factors must be |
| CISA | Implementing Phishing-Resistant MFA fact sheet | Ranks MFA types and sets a rollout order |
Related countermeasures
- Siblings under Agent Authentication: Biometric Authentication, Certificate-based Authentication, Password Authentication and Token-based Authentication. Certificate-based and token-based authentication are the routes for workloads that cannot use MFA.
- Session-side controls: D3-ANCI Authentication Cache Invalidation and credential eviction techniques cover the period after MFA, where stolen cookies and tokens are used.
- Deception: a decoy session token is one way to detect replayed session material that MFA cannot stop.
For how D3FEND is organised and how to use it in a control programme, see the MITRE D3FEND Guide.
Practitioner checklist
- Map every authentication path, including legacy protocols, gateways, cloud consoles and break-glass accounts.
- Require MFA for all interactive sign-ins and phishing-resistant methods for all privileged roles.
- Turn on number matching for push and set an end date for any SMS or voice exception.
- Block legacy authentication protocols that cannot carry a second factor.
- Require a verified sign-in or identity check before any MFA method is added or changed.
- Move service accounts out of user MFA policies onto workload identities or short-lived credentials, and keep the remaining exclusions in a register with owners and expiry dates.
- Pair MFA with session controls: short privileged session lifetimes, revocation on incident, and monitoring for token replay.
- Report sign-in level MFA coverage, phishing-resistant coverage and exclusion counts every month.
Standards and references
- MITRE D3FEND: Multi-factor Authentication (D3-MFA)
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- CISA: Implementing Phishing-Resistant MFA
- MITRE ATT&CK: M1032 Multi-factor Authentication
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- RSA Security Inc.: Method and apparatus for utilizing a token for resource access (US5657388A)
Related NHI Mgmt Group resources: MFA Guide · Phishing-Resistant MFA Guide · Top 10 MFA Mistakes · MITRE ATT&CK T1078 Valid Accounts Guide · MITRE D3FEND Guide