M1027 Password Policies: Password Policies That Actually Mitigate ATT&CK Techniques

Password policy is the most widely deployed control in ATT&CK and one of the most misapplied: the settings that slow guessing and cracking are not the ones most organisations still enforce. MITRE ATT&CK M1027 Password Policies has 47 technique relationships in Enterprise v20, from brute force and Kerberoasting to credential dumping, pass the ticket and unsecured credentials in files. This guide treats M1027 as a control a team implements: which techniques it really affects, how to reconcile ATT&CK's text with the current NIST SP 800-63B-4 rules, how to set policy differently for people, local administrators and service accounts, and how to measure it. It is for identity, Active Directory and detection engineering teams. Policy wording and user communication are in the Password Policy Guide (NIST-aligned); this page stays on the ATT&CK view.

Key takeaways

• Length, uniqueness and blocklists do the work. NIST SP 800-63B-4 requires at least 15 characters for single-factor passwords, a blocklist check on every change, and no composition rules; those settings, not complexity, are what slow T1110 guessing and cracking.
• ATT&CK and NIST disagree on expiry for people. The M1027 text still mentions regular password changes, while NIST says verifiers shall not require periodic changes and shall force a change on evidence of compromise. For human accounts, follow NIST.
• Machine passwords are a different policy. For service accounts, ATT&CK asks for 25 or more characters, periodic expiry and managed service accounts or vaulting, because Kerberoasting cracks them offline where no lockout applies.
• Uniqueness across hosts is half the mapping. T1003 OS Credential Dumping, all eight of its sub-techniques and several lateral movement techniques carry the same usage text: complex, unique local administrator and root passwords on every system.
• Two techniques rely on M1027 alone. In ATT&CK v20, T1201 Password Policy Discovery and T1555.001 Keychain have no other mitigation.

What the control is

ATT&CK describes M1027 as setting and enforcing secure password policies to reduce the likelihood of unauthorised access. Its implementation list covers Windows Group Policy (minimum length, complexity, history, lockout), Linux PAM modules (pam_pwquality for length and complexity, pam_faillock for lockout), enterprise password managers, breached and banned password checks, Windows LAPS for unique local administrator passwords, and regular auditing of policy and account configuration. The ATT&CK text names example products; this guide stays vendor-neutral. On current Linux distributions use pam_faillock, as pam_tally2 has been removed from recent Linux-PAM releases, and pam_pwhistory for reuse checks.

M1027 sits beside three related mitigations: M1032 Multi-factor Authentication, which makes a guessed password insufficient; M1036 Account Use Policies, which covers lockout and logon restrictions; and M1026 Privileged Account Management, which limits what a cracked password unlocks. ATT&CK lists M1027 and M1032 together for most brute force sub-techniques.

Techniques ATT&CK says M1027 mitigates

Counts are computed from the ATT&CK Enterprise v20 STIX data: 47 active relationships, with Credential Access accounting for 29. Persistence, Lateral Movement and Defense Impairment have 7 each, Stealth, Privilege Escalation and Initial Access 5 each, and Execution and Discovery 1 each (a technique with several tactics counts once per tactic). The table groups the relationships by what the usage text actually asks for.

Priorities: start with T1110.003 Password Spraying and T1110.004 Credential Stuffing, because they are how most password-based initial access happens and M1027 has direct settings for both. Then T1558.003 Kerberoasting, where service account password length is the only thing standing between a captured ticket and a cracked domain account. Then local administrator uniqueness, which turns one dumped hash into one host instead of every host. For technique depth, see the MITRE ATT&CK T1110 Brute Force Guide, MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide, MITRE ATT&CK T1552 Unsecured Credentials Guide and T1555 Credentials from Password Stores Defensive Guide.

Reconciling ATT&CK with NIST SP 800-63B-4

The M1027 description still lists complexity and regular changes. ATT&CK's brute force usage text points to NIST guidance, and NIST published SP 800-63B-4 as final on 31 July 2025. Where they differ, the NIST rules are the current baseline for human accounts.

On-premises Active Directory needs a password filter to apply a banned list at change time. Microsoft Entra Password Protection, for example, installs a DC agent with a password filter DLL on every domain controller and evaluates passwords during change and reset against Microsoft's global banned list and a per-tenant custom list. Microsoft states that partial deployment is not secure and that if no policy is available on a domain controller the password is accepted, so coverage of every domain controller is part of the control. Other vendors offer equivalent filters. Because these are LSA plug-ins, test them alongside LSA protection; see M1025 Privileged Process Integrity.

Policies by account type

Where identity fits

