Active Directory password risks in 2026

Introduction

#

For many years, securing passwords in Active Directory meant configuring a domain policy with minimum length, complexity, history, expiry and account lockout. These controls still serve a purpose, but they primarily address an older problem: preventing obviously weak choices and limiting repeated guesses against one account. Modern attackers often take a different route. Rather than cracking a password through brute force, they use a credential they already possess or test a small number of likely passwords across a large user population.

Four risks dominate this model. In password spraying, an attacker tries one common password against hundreds or thousands of accounts to remain below lockout thresholds. Credential stuffing uses username and password pairs taken from other services. Password reuse turns an external breach into an internal security incident. Finally, password breaches feed credential databases, combo lists and criminal services that automate attacks against organisations before Active Directory has any indication that the password is exposed.

A password can be 18 characters long, contain upper- and lower-case letters, numbers and symbols, and still be compromised. If it was reused on an external service, captured by malware or included in a breach, it remains policy-compliant but is no longer safe. This distinction between syntactic compliance and real-world exposure risk is the central weakness of traditional password policies.

The answer is not to abandon passwords or remove native controls. It is to treat them as a baseline and add breached-password protection, multifactor authentication, identity monitoring and risk-based response.

How traditional password policies work

#

In Active Directory Domain Services, the domain password policy is usually enforced through Group Policy. Fine-Grained Password Policies allow different values to be assigned to defined user sets, such as privileged accounts, service accounts and standard users. In both cases, the objective is to validate password properties and control behaviour after failed authentication attempts.

Complexity

#

The native complexity rule requires characters from different categories and prevents certain combinations containing the account name or tokens from the display name. A password such as CompanySummer2026! can satisfy both length and composition requirements. Users, however, tend to construct predictable patterns: the organisation name, a season, the current year and a symbol at the end. The password passes the policy but remains vulnerable to dictionaries tailored to the company and its context.

Password expiry

#

Maximum password age forces a change after a defined period, historically every 30, 60 or 90 days. The assumption was that rotation would reduce the useful lifetime of a stolen password. In practice, frequent changes encourage sequences such as Project2026!01, Project2026!02 and Project2026!03. An attacker who knows an earlier value can often predict the next one, while the organisation generates more service desk requests and increases the likelihood of passwords being written down or stored insecurely.

Minimum password age can prevent a user from cycling through several values to return immediately to a previous password. It complements password history, but it provides no information about whether the current credential has been compromised.

History

#

Password history retains hashes of previous passwords to prevent immediate reuse within the same domain. For example, a history of 24 values stops a user from changing SecureNetwork!24 to a temporary password and then immediately returning to the original. It cannot detect that the same password is being used for personal email, an online retailer or a SaaS provider. It also does not identify semantically similar variations.

Minimum length

#

A longer minimum increases the search space and makes passphrases practical. A unique phrase built from four or five unrelated words will generally resist offline cracking more effectively than a short word overloaded with predictable substitutions. The chosen value must remain compatible with legacy applications, VPNs, appliances and synchronisation mechanisms because older technical limits may silently truncate passwords.

In 2026, 14 or 15 characters provide a more defensible baseline for user passwords, while privileged accounts and managed secrets should use longer, randomly generated values. Length alone, however, does not prevent exposure or reuse.

Lockout policies

#

Account lockout combines a failed-attempt threshold, a lockout duration and the interval after which the counter resets. Setting the threshold too low enables denial of service because an attacker can deliberately lock out users. Setting it too high permits more guesses. Values such as 10 attempts with 15-minute windows can provide a starting point, but they must be adjusted for organisational risk, available telemetry and the authentication protocols in use.

Password spraying is specifically designed to bypass this control. One attempt per account, followed by a sufficiently long delay, can keep every user below the threshold. Lockout still limits concentrated brute-force attacks, but it should not be mistaken for distributed attack detection.

Why these policies fail today

#

Native policies primarily assess a password when it is set or changed. They do not know where else it has been used, whether it appeared in a breach yesterday or whether an infostealer extracted it from a browser. The attacker operates outside the domain boundary and later presents a valid credential to the authentication service.

