D3FEND Harden Tactic: Every Hardening Countermeasure and Where to Start

Most successful intrusions exploit something that could have been closed before the system went live: a default password, a writable configuration, an unsigned boot path or a memory bug the compiler could have trapped. MITRE D3FEND groups those preventive countermeasures under its Harden tactic, which it defines as being "used to increase the opportunity cost of computer network exploitation", adding that hardening "generally is conducted before a system is online and operational". This hub lists every Harden technique in the D3FEND ontology, shows how the six families fit together, summarises which ATT&CK techniques D3FEND relates them to, and suggests an order of work. It is written for security architects, endpoint engineers and AppSec leads. For the framework itself, see the MITRE D3FEND Guide.

Key takeaways

• Harden is the largest preventive tactic. The D3FEND site (version 1.6.0, checked November 2026) shows 55 Harden entries: six families and 49 techniques beneath them.
• The families follow the stack. Source Code and Application Hardening act on software, Platform Hardening on firmware, boot, storage and hardware, Credential Hardening and Agent Authentication on identities, and Message Hardening on communications.
• ATT&CK links are inferred, not asserted. D3FEND relates Harden techniques to ATT&CK through shared digital artefacts such as Credential, Process Segment or Boot Loader. Treat them as candidates to test.
• Start where the cost to the attacker rises fastest. Credential hygiene, software update and secure configuration close the most common initial access and credential access paths at the lowest cost; compiler and boot integrity work follows.
• Hardening decays. Every Harden technique needs a verification check and a drift metric.

What Harden means in D3FEND

D3FEND organises defensive techniques under seven tactics: Model, Harden, Detect, Isolate, Deceive, Evict and Restore. Harden is the only one that is mostly applied before an adversary is present. Its techniques change a property of a system so that a class of attack becomes harder, noisier or impossible: configuration baselines, patching, encryption, secure boot, compiler mitigations, credential policy and message signing.

Each technique is described by what it does to a digital artefact: Bootloader Authentication "authenticates" a Boot Loader, Strong Password Policy "strengthens" a Password. D3FEND uses these relations to infer which ATT&CK techniques a countermeasure is relevant to: an ATT&CK technique that acts on the same artefact, or a more specific one of the same kind, is related. NHI Mgmt Group computed the relations below from the ontology file; D3FEND hand-maps few Harden techniques to ATT&CK.

Every technique in the Harden tactic

The table is built from the D3FEND ontology file (d3fend-protege.ttl, checked November 2026). Family rows link to the implementation guide for that family; technique rows link to the technique page. The purpose column paraphrases D3FEND's definition; each technique page gives the artefact relations in full. One entry, Particle Radiation Hardening, appears in the ontology without a D3FEND ID and is not shown on the D3FEND site; it is listed for completeness.

How the six families fit together

The families are easiest to read as layers. A weakness at a lower layer undermines the ones above: measured boot is pointless if anyone can change system configuration, and a strong password policy does little if the password is hard-coded in a repository.

Which ATT&CK techniques Harden counters

Run across all 55 entries, the shared-artefact method relates Harden to well over a hundred Enterprise techniques, many through broad artefacts such as File or Software. The table below keeps the relations where the Harden technique genuinely changes the outcome; the strength column is NHI Mgmt Group's assessment, not part of D3FEND.

The ontology still points to some ATT&CK IDs that v20 has revoked. Application Configuration is related to a revoked Windows event logging sub-technique, now T1685.001 Disable or Modify Windows Event Log; credential artefacts are related to the old Keychain ID, now T1555.001; and Change Default Password is related to the old ICS default credentials ID, now T1694.001 Default Credentials. Several ICS message techniques that D3FEND relates to Message Hardening are also revoked in v20, which is why only current IDs appear above.

Where to start: a prioritised order

D3FEND gives no priority order. The sequence below is NHI Mgmt Group's view, ordered by how much attacker cost each step adds per unit of effort for a typical enterprise estate.

1. Inventory and baseline. You cannot harden what you have not listed. Use configuration benchmarks (see the CIS Benchmarks Guide) as the starting baseline for Application Configuration Hardening and System Configuration Permissions, applied first in audit mode on a pilot ring.
2. Credentials first. Change Default Password on every device and appliance before it reaches production, apply Strong Password Policy, enforce Multi-factor Authentication for administrators and remote access, and run Credential Scrubbing on repositories. These close the cheapest attacker paths.
3. Software Update. Patching is the Harden technique with the broadest inferred reach. Tie it to exposure: internet-facing first. See the Patch Management Guide.
4. Disable Remote Access that is not needed, then verify from outside.
5. Platform integrity. Enforce Bootloader Authentication, TPM Boot Integrity, Driver Load Integrity Checking and Disk Encryption on endpoints and servers, rolled out by hardware model, with recovery keys escrowed before enforcement.
6. Compiler and runtime mitigations. Make Process Segment Execution Prevention, Segment Address Offset Randomization, Stack Frame Canary Validation and Control Flow Integrity build defaults, and fail builds that lose them.
7. Rotation and binding. Short-lived credentials and certificates, then Token Binding where supported.
8. Source Code Hardening as a development standard. Pointer, integer and type validation rules belong in coding standards and static analysis; the strongest version is moving new code to memory-safe languages (see the Memory-Safe Languages Guide).
9. Message Hardening and physical controls by exposure. Message Authentication and Encryption for mail, APIs and industrial buses; enclosure and RF controls only for physically exposed or regulated environments.

