Most password policies still enforce the rules that make passwords worse (forced complexity and expiry) and skip the one that stops real attacks: screening against known compromised passwords. D3-SPP Strong Password Policy is the MITRE D3FEND countermeasure for the password itself. D3FEND defines it as "Modifying system configuration to increase password strength." It sits in the Harden tactic as a child of Credential Hardening and strengthens the Password artefact. This card covers what D3FEND means by a strong policy, which ATT&CK techniques it relates to, the settings that carry it on common platforms, how to verify it, and where it stops helping. It is written for identity and platform engineers who set password policy; for the full policy design, see the Password Policy Guide (NIST-aligned).
Key takeaways
- D3FEND's version of "strong" is the modern one. Its knowledge base names length, permitting ASCII and Unicode, and screening new passwords against commonly used or compromised lists, and warns that extreme complexity rules push users to obvious or written-down passwords.
- It hardens one artefact against a narrow set of attacks. D3FEND's direct relationships are with Password Guessing, Password Cracking and Password Spraying; it does little against phishing, infostealers or reuse of a password that is strong but stolen.
- Screening matters more than composition. NIST SP 800-63B-4 requires a blocklist check on every new password and prohibits extra composition rules and periodic forced change.
- A new policy rarely changes existing passwords. Several platforms apply length and character rules only at the next change, so measure the password population, not the setting.
- Verify by attacking your own hashes, with authorisation. An offline audit against a breached-password corpus is the only direct measure of policy strength.
D3-SPP at a glance
| Field | D3-SPP Strong Password Policy |
|---|---|
| D3FEND ID | D3-SPP |
| Tactic | Harden |
| Parent technique | Credential Hardening (siblings: Certificate Pinning, Credential Rotation, Token Binding) |
| Child technique | D3-CDP Change Default Password |
| Digital artefact | Password (D3FEND: the technique "strengthens" a Password) |
| D3FEND references | NIST Digital Identity Guidelines (SP 800-63-3); Weir, Aggarwal, Collins and Stern, "Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords" |
| Related ATT&CK mitigations (D3FEND links) | M1027 Password Policies, M1026 Privileged Account Management |
| Main limitation | Raises the cost of guessing and cracking; does nothing once a password is phished, logged or reused from another breach and still meets the policy |
D3FEND's references still point to SP 800-63-3. The current revision is SP 800-63B-4, which keeps the same direction and tightens the length rule; the settings below follow the current text. See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
What a strong password policy means now
| Setting | NIST SP 800-63B-4 position | Why it matters |
|---|---|---|
| Minimum length | At least 15 characters when the password is the only factor; at least 8 when it is used within multi-factor authentication | Length is the main driver of guessing and cracking cost |
| Maximum length | Should permit at least 64 characters | Allows passphrases and password manager output |
| Character set | Should accept printing ASCII, space and Unicode (NFC-normalised before hashing) | Removes friction that pushes users to short passwords |
| Blocklist screening | Shall check new and changed passwords against commonly used, expected or compromised values, and tell the user why a password was rejected | Directly removes the passwords sprayed and cracked first |
| Composition rules | Shall not impose other composition rules | Mixed-class rules produce predictable patterns such as a capital first and a digit and symbol last |
| Periodic change | Shall not require periodic change; shall force change on evidence of compromise | Scheduled expiry produces incremented variants of the old password |
| Hints and security questions | Shall not store hints readable before authentication or prompt for knowledge-based questions | Removes guessable side channels |
| Password managers | Shall allow password managers and autofill; should permit paste | Makes long unique passwords practical |
| Failed attempts | Shall rate-limit, with no more than 100 consecutive failures before the authenticator is disabled | Bounds online guessing; see D3-AL Account Locking |
| Storage | Shall salt (at least 32 bits) and hash with a suitable password hashing scheme; cost factor as high as practical | Sets the cost of offline cracking after a hash dump |
The last row is where D3-SPP meets T1110.002 Password Cracking: policy controls how guessable the password is, and storage controls how fast each guess can be tested. Both have to be right. Breached-password screening is covered in depth in Breached password checks.
ATT&CK techniques D3FEND relates to D3-SPP
Relationship type: inferred only. D3FEND derives these relationships through shared digital artefacts and labels them inferred and experimental (checked November 2026). The direct relationship is through Password: the three Brute Force sub-techniques access the artefact D3-SPP strengthens. The other rows come through the User Account artefact. Every ID was checked against ATT&CK v20. The last column is NHI Mgmt Group's assessment, not D3FEND content.
| ATT&CK ID | Technique | D3FEND relation | What a strong policy changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1110.001 | Password Guessing | Accesses Password | Strong: blocklisted and short passwords are the ones guessed first |
| T1110.003 | Password Spraying | Accesses Password | Strong: spraying relies on a few common passwords across many accounts; screening removes them |
| T1110.002 | Password Cracking | Accesses Password | Strong with good storage: long, unlisted passwords resist dictionary and rule-based cracking |
| T1078.001 to T1078.004 | Valid Accounts: Default, Domain, Local, Cloud Accounts | Via User Account | Partial: helps only where the valid account was obtained by guessing or cracking; default accounts are covered by the child technique D3-CDP |
| T1098.002, T1098.003 | Additional Email Delegate Permissions, Additional Cloud Roles | Via User Account | Indirect: fewer accounts are taken over to make these changes |
| T1136.001 to T1136.003 | Create Account: Local, Domain, Cloud Account | Via User Account | Indirect: the policy applies to attacker-created accounts too, which is not a meaningful barrier |
| T1548.005 | Temporary Elevated Cloud Access | Via User Account | Indirect |
| T1087.001, T1087.002, T1087.004 | Account Discovery: Local, Domain, Cloud Account | Via User Account | Minimal: discovery is unaffected; only the use of discovered accounts gets harder |
| T1531 | Account Access Removal | Via User Account | Minimal |
One technique works against the policy itself: T1201 Password Policy Discovery, where an adversary reads the policy to tune guessing and stay under lockout thresholds. See the MITRE ATT&CK T1201 Password Policy Discovery, the MITRE ATT&CK T1110 Brute Force Guide and M1027 Password Policies.
Where it is implemented
Platforms are listed alphabetically. Each row shows the setting names from the vendor's own documentation (checked November 2026) and how existing passwords are treated where the docs say so.
| Platform | Where the policy is set | Settings that carry D3-SPP |
|---|---|---|
| AWS IAM users | Account password policy (aws iam get-account-password-policy to read it) | Minimum length 6 to 128; optional character requirements; reuse prevention of 1 to 24 previous passwords. Length and character rules apply at the next password change. The policy covers IAM user console passwords; protect the root user with MFA and keep it out of daily use |
| Linux (PAM) | pam_pwquality, configured in /etc/security/pwquality.conf | minlen (default 8); dictcheck (cracklib dictionary, on by default); usercheck; badwords for organisation terms; enforce_for_root (off by default, so root changes only warn). Set the dcredit, ucredit, lcredit and ocredit credits to 0 so minlen counts raw length |
| Microsoft Active Directory | Default domain password policy; Fine-Grained Password Policies (Password Settings objects in the Password Settings Container, domain functional level Windows Server 2012 or higher) | Fine-grained policies apply to users and global security groups with a precedence value, which allows a longer minimum for privileged and service accounts |
| Microsoft Entra ID | Microsoft Entra Password Protection, with an agent for on-premises AD DS domain controllers | Global banned password list (always on) plus a custom banned list of up to 1,000 base terms; normalisation, fuzzy matching and a scoring rule that needs at least 5 points. Availability: custom list needs Entra ID P1 or P2; synced users need P1 or P2 for both lists |
| Okta | Password authenticator policy, per group and authentication provider | Minimum length 4 to 30 (Okta recommends at least 12); common password check against one million commonly used passwords; restricted words via expression language; history of 1 to 30. For AD-sourced users, AD enforces length and complexity |
Where a directory and an identity provider both validate a password, the user has to satisfy both, so align them or the stricter one decides. Service accounts and other non-human identities often sit outside interactive password policy entirely; long random secrets from a vault, or no password at all, are the better hardening for them. See the How to find AD accounts with password never expires.
Implementation steps
- Read the current policy everywhere it lives. Directory default and fine-grained policies, identity provider, cloud accounts, Linux PAM, databases and appliances with local users.
- Turn on screening first. Add a blocklist of common and breached passwords plus organisation terms (company, product and place names). This gives the largest gain for the least user impact.
- Raise the minimum length. Use 15 for password-only access and at least 8 where a second factor is always required, following SP 800-63B-4. Use fine-grained policies or groups to apply longer minimums to privileged accounts first.
- Remove what works against you. Drop composition rules and scheduled expiry where your regulators and auditors accept the NIST position; keep forced change on evidence of compromise.
- Pilot with a ring. Apply to IT staff first, watch help desk volumes and rejection messages, then widen. Rollback is reverting the policy object; passwords already set are unaffected.
- Bring existing passwords up to standard. New rules usually apply at the next change. Use a breached-password audit to find accounts that need a targeted reset rather than resetting everyone.
- Fix storage. Confirm that applications you build use a salted password hashing scheme with a high cost factor.
How to verify it works
- Rejection tests: try to set a known common password, a password containing the company name, and a 14-character password on a password-only system. Each should be rejected with a reason.
- Resultant policy check: for a sample of users, admins and service accounts, read the policy that actually applies (in AD, the resultant password settings object) rather than the default.
- Authorised offline audit: with written approval and strict handling of the hash extract, test directory hashes against a breached-password corpus. This measures the population, which is what attackers face. See the Hashcat and Password Cracking for Defenders Guide.
- Spray telemetry: watch failed sign-ins spread across many accounts from few sources; successful sign-ins in that pattern mean a sprayed password survived.
| Metric | What it shows | Example target (illustrative, not a standard) |
|---|---|---|
| Accounts whose password appears in a breached-password corpus | Real exposure to spraying and stuffing | Falling to zero for privileged accounts |
| Share of accounts whose password was set after the current policy | How much of the population the policy actually covers | Rising steadily |
| Passwords recovered in an authorised cracking audit within a fixed time budget | Resistance to offline cracking | Falling each audit |
| Accounts with password never expires and no owner (non-human) | Stale secrets outside policy | Each one owned or replaced |
| Successful sign-ins following spray patterns | Whether screening removes the sprayed values | Zero |
Limits, bypasses and failure patterns
- Weak minimums on customer-facing logins: the 23andMe breach page records an eight-character minimum with little else, and passwords reused from other breaches. Breached-password screening, rate limiting and MFA were the missing layers; length alone would not have stopped reused passwords.
- Policy set, population unchanged: rules that apply only at the next change leave old weak passwords in place for years when expiry is turned off. Pair the change with an audit and targeted resets.
- Complexity theatre: mixed-class rules and 90-day expiry produce patterns that cracking rules model well, the outcome D3FEND's own considerations warn about.
- Root and break-glass outside policy: local root, cloud root users and emergency accounts often bypass the managed policy. Set them by hand to long random values held in a vault.
- Strong but stolen: phishing, infostealers and keyloggers capture the password whatever its strength. D3-SPP needs D3-MFA Multi-factor Authentication beside it; see the Password Spraying and Credential Stuffing Defence Guide.
Framework mapping
| Framework | Reference | Relationship to D3-SPP |
|---|---|---|
| MITRE ATT&CK | M1027 Password Policies; M1026 Privileged Account Management | The mitigations D3FEND links to D3-SPP |
| NIST SP 800-53 Rev 5 | IA-5(1) Password-based Authentication | Blocklist screening, salted hashing and change on compromise |
| NIST SP 800-63B-4 | Section 3.1.1 Passwords | The current verifier requirements summarised above |
| NIST CSF 2.0 | PR.AA-01 | Identities and credentials are managed by the organisation |
| ISO/IEC 27001:2022 | Annex A 5.17 Authentication information | Allocation and management of authentication information |
Related countermeasures
- Child technique: D3-CDP Change Default Password applies the same idea to factory credentials on devices and OT controllers.
- Siblings under Credential Hardening: D3-CRO Credential Rotation (with its child D3-PR Password Rotation), D3-TB Token Binding and Certificate Pinning.
- Detection side: D3-DUC Decoy User Credential catches spraying and credential testing that a strong policy makes slower but not impossible.
Practitioner checklist
- Inventory every place a password policy is set, including Linux PAM, cloud accounts and appliances.
- Enable breached and common password screening with organisation-specific terms.
- Set a 15-character minimum for password-only access and at least 8 where MFA is always required.
- Allow at least 64 characters, spaces, Unicode, paste and password managers.
- Remove composition rules and scheduled expiry where your compliance obligations allow; force change on compromise.
- Apply stricter fine-grained policies to privileged accounts and set root and break-glass passwords by hand to long random values.
- Run an authorised breached-password audit after the change and reset the accounts it finds.
- Confirm application password storage uses salted hashing with a high cost factor.
Standards and references
- MITRE D3FEND: Strong Password Policy (D3-SPP)
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- MITRE ATT&CK: M1027 Password Policies
- AWS: Set an account password policy for IAM users
- libpwquality: pam_pwquality manual page
- Microsoft: Configure fine-grained password policies for AD DS
- Microsoft: Eliminate bad passwords using Microsoft Entra Password Protection
- Okta: Configure the password authenticator
Related NHI Mgmt Group resources: Password Policy Guide (NIST-aligned) · Breached password checks · Account Lockout and Brute-Force Protection Guide · MITRE D3FEND Guide