MITRE D3FEND Agent Authentication Implementation Guide: Choosing, Combining and Testing Authentication Methods

Most estates run five or six authentication methods side by side, for people, services and devices, and few teams can say which method protects which account class or which attacks each one actually raises the cost of. MITRE D3FEND groups these methods under Agent Authentication (D3-AA), a parent technique that enables the Harden tactic and has five children: password, token-based, biometric, certificate-based and multi-factor authentication. This guide treats D3-AA as a programme: what the family covers, how to choose and combine the children for each kind of account, how to sequence the work, what to measure and where it goes wrong. It is written for identity architects, IAM engineers and detection teams. Each child technique has its own deep page, linked below, so this page does not repeat their settings. For D3FEND itself see the MITRE D3FEND Guide.

Key takeaways

• "Agent" means any actor, not only AI agents. D3FEND defines an Agent as "an entity capable of performing intentional actions", so D3-AA covers people, service accounts, workloads and devices alike.
• The family has five children, each a different evidence type. Something known (D3-PWA), something held as a token (D3-TBA), something you are (D3-BAN), a private key with a certificate (D3-CBAN), and the combination of factors (D3-MFA).
• The parent strengthens the User Account artefact. In the ontology D3-AA authenticates an Agent and strengthens a User Account; its children add relations to Password, Access Token, Certificate and Credential.
• The ATT&CK links are inferred and broad. D3FEND lists 33 related ATT&CK techniques and sub-techniques, from brute force to golden tickets, and labels them inferred and experimental. Read them as "relevant to", not "blocked by".
• Choosing by account class is the real work. Humans, services and devices cannot all use the same child; the programme is a matrix of account class against method, with gaps closed in priority order.

What D3FEND means by Agent Authentication

D3FEND defines Agent Authentication as "the process of verifying the identities of agents to ensure they are authorized and trustworthy participants within a system". Its only listed reference is NIST SP 800-53 Revision 5, which places authentication in the IA (Identification and Authentication) family. The ontology models three relations for the parent: it authenticates an Agent, it strengthens a User Account and it enables Harden.

Two boundaries are worth fixing early. First, D3-AA is about proving who is acting; it does not decide what that actor may do, which D3FEND models under Access Policy Administration and enforces under Access Mediation (see the MITRE D3FEND Access Mediation Implementation Guide). Second, protecting the credential itself (rotation, password policy, pinning, token binding) sits in a separate parent, Credential Hardening (D3-CH), covered in the companion MITRE D3FEND Credential Hardening Implementation Guide. A sound programme needs all three.

The five child techniques

The table lists every child of D3-AA in the D3FEND ontology, with D3FEND's definition in short form and the account classes each one realistically serves. The account-class column is NHI Mgmt Group's view, not part of D3FEND.

Two points from the child pages shape the whole family. D3-BAN does not apply to non-human identities at all, and NIST SP 800-63B-4 allows biometrics only as part of multi-factor authentication with a physical authenticator. D3-TBA, by contrast, is where most non-human authentication now lives, and the result is a bearer token: whoever holds it is accepted unless it is bound to a key.

Choosing a method by account class

D3FEND does not say which child to use where. The matrix below is NHI Mgmt Group's recommendation, based on current NIST guidance and the deep pages linked above. "Primary" means the method that should carry the authentication; "supporting" means it appears inside another method.

Decision rules

• Can the actor answer a prompt? If not, D3-MFA and D3-BAN are out. Use D3-CBAN or D3-TBA backed by a key the workload holds; SPIFFE, for example, issues short-lived X.509 and JWT identity documents (SVIDs) to workloads for exactly this purpose.
• Is the credential replayable? Passwords, one-time codes and bearer tokens are. NIST SP 800-63B-4 states that one-time password authentication is not phishing-resistant. Prefer methods where a private key never leaves the actor.
• Who issues and revokes? Certificates move the trust to the PKI and tokens move it to the issuer. Choose the method whose issuer you already operate well, and see the MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide for the PKI risks.
• Small versus large organisations. A small organisation gets most value from an identity provider enforcing phishing-resistant D3-MFA for every person and from replacing static service passwords with platform-managed identities. Large estates add D3-CBAN for workloads, Kerberos PKINIT for smart card users (see the Kerberos PKINIT and Certificate Mapping Guide) and formal token lifetime standards.

Combining and sequencing the children

The children are rarely used alone. A typical sign-in chains three of them: a biometric unlocks a key on the device (D3-BAN), that key signs a challenge as part of multi-factor authentication (D3-MFA, often realised through D3-CBAN-style public key cryptography), and the identity provider then issues a session or access token (D3-TBA). The weakest link in that chain sets the strength of the whole. Strong sign-in followed by a 30-day bearer session cookie leaves the session as the target, which is why ATT&CK techniques such as T1539 Steal Web Session Cookie and T1550.004 Web Session Cookie appear in D3FEND's mapping for the family.

A sensible programme order, which is our recommendation rather than D3FEND's:

1. Inventory account classes and methods. For every identity store, record each account class, the method in use, and every exception (legacy protocols, MFA exclusions, shared accounts). The How to Find Accounts Excluded From MFA and Conditional Access walkthrough helps here.
2. Fix the password baseline (D3-PWA). Apply the NIST SP 800-63B-4 verifier rules: 15 characters for single-factor use, blocklist screening and no periodic forced change, and remove default passwords.
3. Enforce D3-MFA for remote and privileged people first. Pilot with IT staff, then expand by ring. Keep break-glass accounts out of scope only with compensating controls and alerting.
4. Move non-human accounts off passwords. Replace static service passwords and long-lived keys with D3-CBAN or federated D3-TBA. See the Service Account Security Guide.
5. Shorten and bind tokens. Set token and session lifetimes per risk tier, and where the platform supports it bind tokens to keys with mutual TLS or DPoP (RFC 9449). Token binding sits in D3-CH; see D3-TB Token Binding.
6. Move people to phishing-resistant methods. Replace codes and push with passkeys or certificates, starting with administrators.

Testing and rollback: run each change in report-only or audit mode where the identity provider supports it, review the sign-ins that would fail, then enforce in rings. Keep a documented rollback per ring (return the policy to report-only) and an out-of-hours owner. For workloads, run the old and new credential in parallel until telemetry shows zero use of the old one.

Inferred ATT&CK relations for the family

D3FEND relates D3-AA to ATT&CK through the artefacts it acts on: it strengthens User Account, uses Password and Access Token, reads Certificate and uses Credential. The D3FEND site labels these relations inferred and experimental. The table groups the techniques it lists by ATT&CK v20 tactic; several appear under more than one tactic and are shown once.

Use the table as a test plan. For each child you deploy, emulate the relevant techniques safely in a test environment and confirm both that the attempt fails and that it is logged. The MITRE ATT&CK T1078 Valid Accounts Guide and MITRE ATT&CK T1110 Brute Force Guide cover the two most common families in depth.

Where identity fits

D3-AA is identity by definition, but the non-human share is where most programmes lag. Service accounts, API clients, CI runners and AI agents usually outnumber people, cannot use D3-BAN or interactive D3-MFA, and are often left on D3-PWA with passwords that never change. The children that fit them are D3-CBAN and D3-TBA, with credentials issued to a workload identity, kept short-lived and scoped to one audience. See the Non-Human Identity (NHI) Guide and the Cloud Workload Identity Guide.

Detection and measurement

Authentication logs are the main telemetry: identity provider sign-in logs, domain controller events, certificate authority issuance logs and token service logs. Useful detections include a non-human account signing in interactively, a sign-in that skipped MFA through a legacy protocol, a certificate issued with a subject that does not match its requester, and a token used from a network or client it was never issued to.

Metrics we suggest at NHI Mgmt Group (example targets, not standards):

1. Method coverage: percentage of accounts per class using the primary method from the matrix.
2. Phishing-resistant share: percentage of workforce sign-ins completed with a phishing-resistant authenticator.
3. MFA exclusions: count of accounts excluded from MFA policies, each with an owner and an expiry.
4. Static non-human credentials: count of service accounts still authenticating with a password or long-lived key.
5. Token lifetime: median and maximum lifetime of issued access tokens and sessions per tier.
6. Emulation pass rate: percentage of tested ATT&CK behaviours that failed and raised an alert.

Framework mapping

Common failure patterns

• Strong sign-in, weak session. Phishing-resistant MFA followed by long-lived bearer cookies or tokens moves the attack to session theft.
• Exclusions that never end. Service accounts, break-glass accounts and legacy protocols left outside MFA policy become the preferred entry path.
• Human methods forced onto machines. Giving a workload a user account with a password, or a personal access token, because it cannot complete MFA.
• Weak certificate mapping. Accepting any certificate from a trusted issuer, or mapping by name only, lets one identity authenticate as another.
• Treating the inferred mapping as coverage. Deploying one child and marking every listed ATT&CK technique as covered.

Practitioner checklist

• Build a matrix of account class against D3-AA child method for every identity store.
• Apply NIST SP 800-63B-4 password verifier rules wherever D3-PWA remains.
• Enforce phishing-resistant D3-MFA for administrators and remote access first.
• Give every exclusion an owner, a compensating control and an expiry.
• Move service accounts and agents to certificates or federated short-lived tokens.
• Set token and session lifetimes per risk tier and bind tokens to keys where supported.
• Use the inferred ATT&CK list as a test plan and record pass or fail per child.
• Report method coverage and static non-human credential counts quarterly.

Standards and references

• MITRE D3FEND: Agent Authentication
• MITRE D3FEND: Multi-factor Authentication
• MITRE D3FEND: Certificate-based Authentication
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• SPIFFE: Overview

Related NHI Mgmt Group resources: MITRE D3FEND Guide · MITRE D3FEND Access Policy Administration Implementation Guide · Phishing-Resistant MFA Guide · Passwordless and Passkeys Guide · Service Account Security Guide