Plan rollback before enforcement: a tested configuration revert, boot recovery media and escrowed keys, and a coordinated cut-over for services that depend on changed passwords or tokens.

Small and large organisations: a small organisation gets most of the value from steps 1 to 4 using vendor defaults and managed services. A large organisation needs owners per family, a baseline per platform and an exception process for legacy devices.

Where identity fits

Two of the six families are identity controls, and they apply to non-human identities as much as to people. Credential Rotation, Certificate Rotation, Credential Scrubbing and Token Binding are the Harden techniques that act directly on API keys, service account passwords, workload certificates and OAuth tokens. These machine credentials typically rotate least often and are the ones found hard-coded in repositories. Change Default Password also applies to device and appliance accounts. For the identity side of this work, see the Non-Human Identity (NHI) Guide and Credential Rotation at Scale.

Verifying hardening and measuring progress

A hardening control that is not checked is an assumption. Verify each family from live state, not build documentation: benchmark scans for configuration (with drift alerts handed to the D3FEND Detect Tactic), secure boot, TPM and encryption status from device management, binary flag checks in the build pipeline, secret scanning and credential age reports, and mail authentication reports for messages.

Example metrics (illustrative targets, not standards):

• Baseline conformance: share of assets passing the configuration benchmark, by platform.
• Patch latency: median days from release to deployment for internet-facing systems.
• Integrity coverage: share of endpoints with secure boot enforced and disk encryption on.
• Credential age: share of machine credentials older than the rotation policy allows.
• Default credentials found: count per quarter, with a target of zero in production.

Limits and common failure patterns

• Treating inferred mappings as coverage: a D3FEND relation shows relevance, not effectiveness; test before reporting coverage.
• Audit mode forever: secure boot, driver integrity and application control are often deployed in audit mode and never enforced, giving reports without protection.
• Admin bypass: System Configuration Permissions and most platform controls do not stop an attacker who already holds administrator or SYSTEM rights. Hardening must be paired with privileged access controls.
• Rotation without discovery: rotating known credentials while unknown copies sit in code, CI variables and scripts leaves the leaked ones valid elsewhere.
• Forgotten device classes: appliances, OT controllers and printers keep default passwords and old firmware long after servers are hardened. Message Hardening is the family most relevant here: D3FEND relates it mainly to ATT&CK for ICS techniques that produce protocol messages, such as T0836 Modify Parameter, T0843 Program Download and T0858 Change Operating Mode.
• Rotating the wrong passwords: NIST SP 800-63B does not require periodic changes of user passwords, only change on evidence of compromise, so aim Password Rotation mainly at shared and machine credentials.

Framework mapping

The mapping is NHI Mgmt Group's; D3FEND itself cites SP 800-53 Rev 5 as a reference for Agent Authentication. For configuration baselines in CIS terms, see the CIS Control 4 Secure Configuration of Enterprise Assets and Software Guide.

Practitioner checklist

• Map each Harden family to a named owner and a baseline document.
• Apply configuration baselines in audit mode on a pilot ring, then enforce with a tested revert.
• Scan for and remove default passwords on every device class, including OT and appliances.
• Scrub credentials from repositories and CI, then rotate anything that was exposed.
• Enforce secure boot, measured boot and disk encryption, with recovery keys escrowed first.
• Make compiler mitigations build defaults and fail builds that drop them.
• Validate inferred ATT&CK counters with testing before claiming coverage.
• Feed drift and failed-verification signals into detection; plan for failure with the D3FEND Isolate Tactic and D3FEND Evict Tactic.

Standards and references

• MITRE D3FEND: Harden Tactic
• MITRE D3FEND: D3FEND Ontology
• NIST: SP 800-53 Rev 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-193 Platform Firmware Resiliency Guidelines
• NIST: SP 800-70 Rev 5, National Checklist Program for IT Products
• CIS: Critical Security Controls v8.1
• CISA: Secure by Design

Related NHI Mgmt Group resources: MITRE D3FEND Guide · MITRE D3FEND Platform Hardening Implementation Guide · MITRE D3FEND Credential Hardening Implementation Guide · CIS Benchmarks Guide · ATT&CK Credential Access Tactic Guide