flowchart LR
    A[Breach at an external service] --> B[Combo list or criminal market]
    C[Infostealer on an endpoint] --> B
    B --> D[Automated attacks]
    D --> E[Password spraying]
    D --> F[Credential stuffing]
    E --> G[Active Directory]
    F --> G
    G --> H{Valid credential?}
    H -->|Yes| I[Initial access]
    H -->|No| J[Try another account or password]

Password reuse creates an invisible relationship between the domain and services the organisation does not control. Even if the company never suffers a breach, an external portal can expose the same password. Active Directory history only compares previous values for that user inside the domain; it does not measure global uniqueness.

Leaked credentials are aggregated into credential databases and combo lists. Attackers filter them by email domain, region, technology or organisation and run tests at scale. A complex password already known to the attacker offers no cryptographic resistance during authentication: the attacker simply submits the correct value.

Infostealer malware has made collection even more direct. It can capture passwords stored in browsers, session cookies, tokens, wallet data and system information. This reduces reliance on historical breaches and provides criminals with current credentials. MFA remains essential, but stolen sessions, password-only authentication methods and fraudulent approval prompts also require endpoint protection, Conditional Access and anomaly detection. The English version of the article on Claude reaching real systems during cybersecurity evaluations also illustrates how exposed credentials and weak operational boundaries can quickly turn a configuration failure into unauthorised access.

Finally, automated attacks reduce the cost of testing credentials. Distributed proxies, botnets and cloud infrastructure allow attackers to vary source, timing and protocol. Authentication events against VPNs, Remote Desktop gateways, AD FS, legacy applications, Microsoft 365 and published services may look unrelated unless they are correlated. Password policy has none of the context required to connect these signals.

What changed in Microsoft’s recommendations

#

Modern Microsoft guidance separates configuration baselines from identity risk protection. Microsoft Security Baselines provide tested settings for Windows and Windows Server and should be used as a starting point rather than copied without validation. A baseline should enforce a setting when it mitigates a contemporary threat without introducing operational impact that outweighs the risk.

The most visible shift is away from mandatory periodic expiry. For cloud-only accounts, Microsoft recommends non-expiring passwords and favours changes when compromise is suspected or confirmed. The reasoning is both operational and behavioural: calendar-driven rotation does not prove that a credential remained secret and often produces minimal, predictable changes. This does not remove the need for resets after incidents, role changes, confirmed exposure or failures in secret-management processes.

Microsoft Entra Password Protection, previously known as Azure AD Password Protection, blocks known weak passwords and their variants. Microsoft’s global banned-password list can be supplemented with a custom list containing organisation-specific terms such as brands, locations, products or internal names. In hybrid environments, the same approach can protect password changes and resets performed against on-premises AD DS.

The on-premises architecture has two important components:

• the Password Protection Proxy runs on a domain-joined member server and retrieves banned-password policies from Microsoft Entra ID, so domain controllers do not need direct internet access;
• the Password Filter DC Agent runs on domain controllers, receives validation requests from the operating system and applies the cached policy locally before returning an accept or reject decision.

For consistent enforcement, the DC Agent must be installed on every domain controller. A partial deployment is suitable for testing, not production, because a client may send a password change to any DC. Microsoft also states that clear-text passwords do not leave the domain controller and that the solution requires no AD DS schema extension.

This direction aligns with NIST SP 800-63B, whose current revision provides clear guidance for memorised secrets: passwords used as a single authentication factor must be at least 15 characters, verifiers should support a maximum length of at least 64 characters, proposed values must be checked against a blocklist of common, expected or compromised passwords, additional composition rules should not be imposed, and periodic changes should not be required without evidence of compromise. NIST does not make passwords irrelevant; it moves the priority from artificial patterns to length, known-bad password screening and multifactor authentication.

Enzoic and continuous monitoring for compromised credentials

#

