Strong authentication is undone when the credential behind it is a default password, a certificate that never changes or a token anyone can replay. MITRE D3FEND groups the controls that protect credentials themselves under Credential Hardening (D3-CH), a parent technique that enables the Harden tactic and holds eight techniques in three levels: certificate pinning, credential rotation (with certificate rotation, password rotation and one-time passwords beneath it), strong password policy (with change default password beneath it) and token binding. This guide treats D3-CH as a programme: what each branch protects, which credential types it suits, how to sequence the work, how to measure it and where it fails. It is written for identity, PKI and platform teams. Each technique has its own deep page linked below, so settings are not repeated here. For D3FEND itself see the MITRE D3FEND Guide.
Key takeaways
- Credential Hardening changes the credential, not the login. D3FEND defines it as techniques that "modify system or network properties in order to protect system or network/domain credentials". How an actor proves identity is a separate parent, Agent Authentication.
- Eight techniques sit in four branches. Pinning (D3-CP), rotation (D3-CRO with D3-CERO, D3-PR and D3-OTP), password policy (D3-SPP with D3-CDP) and token binding (D3-TB). The hierarchy comes from the D3FEND ontology.
- Each branch answers a different question. How long a credential lives, how hard it is to guess, whether it can be replayed elsewhere, and whether the client can be fooled about the server.
- Scheduled rotation is for machines, not people. NIST SP 800-63B-4 says verifiers shall not require periodic password changes; rotation pays off for service, device and certificate credentials.
- The ATT&CK links are inferred. D3FEND relates the family to brute force, credential dumping, token theft and account techniques through shared artefacts and labels them inferred and experimental.
What D3FEND means by Credential Hardening
In the D3FEND ontology D3-CH hardens the Credential artefact and enables Harden. The D3FEND site lists the relations its descendants add: strengthening Password, User Account and Access Token, limiting the use of a Password, hardening Certificate and OT Controller, regenerating Credential and Certificate, and authenticating a Public Key. Those artefacts are the scope of the programme: passwords, certificates and their keys, access tokens and controller credentials.
Keep three neighbouring parents apart. Agent Authentication (D3-AA) chooses the method an actor uses to prove identity; see the companion MITRE D3FEND Agent Authentication Implementation Guide. Credential Eviction removes credentials already compromised. Credential Hardening sits between them: it makes the credentials in use harder to guess, shorter-lived and less useful if copied. For the human password rules in full, see the Password Policy Guide (NIST-aligned).
The eight techniques
The table lists every descendant of D3-CH in the ontology, indented by level, with D3FEND's purpose in short form and the credential types it fits. The last column is NHI Mgmt Group's view.
| D3FEND technique | Parent | What it does | Best fit |
|---|---|---|---|
| D3-CP Certificate Pinning | D3-CH | Client stores a server's certificate or public key and compares it to what the server presents | Native apps, embedded clients, service-to-service code |
| D3-CRO Credential Rotation | D3-CH | Regularly changes or replaces passwords, API keys or certificates | Service accounts, API keys, shared and break-glass accounts |
| D3-CERO Certificate Rotation | D3-CRO | Replaces certificates and their private keys | TLS, mutual TLS and workload certificates |
| D3-PR Password Rotation | D3-CRO | Changes account passwords to limit the life of a compromised one | Local admin, service and device passwords; people only on evidence of compromise |
| D3-OTP One-time Password | D3-PR | A password valid for only one authentication | A second factor where stronger methods are not possible |
| D3-SPP Strong Password Policy | D3-CH | Configures systems to increase password strength | Every system that still accepts passwords |
| D3-CDP Change Default Password | D3-SPP | Replaces factory credentials with a strong, unique password before deployment | Network devices, appliances, IoT and OT controllers |
| D3-TB Token Binding | D3-CH | Binds tokens such as cookies or OAuth tokens to a specific connection | OAuth access tokens, session cookies, API clients |
The hierarchy matters for reporting. D3-OTP sits under Password Rotation because each code is a password that expires after one use, and D3-PR sits under Credential Rotation, not under Credential Eviction. Take the hierarchy from the ontology when you map controls.
Choosing the right branch for each credential
Most credentials need more than one branch. The matrix shows which branches apply to each credential type; it is our recommendation, built from the child pages and the standards they cite.
| Credential type | Strength (D3-SPP, D3-CDP) | Lifetime (D3-CRO family) | Replay resistance (D3-TB) | Server trust (D3-CP) |
|---|---|---|---|---|
| Human passwords | Length, blocklist screening, no composition rules | Change on evidence of compromise only | Not applicable to the password; applies to the session | Not applicable |
| Local admin and service passwords | Long random values | Scheduled and event-driven, automated | Not applicable | Not applicable |
| Device and OT credentials | Unique per device, set before go-live | Event-driven, with maintenance windows | Not applicable | Where the client supports it |
| Certificates and keys | Key length and algorithm policy | Automated renewal with a new key | Used as the binding key | Pin the key or a backup set |
| OAuth tokens and session cookies | Not applicable | Short lifetimes, refresh rotation | Mutual TLS or DPoP sender constraint | Not applicable |
| API keys | High-entropy, issuer-generated | Scheduled and on exposure, with overlap | Prefer replacing with bound tokens | Not applicable |
Decision rules
- Rotate or remove? If a credential can be replaced by a short-lived, automatically issued one (a federated token or a short-lived certificate), do that instead of building a rotation schedule. Rotation is the fallback for credentials that must stay static.
- Pin or rely on PKI? D3FEND notes that browser pinning was deprecated in favour of Certificate Transparency. Pin only in clients you control and can update, always with a backup pin. See the Certificate Pinning guide.
- Token Binding or its successors? RFC 8471 Token Binding did not ship in mainstream browsers. For OAuth, use mutual TLS certificate-bound tokens (RFC 8705) or DPoP (RFC 9449, a Proposed Standard since September 2023). See the DPoP Guide.
- Small versus large organisations. Small teams get most value from D3-CDP on every device, D3-SPP through the identity provider, and platform-managed service identities that rotate themselves. Large estates add automated certificate lifecycle management, privileged password vaulting and sender-constrained tokens for high-value APIs.
Implementation roadmap
The order below is NHI Mgmt Group's recommendation; D3FEND does not prescribe one.
- Inventory credentials by artefact. List passwords, certificates, tokens, API keys and device credentials per system, with owner, age and where each is stored. Ages and owners are the baseline for every later metric.
- Remove defaults (D3-CDP). Gate onboarding of every device and appliance on a changed credential, and confirm with an authenticated scan that tries known defaults. See the Default Credential Breaches Lessons Guide.
- Set the password policy (D3-SPP). Apply NIST SP 800-63B-4: at least 15 characters for single-factor use, blocklist screening of every new password, no composition rules and no periodic forced change for people.
- Automate rotation for machine credentials (D3-CRO, D3-PR, D3-CERO). Start with local administrator passwords and privileged service accounts, then certificates. Use overlapping old and new credentials, and confirm the old value is invalidated. See the Secrets Management Guide.
- Bind high-value tokens (D3-TB successors). Pilot sender-constrained tokens on one API with clients you control, then extend.
- Pin where you own the client (D3-CP). Mobile and embedded clients that talk only to your servers, with a documented key change plan.
Testing and rollback: run rotation first against a test copy of each dependent service, then in rings; keep the previous credential valid for a defined overlap so rollback is a configuration change, not an outage. For pinning, ship a backup pin and a remote way to update pins before enforcing. For password policy, enable screening in audit mode first where the platform allows, to see how many existing passwords would fail.
Inferred ATT&CK relations for the family
D3FEND links D3-CH to ATT&CK through the artefacts its descendants act on and labels the links "inferred, experimental". The site groups them as follows (ATT&CK v20 IDs; techniques that appear under several tactics are shown once).
| Tactic | Techniques D3FEND lists | Branch with the most direct effect (our view) |
|---|---|---|
| Credential Access | T1110.001 Password Guessing, T1110.002 Password Cracking, T1110.003 Password Spraying | D3-SPP, D3-PR, D3-OTP |
| Initial Access, Persistence, Privilege Escalation, Stealth | T1078.001 Default Accounts, T1078.002 Domain Accounts, T1078.003 Local Accounts, T1078.004 Cloud Accounts | D3-CDP for T1078.001; D3-CRO for the rest |
| Credential Access | T1003.003 NTDS, T1003.005 Cached Domain Credentials, T1003.008 /etc/passwd and /etc/shadow, T1555.001 Keychain, T1552 Unsecured Credentials | D3-CRO limits how long dumped material works |
| Credential Access | T1649 Steal or Forge Authentication Certificates, T1558.001 Golden Ticket | D3-CERO; D3-CP on the client side |
| Credential Access, Lateral Movement | T1528 Steal Application Access Token, T1539 Steal Web Session Cookie, T1606.001 Web Cookies, T1550.001 Application Access Token, T1550.004 Web Session Cookie | D3-TB and short token lifetimes |
| Privilege Escalation, Stealth | T1134.001, T1134.002, T1134.003 Access Token Manipulation; T1548.005 Temporary Elevated Cloud Access | Context only: related through the Access Token artefact |
| Persistence, Discovery, Impact | T1098.001, T1098.002, T1098.003 Account Manipulation; T1136.001, T1136.002, T1136.003 Create Account; T1087.001, T1087.002, T1087.004 Account Discovery; T1531 Account Access Removal | Context only: related through the User Account artefact |
Rows marked context only are listed by D3FEND but hardening the credential does little to stop them; detection and access policy matter more there. For the strongest links see the MITRE ATT&CK T1110 Brute Force Guide and the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide.
Where identity fits
Non-human credentials are where Credential Hardening does most of its work. People should not have scheduled password changes, but service accounts, API keys, device passwords and workload certificates should be rotated automatically or, better, replaced by short-lived credentials issued on demand. The credentials most often missed are the ones nobody owns: keys in pipelines, passwords in scripts, certificates on appliances. See the Non-Human Identity (NHI) Guide and the Service Account Security Guide.
Detection and measurement
Useful signals are a credential used after it was rotated (the old value still accepted, or still being tried), authentication with a known default credential, certificate validation failures on pinned clients, and a sender-constrained token presented without its proof. Each points either to an attack or to a hardening step that did not complete.
Metrics we suggest at NHI Mgmt Group (example targets, not standards):
- Default credential findings: devices where an authenticated scan succeeded with a known default, target zero.
- Credential age: oldest active service account password, API key and certificate key, per tier.
- Rotation completeness: percentage of rotations where the superseded value saw zero successful use afterwards.
- Blocklist coverage: percentage of password-accepting systems that screen new passwords.
- Bound token share: percentage of high-value API calls using sender-constrained tokens.
- Time to rotate on exposure: median time from a leak signal to a completed rotation.
Framework mapping
| Framework | Reference | Link to D3-CH |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-5 Authenticator Management | Password strength, defaults, rotation and protection of authenticators |
| NIST SP 800-53 Rev. 5 | SC-17 Public Key Infrastructure Certificates, SC-23 Session Authenticity, SC-8 Transmission Confidentiality and Integrity | Certificate rotation, token binding and pinning |
| NIST CSF 2.0 | PR.AA-01 | Identities and credentials managed by the organisation |
| NIST SP 800-63B-4 | Password verifier requirements | D3-SPP and when D3-PR applies to people |
| MITRE D3FEND | D3-AA Agent Authentication | The methods that consume hardened credentials |
Common failure patterns
- Rotation that adds instead of replaces. A new key is issued but the old one stays valid, so the attacker's copy still works.
- Forced periodic changes for people. Users respond with predictable patterns; NIST guidance now prohibits it.
- Policy changed, passwords unchanged. New length rules usually apply only at the next change, so the existing population stays weak.
- Pinning without a backup. A key change or CA migration locks every client out until an app update ships.
- Defaults beyond the web admin. SNMP communities, serial consoles and vendor support accounts keep factory values after the main password is changed.
Practitioner checklist
- Inventory every credential by artefact type, owner, age and storage location.
- Block onboarding of any device until every default credential is changed and scanned.
- Apply NIST SP 800-63B-4 password rules, including blocklist screening.
- Automate rotation for local admin, service, device and certificate credentials.
- Verify each rotation by confirming zero use of the superseded value.
- Replace static API keys with short-lived or sender-constrained tokens where platforms allow.
- Pin only clients you control, always with a backup pin and an update path.
- Report credential age and default credential findings quarterly.
Standards and references
- MITRE D3FEND: Credential Hardening
- MITRE D3FEND: Credential Rotation
- MITRE D3FEND: Token Binding
- 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)
- IETF: RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Password Policy Guide (NIST-aligned) · Secrets Management Guide · Certificate Pinning · MITRE D3FEND Access Mediation Implementation Guide