Notifications
Clear all
Topic starter
24/06/2026 7:15 pm
TL;DR: Most organisations already have password policies, but policy alone does not stop weak, reused, or compromised credentials from being used at endpoints, according to Netwrix. The real control gap is enforcement at the point of creation and throughout the credential lifecycle, not the existence of a written rule.
NHIMG editorial — based on content published by Netwrix: You still have passwords. Now enforce them
Questions worth separating out
Q: How should security teams enforce password policy in Active Directory environments?
A: Security teams should enforce password policy at the point of creation, not rely on directory settings alone.
Q: Why do strong password policies still fail in practice?
A: Strong policies fail when they only validate format and length.
Q: What signals show that password enforcement is actually working?
A: Working enforcement shows up as high rejection rates for weak or reused passwords, fewer user workarounds, and fewer accepted passwords that later match exposed patterns.
Practitioner guidance
- Enforce password quality at creation time Block weak, reused, and breach-exposed passwords at the point of change or enrolment so users cannot bypass policy with obvious variants.
- Add breach-list and dictionary validation Check candidate passwords against known compromise sources and local dictionaries before acceptance, not after an incident or audit finding.
- Close the endpoint-policy gap Push controls beyond directory settings so endpoint behaviour cannot preserve weak credentials that look compliant in policy reports.
What's in the full article
Netwrix's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific enforcement examples for blocking weak and compromised passwords in Active Directory.
- Detailed product behaviour for real-time password guidance during creation and reset flows.
- Granular policy options for compliance scenarios that go beyond native directory settings.
👉 Read Netwrix's analysis of password policy enforcement in Active Directory →
Password policy enforcement in AD: are your controls actually working?
Explore further
25/06/2026 4:27 am
Password policy without enforcement is administrative theatre. A rule set that exists only in directory policy does not meaningfully reduce risk if endpoints, reuse patterns, and breach-listed credentials are not blocked at the point of use. The field should treat enforcement as the control, not the policy document. Practitioners should measure whether passwords are actually rejected when they are weak, not whether a policy exists on paper.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which shows how often identity controls remain incomplete in practice.
A question worth separating out:
Q: Who is accountable when password policy exists but weak passwords still get through?
A: Accountability sits with the identity and endpoint owners who define the control and the teams that allow exceptions to persist. NIST Cybersecurity Framework 2.0 reinforces that access control must be operational, not merely documented, so governance teams should assign ownership for enforcement and exception handling.
👉 Read our full editorial: Password policy enforcement is the real control gap in AD