The ATT&CK text for Kerberos techniques is effectively a non-human identity policy: long, random, rotated service account passwords, managed by the platform or a vault. Human password guidance (no expiry, memorable passphrases) must not be applied to service accounts, and service account exemptions from lockout and MFA must not be left without a compensating control. See the Group Managed Service Accounts (gMSA) Guide, the Kerberoasting and AS-REP Roasting Defence Guide and Rotating a Windows or Linux Service Account Password.

Rolling out the policy

1. Measure first. Audit current hashes against breached and banned lists offline in a controlled process, count service accounts with SPNs and their password age, and count local administrator passwords shared across hosts.
2. Deploy the banned list in audit or pilot mode. Run the password filter on a test domain first, then on all domain controllers; confirm every domain controller reports policy.
3. Raise minimum length for new passwords. Apply at next change rather than forcing a mass reset; use fine-grained password policies to set stricter rules for administrators and service accounts first.
4. Remove scheduled expiry for users only when the banned list, breached password checks and MFA are live; expiry removal without them weakens the control.
5. Fix service accounts. Convert to group managed service accounts where possible, rotate the rest to long random values, and disable RC4 for Kerberos where applications allow.
6. Disable reversible encryption in the domain policy and on any account that has it set.
7. Rollback: length and banned list rules apply only at change, so rolling back is a policy change with no effect on existing passwords; keep a tested exception process for applications that cannot handle long passwords.

What M1027 does not stop

• Phishing and session theft: a strong password typed into a fake page is still stolen; M1032 with phishing-resistant methods is the answer.
• Pass the hash and ticket reuse: once a hash or ticket is stolen, password strength no longer matters for reuse; M1026, M1025 and M1043 reduce exposure.
• Online attacks against exempt accounts: lockout does not apply to accounts excluded from it, and spraying stays under per-account thresholds. The Microsoft Midnight Blizzard breach began with a slow password spray against a legacy test tenant account that had no MFA.
• Reuse outside your control: customers and staff reuse passwords from other breached services. In the 23andMe breach, credential stuffing reached more than 18,000 accounts directly where MFA was optional; breached password checks and mandatory MFA are the controls that address it.

Verifying it works

• Policy state: report effective domain and fine-grained policies, the number of domain controllers running the password filter, and accounts with reversible encryption or password-not-required flags.
• Attack signals: many accounts failing once from one source (spraying), Kerberos service ticket requests for many SPNs from one account, and success after failure sequences. See the Password Spraying and Credential Stuffing Defence Guide.
• Testing: an authorised, periodic offline audit of password hashes against breached lists, run by a small team under change control, shows how many passwords remain guessable.

Metrics: percentage of active accounts whose password matches a breached or banned list; service accounts with SPNs and passwords older than your rotation interval; percentage of service accounts converted to managed accounts; hosts sharing a local administrator password; domain controllers without the password filter; accounts exempt from lockout or MFA without a documented compensating control.

Related D3FEND countermeasures and framework mapping

MITRE D3FEND relates M1027 to D3-SPP Strong Password Policy and D3-OTP One-time Password.

Common failure patterns

• Complexity and 90-day expiry instead of length and blocklists. Users produce predictable variations that spraying lists already contain.
• Service accounts on the user policy. Eight-character service account passwords that never change are the main Kerberoasting yield.
• Banned list on some domain controllers only. A password change handled by an uncovered domain controller bypasses the check.
• Exemptions without compensation. Test, legacy and service accounts excluded from MFA and lockout, as in Midnight Blizzard.
• Shared local administrator passwords from imaging. One dumped hash opens every host built from the same image.
• Passwords in scripts and registry. Policy covers what users type but not what automation stores (T1552.001, T1552.002).

Practitioner checklist

• Set 15 characters minimum for single-factor passwords and allow at least 64.
• Deploy a banned and breached password check on every domain controller and identity provider.
• Remove scheduled expiry for people once blocklists and MFA are live; force reset on compromise.
• Apply a separate policy to service accounts: managed accounts, or 25+ random characters in a vault with rotation.
• Give every host a unique, managed local administrator and root password.
• Disable reversible encryption and remove password-not-required flags.
• Change default credentials before any device or application reaches production.
• Ban passwords in files, scripts and registry; scan for them.
• Track the M1027 rows in your ATT&CK coverage tracker, starting with T1110.003, T1110.004 and T1558.003.

Standards and references

• MITRE ATT&CK: M1027 Password Policies
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST CSRC: SP 800-63B-4 publication record
• Microsoft Learn: Enforce Microsoft Entra Password Protection for Windows Server Active Directory
• Microsoft Learn: Group Managed Service Accounts overview
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE D3FEND: Strong Password Policy

Related NHI Mgmt Group resources: Password Policy Guide (NIST-aligned) · Password Spraying and Credential Stuffing Defence Guide · Kerberoasting and AS-REP Roasting Defence Guide · M1032 Multi-factor Authentication · Local Administrator Password Solution (LAPS) Guide