Enzoic for Active Directory is intended to address a gap that native AD controls and Microsoft Entra Password Protection do not fully cover: continuous monitoring of credential exposure. Its technical model combines validation when a password is created or changed with subsequent checks against compromised-credential intelligence.

According to the vendor’s documentation and technical materials, the platform compares passwords with a continuously updated database derived from breaches, criminal-market sources and malware logs. It can block compromised values, common words, derivatives of the username and variants produced through predictable substitutions. Continuous Password Protection reassesses credentials already in use when new intelligence becomes available, allowing the organisation to identify a password that was acceptable when created but later appeared in a breach.

Within the Active Directory integration, validation occurs during password changes and resets and can provide feedback to the user. If later compromise is detected, available responses can include notification, forcing a password change at next sign-in, disabling the account or initiating an integrated remediation workflow. The exact action should be risk-based: automatically disabling every affected account may interrupt critical operations, while alert-only behaviour may leave credentials exposed for too long.

The potential benefits are measurable: fewer reused or previously exposed passwords, targeted remediation instead of estate-wide resets, and additional telemetry for audit and SOC operations. Adoption still requires a formal technical assessment. The organisation should evaluate the query architecture, hash handling, external dependencies, availability, latency, data protection, data residency, licensing, fail-open or fail-closed behaviour, and SIEM integration.

Enzoic does not replace MFA, endpoint protection, PAM, administrative segmentation or identity threat detection. It must also be assessed as a commercial vendor making its own claims about data coverage and update frequency. Its value lies in the additional exposure-intelligence layer, provided the implementation is technically validated and integrated into a defence-in-depth strategy.

Active Directory best practices for 2026

#

These practices should be supported by retiring legacy protocols, reviewing inactive accounts, protecting service accounts with gMSA where possible, auditing privileged groups and centralising event collection. Passwords are only one control within the identity security plane.

Example of a modern architecture

#

flowchart TD
    U[User] --> AD[Active Directory]
    AD --> PP[Password Protection]
    PP --> EZ[Enzoic
compromised credential monitoring]
    EZ --> MDI[Microsoft Defender for Identity]
    MDI --> SOC[SOC]

    ENTRA[Microsoft Entra ID
global and custom lists] -. policy .-> PP
    MFA[MFA and Conditional Access] -. additional control .-> AD
    SOC -. response and remediation .-> AD

The diagram represents logical layers, not a mandatory authentication flow. Microsoft Entra Password Protection validates password choices against banned-password policies; a platform such as Enzoic adds continuous exposure intelligence; Defender for Identity generates detections from Active Directory activity; and the SOC correlates events and coordinates response. Production integrations should avoid unnecessary synchronous dependencies that could prevent password changes during an external service outage.

Conclusion

#

Traditional Active Directory password policies continue to provide a necessary baseline. Length, history, minimum age and lockout limit specific classes of abuse and support operational requirements. The mistake is expecting these mechanisms to detect external reuse, combo lists, infostealers or credentials that become public after they have already been accepted.

A modern strategy combines long and unique passwords, passphrases, blocklists, Microsoft Entra Password Protection, phishing-resistant MFA, endpoint protection, PAM, administrative tiering and continuous detection. Compromised-credential monitoring can provide additional visibility, but it should be evaluated as a security-critical component rather than treated as a replacement for the remaining controls.

Strong passwords still matter, but the critical requirement today is preventing the use of compromised credentials. That requires visibility into credential exposure, correlation across authentication events and rapid response when risk changes — not a blanket password change every time another 90 days have elapsed.

References

#

• Petri — Why Active Directory Password Policy Fails Modern Attacks (and What Admins Need Instead)
• Enzoic — Native Active Directory Password Policies Still Fail Modern Attacks
• Microsoft Learn — Enforce on-premises Microsoft Entra Password Protection for Active Directory Domain Services
• Microsoft Learn — Password policy recommendations for Microsoft 365
• Microsoft Learn — Security Baselines
• NIST — Special Publication 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management
• Wikimedia Commons — Microsoft Entra ID color icon, public domain