A certificate is only as strong as the private key behind it, the CA that issued it and the rule that maps it to an account. D3-CBAN Certificate-based Authentication is the MITRE D3FEND countermeasure that D3FEND defines as "Requiring a digital certificate 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 reads a Certificate. This card explains what D3-CBAN hardens, which ATT&CK techniques D3FEND relates it to, where it is implemented for people, devices and workloads, how to prove it is working and where it fails. It is written for identity engineers, PKI owners and detection teams. For the protocol detail of mutual TLS between services, see the mTLS Guide; this page does not repeat it.
Key takeaways
- The mapping rule matters as much as the certificate. Weak certificate-to-account mappings (subject name, email or UPN only) let a certificate issued for one identity authenticate as another; Microsoft's strong mapping changes for Active Directory exist for exactly this reason.
- D3FEND's ATT&CK links are inferred. They come from shared artefacts (Certificate and User Account), so read them as "relevant" rather than "blocked".
- Certificate authentication moves the target to the PKI. An attacker who can enrol, steal or forge a certificate (T1649) gets a credential that often outlives a password reset.
- It is the natural strong factor for workloads. Services and agents cannot answer an MFA prompt, but they can hold a private key and present a short-lived certificate.
- Verify with negative tests and DC or IdP logs. Prove that revoked, expired, wrongly mapped and untrusted-issuer certificates are all refused, on every endpoint that accepts certificates.
D3-CBAN at a glance
| Field | D3-CBAN Certificate-based Authentication |
|---|---|
| D3FEND ID | D3-CBAN |
| Tactic | Harden |
| Parent technique | Agent Authentication (siblings: Biometric Authentication, Multi-factor Authentication, Password Authentication, Token-based Authentication) |
| Digital artefact | Certificate (D3FEND: the technique "reads" a Certificate); the parent strengthens User Account |
| What it changes | The authentication decision: the client proves possession of the private key matching a certificate that chains to a trusted issuer and maps to an account |
| D3FEND considerations | Protect private keys, run a working revocation process, and use mutual authentication against man-in-the-middle attacks |
| Typical implementation points | Smart card and PIV logon, cloud identity provider certificate sign-in, VPN and Wi-Fi (EAP-TLS), mutual TLS between services, OAuth client authentication |
| Typical data sources for verification | Domain controller KDC events, identity provider sign-in logs, TLS termination logs with client certificate details, CA issuance logs |
| D3FEND reference | Identity, Credential, and Access Management Subcommittee: Federal Public Key Infrastructure 101 |
How it works
D3FEND's knowledge base entry describes certificate-based authentication as using digital certificates to verify the identity of a user, device or server before granting access, relying on a public and private key pair. In practice the verifier performs four checks, and each one is a separate control that can be misconfigured:
- Proof of possession: the client signs a challenge (in the TLS handshake, a Kerberos PKINIT request or a signed assertion) with the private key. A copied certificate without its key is useless; a copied key is everything.
- Path validation: the certificate must chain to a trust anchor the verifier is configured to accept. The Federal PKI material D3FEND cites describes this model: PIV certificates chain through intermediate CAs to the Federal Common Policy CA G2 as the trust anchor, and PIV certificates on a smart card provide AAL3 authentication.
- Status checks: validity dates and revocation (CRL or OCSP). See the Certificate Revocation Guide.
- Account mapping: the verifier decides which account the certificate represents. This is where most real-world bypasses live.
Strong and weak mappings
Microsoft's KB5014754 for Active Directory defines a mapping as strong if it is based on identifiers that cannot be reused. The strong altSecurityIdentities mappings are X509IssuerSerialNumber (recommended), X509SKI and X509SHA1PublicKey; X509IssuerSubject, X509SubjectOnly and X509RFC822 are weak. Enterprise CAs also add a security extension (OID 1.3.6.1.4.1.311.25.2) carrying the account SID, which the KDC validates. Microsoft Entra ID uses the same idea under the name affinity: PrincipalName, RFC822Name, IssuerAndSubject and Subject bindings are low affinity, SKI, SHA1PublicKey and IssuerAndSerialNumber are high affinity, and Microsoft notes that a configuration is only as secure as its lowest-affinity binding.
| Mapping basis | Examples | Risk |
|---|---|---|
| Name-based (low affinity, weak) | UPN or email in the SAN, subject DN, issuer plus subject | Anyone who can get a certificate with that name, from any trusted issuer or a misconfigured template, can sign in as the account |
| Key or certificate-bound (high affinity, strong) | Issuer and serial number, subject key identifier, SHA-1 hash of the public key | Bound to one certificate or key; needs updating at each renewal unless automated |
| SID extension (Active Directory) | OID 1.3.6.1.4.1.311.25.2 added by Enterprise CAs | Lost if a template is configured to exclude it |
Microsoft states that domain controllers moved to Full Enforcement with the February 11, 2025 Windows update, and that the option to return to Compatibility mode ended with the September 9, 2025 update. These changes addressed CVE-2022-26923, CVE-2022-26931 and CVE-2022-34691, Kerberos KDC elevation of privilege issues in certificate authentication. See the AD CS Security Guide for template hardening.
Where identity and NHIs fit
Certificate authentication is one of the few strong methods that work for services, devices and AI agents as well as people. RFC 8705 (Proposed Standard, February 2020) defines two OAuth client authentication methods over mutual TLS, tls_client_auth (CA chain validation plus a registered subject) and self_signed_tls_client_auth (a registered certificate without chain validation), and certificate-bound access tokens that carry a cnf claim with an x5t#S256 thumbprint so a stolen token fails without the key. Workload identity systems issue short-lived X.509 identities automatically; see the SPIFFE and SPIRE Guide. The NHI risk is the reverse of the human one: long-lived machine certificates with exportable keys sitting in files, which is why the sibling technique D3-CERO Certificate Rotation matters.
ATT&CK techniques D3FEND relates to D3-CBAN
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CBAN; every row below is inferred through a shared digital artefact and D3FEND labels these mappings experimental (checked November 2026).
D3-CBAN reads Certificate, and its parent Agent Authentication strengthens User Account, so techniques that forge a Certificate or act on a User Account or its sub-artefacts are related. Each ID was checked against ATT&CK v20. The last column is NHI Mgmt Group's assessment, not part of D3FEND.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What certificate authentication changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1649 | Steal or Forge Authentication Certificates | Certificate (forged or accessed) | None on its own: this technique targets the control. Non-exportable keys, strong mapping and template hardening are what limit it |
| T1078.001, T1078.002, T1078.003, T1078.004 | Valid Accounts: Default, Domain, Local, Cloud Accounts | Sub-artefacts of User Account | Strong where certificates replace passwords; none where password sign-in stays available beside them |
| T1098.002, T1098.003 | Additional Email Delegate Permissions, Additional Cloud Roles | Sub-artefacts of User Account | Partial: protects the admin sign-in used to make the change |
| T1136.001, T1136.002, T1136.003 | Create Account: Local, Domain, Cloud Account | Sub-artefacts of User Account | Partial: a new account is only blocked if its sign-in path also requires a certificate |
| T1548.005 | Temporary Elevated Cloud Access | Sub-artefact: Cloud User Account | Partial: helps where elevation requires a fresh certificate sign-in |
| T1087.001, T1087.002, T1087.004 | Account Discovery: Local, Domain, Cloud Account | Sub-artefacts of User Account | Indirect: discovered accounts are harder to use without a key |
| T1531 | Account Access Removal | Same artefact: User Account | Indirect: protects the admin sign-ins used to lock others out |
Interception through a trusted root added by an attacker (T1553.004 Install Root Certificate) and T1557 Adversary-in-the-Middle are not in D3FEND's D3-CBAN mapping, but mutual authentication is the consideration D3FEND gives against them. See the MITRE ATT&CK T1649 Steal or Forge Authentication Certificates Guide and the MITRE ATT&CK T1557 Adversary-in-the-Middle.
Where it is implemented
| Enforcement point | What to configure | Typical gap |
|---|---|---|
| Windows domain logon (smart card, PKINIT) | Full Enforcement of strong mapping, hardened AD CS templates, smart card required for privileged accounts | Templates that let the requester supply the subject name, or that exclude the SID extension |
| Cloud identity provider | Certificate sign-in with high-affinity bindings, authentication binding by issuer or policy OID, trusted CA list with revocation | Roles with no policy requiring the certificate method; CRL endpoints that nobody monitors |
| Network access (VPN, 802.1X) | EAP-TLS with device and user certificates, server certificate validation on the client | Clients that do not validate the RADIUS server certificate. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide |
| Service to service | Mutual TLS with a private CA, identity taken from a URI SAN, short certificate lifetimes | Trusting any certificate from a shared corporate CA instead of a specific identity |
| OAuth clients and APIs | RFC 8705 tls_client_auth or self_signed_tls_client_auth, certificate-bound tokens | Client secrets kept as a fallback method |
| Mobile and derived credentials | Derived PIV credentials or device-bound certificates enrolled by MDM. See Derived PIV Credentials | Exportable software keys on unmanaged devices |
For Microsoft Entra ID specifically, Microsoft's documentation states that the trusted CA's CRL distribution point must be a single HTTP URL per CA (OCSP and LDAP are not used), that the password option stays visible alongside CBA (so Conditional Access authentication strength is the way to require certificates for a role), and that a certificate counts as single-factor by default unless the authentication binding policy marks its issuer or policy OID as multifactor (which then requires the key to be PIN or biometric protected). Treat these as customer-side settings to configure deliberately.
Implementation steps
- Inventory where certificates are accepted. List each verifier (DCs, IdP, VPN, RADIUS, API gateways, service meshes), the trust anchors it accepts and the mapping rule it uses.
- Narrow the trust anchors. Each verifier should trust only the issuing CAs that exist for its purpose, not every root in the operating system store. See the Enterprise PKI Design and CA Hierarchy Guide.
- Harden issuance before relying on it. Review templates or profiles for requester-supplied subjects, over-broad enrolment rights and authentication EKUs on templates that do not need them. Issuance is part of the authentication control.
- Move to strong or high-affinity mapping in audit first. On domain controllers, review KDC events 39, 40 and 41 (System log, source Kdcsvc) to find certificates that would fail strong mapping; in Entra ID, test high-affinity bindings on a pilot group using an issuer or policy OID rule.
- Protect the keys. Use smart cards, TPM-backed or HSM-backed keys, and non-exportable key settings for people and servers; issue short-lived certificates to workloads rather than long-lived files.
- Make revocation work. Publish CRLs or OCSP where every verifier can reach them, alert on stale CRLs, and rehearse revoking a user and a workload certificate end to end.
- Remove the fallbacks. Where certificates are the intended method, block password, shared secret or basic authentication on the same path, with a documented and monitored break-glass route as the rollback.
How to verify it works
- Negative certificate tests: present an expired certificate, a revoked certificate, a certificate from an untrusted issuer, and a valid certificate mapped to a different account. Each must be refused, on every verifier.
- Mapping test: in an authorised exercise, request a certificate with another user's UPN in the SAN from each template that allows requester-supplied names. Success means a T1649 path exists. See the Certipy and Certify AD CS Tooling Detection Guide for detection of the tooling used in such abuse.
- Fallback test: try the same sign-in with a password or client secret. If it succeeds, certificate authentication is an option, not a control.
- Log review: confirm sign-in records show the certificate used. In Entra ID the Additional Details tab shows labels such as User certificate subject name, User certificate binding and User certificate authentication level.
| Metric (example targets) | What it shows | Target direction |
|---|---|---|
| Share of privileged sign-ins completed with a certificate or other phishing-resistant method | Real coverage for the accounts that matter | Rising to 100% |
| Accounts or clients using weak or low-affinity mappings | Size of the impersonation surface | Falling toward zero |
| KDC events 39 and 41 per week | Certificates without a strong mapping, or with a SID mismatch | Zero; each 41 investigated |
| Certificate templates or profiles allowing requester-supplied subjects with an authentication EKU | Issuance paths to impersonation | Zero, or each one approved and monitored |
| Hours from revocation to refusal at each verifier | Whether revocation actually propagates | Within the CRL publication interval |
Limits, bypasses and failure patterns
- Stolen authentication certificate: in the Mimecast certificate compromise, attackers obtained a certificate that customers used to authenticate Mimecast services to Microsoft 365 Exchange, and Mimecast asked those customers to delete the connection and set up a new one with a replacement certificate. A single shared certificate trusted by thousands of tenants is a concentrated risk.
- Weak mapping: name-based mappings let a certificate issued for one identity sign in as another. Fix the mapping, not only the template.
- Revocation that nobody checks: a verifier that soft-fails when the CRL is unreachable accepts revoked certificates.
- Exportable keys in files: a PFX file with its password in a script is a password with extra steps. See the Private Keys in Repositories Guide.
- Password beside the certificate: where the platform keeps password sign-in available, attackers use that path; pair certificate sign-in with policies that require it for the roles that matter.
- Over-broad trust: a service that accepts any certificate from the corporate CA authenticates every device and user that CA ever issued to.
Framework mapping
| Framework | Reference | Relationship to D3-CBAN |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5(2) Public Key-based Authentication | Path validation, private key protection, mapping to the account |
| NIST SP 800-53 Rev 5 | IA-2, IA-3, IA-9 | Authentication of users, devices and services |
| NIST SP 800-53 Rev 5 | SC-17 Public Key Infrastructure Certificates | Issuing certificates under an approved policy |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03 | Credentials managed; users, services and hardware authenticated |
| NIST SP 800-63B-4 | AAL3 | Phishing-resistant cryptographic authentication with a non-exportable key |
| IETF | RFC 8705 | Mutual TLS client authentication and certificate-bound tokens for OAuth |
Related countermeasures
- Siblings under Agent Authentication: D3-MFA Multi-factor Authentication and D3-TBA Token-based Authentication.
- Certificate hardening: D3-CP Certificate Pinning on the client side and D3-CERO Certificate Rotation for key lifetime.
- Detection: D3-CA Certificate Analysis for spotting forged or misissued certificates.
- Eviction: D3-CR Credential Revocation when a certificate or key is compromised.
Practitioner checklist
- List every verifier that accepts certificates, with its trust anchors and mapping rule.
- Restrict each verifier to the issuing CAs intended for it.
- Run Active Directory in Full Enforcement and use high-affinity bindings in cloud identity providers.
- Remove requester-supplied subjects and unnecessary authentication EKUs from templates and profiles.
- Keep private keys on smart cards, TPMs or HSMs, or issue short-lived workload certificates.
- Prove revocation end to end and alert on stale CRLs.
- Block password and secret fallbacks on paths meant to require certificates.
- Track KDC events 39 to 41, low-affinity mappings and certificate sign-in coverage every month.
Standards and references
- MITRE D3FEND: Certificate-based Authentication (D3-CBAN)
- ICAMSC: Federal Public Key Infrastructure 101
- Microsoft: KB5014754 Certificate-based authentication changes on Windows domain controllers
- Microsoft Learn: Microsoft Entra certificate-based authentication technical deep dive
- IETF: RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
- MITRE ATT&CK: T1649 Steal or Forge Authentication Certificates
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
Related NHI Mgmt Group resources: mTLS Guide · Smart Card and PIV/CAC Authentication Guide · Machine Identity, PKI and Certificate Lifecycle Guide · MITRE D3FEND Guide