LM hash storage should be disabled because LM hashes are weak and can be cracked far more easily than modern password hashes. If Windows is configured to store them again, attackers with local access gain a legacy credential target. Check the relevant local or domain password policy setting and watch for changes to systems that would re-enable LM hash storage.
What LM hashes are and why Windows should not keep storing them
LM hash storage is a legacy compatibility setting, not a modern security feature. If it is enabled, Windows may keep generating and retaining a weak password representation that is easier to recover than contemporary password hashes. That creates unnecessary exposure on endpoints and domain-joined systems, especially where attackers can read local security material after a foothold.
The practical issue is not just that the hash is old, but that it is still a usable target. Once stored, it can be collected from the local system or from other places where legacy credential material is exposed, and it may shorten the path from local access to broader account abuse. Credential dumping guide is useful background because it shows how attackers commonly hunt for password material after they land on a Windows host.
Disabling LM hash storage removes an obsolete credential target and reduces the chance that a weak fallback format survives in environments that otherwise rely on stronger password handling. For defenders, that matters most on systems where privileged users log on, where old compatibility settings linger, or where local access is not tightly controlled.
How to verify whether LM hash storage has been re-enabled
Check the effective local or domain password policy rather than assuming the setting stayed fixed. On Windows estates, the most important question is whether the system is configured to store LM hashes for next-time logon compatibility, because that is the state that reintroduces the weak credential artifact.
Look for configuration drift in the policy source of truth, then confirm it on representative endpoints. If a baseline or GPO change reintroduces the setting, treat that as a security regression even if no one intended to weaken authentication. In mixed environments, also watch for legacy images, old hardening scripts, or exception paths that silently override the intended policy.
Operationally, the best signal is a change event tied to the policy path that controls LM hash retention, paired with a comparison against your approved baseline. If the setting appears unexpectedly on one host, assume the same change may have propagated more widely until you prove otherwise. NIST Cybersecurity Framework 2.0 fits here as a governance lens for identifying configuration drift, monitoring it, and responding when a control state changes.
What to do if you find LM hash storage enabled
First, disable the setting at the policy level so the re-enablement cannot recur after reboot or policy refresh. Then compare the affected systems against your hardening standard to determine whether the issue is isolated, inherited from a template, or present across multiple OUs or device groups.
Next, assume the stored legacy material may already have been exposed on the impacted systems. That does not mean compromise is certain, but it does mean you should review privileged logons, suspicious local access, and any evidence of credential harvesting around the time the setting was active. If the host is high-value, include nearby accounts and cached credential material in your review. MITRE ATT&CK Enterprise Matrix is a useful reference for mapping the credential-access phase and the follow-on abuse that often follows a successful foothold.
If the affected endpoint or policy scope included administrators or service-like accounts, rotate the credentials that may have been at risk and confirm that the old hash format is no longer present. For teams with broader Windows credential exposure concerns, Cisco Active Directory credentials leak 2025 is a reminder that hash material can remain operationally valuable to attackers even when it is not a modern password in plain sight.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02 — Software, Hardware, Data, and Services Inventories | Tracks systems where LM-hash policy drift can appear. |
| PR.AA-05 — Managed Access Control | Covers enforcing access settings that prevent weak legacy credential storage. | |
| Recommendation — Inventory the Windows hosts and policy scopes that must enforce the LM-hash prohibition. Enforce the password policy that disables LM hash storage across the estate. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | LM-hash storage is a configuration state that should remain in the approved baseline. |
| CM-6 — Configuration Settings | Directly applies to controlling the local or domain setting that enables LM hashes. | |
| IA-5 — Authenticator Management | Weak hash storage affects credential lifecycle and exposure of authentication material. | |
| Recommendation — Baseline the no-LM-hash setting and reject deviations from it. Set and monitor the configuration that prevents LM hash generation and retention. Rotate and manage impacted credentials when LM-hash exposure is suspected. | ||
| MITRE ATT&CK | T1003 — OS Credential Dumping | Stored hashes are a common target once an attacker has local access. |
| Recommendation — Hunt for hash-dumping activity on hosts where LM storage was enabled. | ||
| CIS Controls v8 | CIS-5 — Account Management | Legacy hash storage undermines account protection and credential hygiene. |
| Recommendation — Remove legacy credential storage and validate account protections across Windows systems. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | LM-hash storage is a configuration item that should be controlled and reviewed. |
| Recommendation — Control and review the Windows settings that govern password hash storage. | ||
Practitioner Guidance
What to verify: Do not stop at the configured value on one server. Verify the effective setting through the same policy path that actually governs production endpoints, then sample enough hosts to rule out stale templates or OU-specific exceptions.
Decision rule: If the setting is enabled anywhere a user or privileged account can authenticate, treat it as a material exposure and fix the policy first, then assess whether any credential material may already have been collected.
Common mistake: Teams often assume that a modern password policy alone neutralises legacy storage. It does not, because the risk is the presence of the old hash format itself, not just the strength of the current password.
Practitioner takeaway: The priority is to prevent the legacy hash from being stored at all, because once the setting returns, the defender has reintroduced a recoverable credential target that attackers can exploit after local access.
Related resources from NHI Mgmt Group
- How do you know if LSA Protection is actually enabled on a Windows machine?
- How can security teams detect disabled Windows event logging?
- How do you patch or mitigate CVE-2025-21391 (Microsoft Windows Storage Link Following)?
- How do you patch or mitigate CVE-2024-43451 (Microsoft Windows NTLMv2 Hash Disclosure Spoofing)?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org