Microsoft's long-standing advice that Windows users should change their passwords every few months has finally been consigned to history — and not a moment too soon. In a revision to the Windows security baselines tied to the Windows 10 v1903 / Windows Server v1903 updates, Microsoft removed the recommendation that organizations enforce periodic password expiration as a security baseline. The company described periodic expiration as an “ancient and obsolete mitigation of very low value,” recommending instead modern mitigations such as banned-password lists, multi‑factor authentication (MFA), and anomaly detection. This shift aligns Microsoft with major identity guidance bodies and reflects a broader industry move away from rote password rotations toward stronger authentication design and detection-first defenses.
Background
For decades, corporate IT policies have relied on periodic password expiration as a basic control: set a maximum password age, force users to change credentials every N days, and assume an attacker’s window of opportunity is limited. In Windows Group Policy parlance this was implemented through the Maximum Password Age (often set to 42 days by default in Windows) and historically reinforced in Microsoft’s published security baselines (where baseline guidance once cited values like 90 days and later 60 days).
That model has been under pressure from research and standards bodies for years. Empirical studies and human factors research showed that forced rotation frequently produced predictable user behavior — simple incremental changes, reuse patterns, or written notes — that actually lowered real-world security. Starting with modern identity guidance (notably the NIST digital identity guidance), the recommended approach shifted: don’t require periodic password changes unless there is evidence of compromise; instead, favor length, uniqueness, banned-password screening, password managers, and MFA.
Microsoft’s change formalized this practical reality inside one of the most influential configuration documents many enterprises use: the Windows security baselines. By removing password expiration from the baseline, Microsoft signaled that periodic rotation should no longer be treated as an audit-friendly checkbox but as a context-dependent control that organizations should only use when truly needed.
Why Microsoft changed course
The human factor: predictable, weaker replacements
Password expiration assumes users will invent strong new secrets on a schedule. Real behavior shows otherwise. When forced, people choose the smallest, most memorable incremental variations: append a new digit, change “Password1” to “Password2,” or rotate among a set of similarly weak passphrases. Those small, algorithmic changes are trivially predictable and offer little resistance to an attacker who already knows previous values or can mount online guessing attacks that exploit user patterns.
The technical factor: offline cracking and cloud-scale attacks
Modern password‑cracking capabilities (GPU acceleration, cloud-based brute force, and massive leaked-password dictionaries) make short or common passwords highly vulnerable. A policy that increases the probability users will pick short or familiar passwords in the name of memorability unintentionally increases attack surface. In short: forcing frequent changes often trades one risk for another.
The operational factor: detection matters more than schedule
If a credential is compromised, waiting weeks for scheduled rotation is a poor incident response strategy. Best practice is immediate detection and remediation: suspend or force a reset on evidence of compromise. Removing scheduled rotation from a baseline emphasizes detection, response, and stronger primary controls rather than calendar-driven hygiene.
Alignment with modern standards
Major identity standards and guidance have already recommended this shift. Contemporary digital identity guidance explicitly advises against arbitrary periodic change of memorized secrets in favor of change triggered by suspected or confirmed compromise, plus proactive mitigations (banned-password lists, MFA, password hashing protections, and user support for password managers). Microsoft’s baseline update mirrors this shift and brings baseline guidance into alignment with modern recommendations.
What the change actually means for administrators
It’s a baseline change, not a product removal
- Password expiration settings remain in Windows. Administrators can still apply a Maximum Password Age in Group Policy or Active Directory; Microsoft simply removed it from the recommended security baseline.
- Defaults on Windows still behave in familiar ways unless changed. For example, Windows historically reports a default maximum password age value of 42 days for many deployments. That default continues to exist; the baseline removal means Microsoft no longer endorses a scheduled rotation as the baseline expectation for auditors or administrators.
- Organizations retain full discretion. If regulatory or contractual requirements require periodic rotation, or if an organization’s threat model makes timed rotation desirable, admins can — and should — implement whatever schedule they need.
The baseline intent: avoid misleading audit signals
Security baselines are often used as audit checklists. Microsoft argued that including a password-expiration requirement in their baseline could cause organizations to be penalized in compliance reviews for choosing stronger, alternative mitigations (for example, long non-expiring passphrases plus MFA). By removing expiration from the baseline, auditors lose one rigid metric that could produce false negatives on modern defenses.
What to do instead: recommended mitigations and practical steps
Removing rote password expiration from a baseline doesn’t mean lowering standards. It replaces a weak control with a set of stronger, more actionable practices. Administrators and security architects should treat expiration removal as an opportunity to pivot to modern identity hygiene.
Priority controls (implement these first)
- Require multi‑factor authentication (MFA) for all privileged and user logins. MFA dramatically reduces the value of a stolen password. Implement app-based OTP, hardware tokens, or platform authenticators (FIDO2/passkeys) rather than SMS where possible.
- Deploy banned-password lists / password protection. Block known-bad, commonly used, and previously breached passwords at password creation time. This prevents users from picking easy, high‑risk secrets in the first place.
- Allow and encourage password managers and passphrases. Remove UI or policy barriers to pasting passwords and permit longer passphrases that are easier for managers and users to handle.
- Enable robust monitoring and anomaly detection. Deploy systems that detect brute-force attempts, impossible travel, credential stuffing, and anomalous logon patterns. Triage and force a reset on suspicious activity immediately.
- Adopt passwordless authentication where practical. Windows Hello for Business, FIDO2, and other passwordless options reduce reliance on memorized secrets altogether.
- Harden password storage and authentication protocol configurations. Ensure IT infrastructure uses strong hash algorithms, salted storage, and modern Kerberos protections; patch and harden domain controllers and authentication servers.
Operational and policy measures
- Review compliance requirements before changing rotation policies. Some regulatory frameworks still require explicit rotation or defined controls — document the risk-based rationale if you deviate.
- Create an incident-driven reset workflow. Password changes should be triggered by detection and forensics, not calendars. Automate forced resets on confirmed compromise.
- Communicate changes to users. If an organization moves away from routine rotation, explain why and provide clear guidance on password managers, MFA enrollment, and signs of compromise.
- Educate users on passphrase creation and manager usage. Provide training and tools to reduce risky behavior like writing passwords down.
- Test and measure. Use telemetry to measure success: fewer helpdesk password resets, increased MFA adoption rates, and anomalous activity trends before/after policy changes.
Implementation guidance: how to change password-expiration policy safely
If an organization decides to remove or relax password expiration, do it in a controlled, auditable way.
- Inventory where password expiration is enforced — local accounts, domain Group Policy Objects (GPOs), cloud directories (Entra ID/Azure AD), and third‑party identity providers.
- Pilot in a low‑risk group (non‑privileged users) and monitor authentications and helpdesk impacts.
- Configure compensating controls first: enforce banned lists, enable MFA, improve detection.
- If rolling to “never expire,” set Minimum Password Age to at least 1 day to prevent rapid cycling around history. Ensure password history is configured to prevent reuse.
- Update documentation and compliance artifacts: rationale for change, controls implemented, monitoring strategy, and evidence of reduced failure modes.
- For privileged accounts (service accounts, local admin), consider stronger controls: rotating credentials with secrets management tooling, certificates, or managed identities rather than static passwords.
Benefits for security and users
- Better security posture. Stronger primary defenses (MFA, banned-password screening, passkeys) are more effective than calendar-driven rotation.
- Improved user experience. Less frequent forced resets reduce helpdesk tickets and user frustration, encouraging adoption of better practices like password managers.
- Reduced predictable patterns. Eliminating forced rotations removes the incentive for users to create tiny, predictable variations.
- Clearer incident response. Switching to detection-triggered resets focuses effort where it matters — when compromise is suspected or confirmed.
Risks and cautionary notes
- Regulatory and contractual exceptions. Some industries and contracts still require explicit rotation policies. Before changing any control, check applicable regulations and audit expectations. Where regulation demands rotation, comply and document why.
- Transition missteps. If an organization removes expiration without implementing compensating controls, risk increases. Never eliminate rotation in isolation; pair the change with MFA, banned-password lists, and monitoring.
- Legacy systems and service accounts. Many legacy applications, automated scripts, and service accounts still rely on password rotation semantics. Replace those with managed identities, secrets vaults, or certificate-based authentication before disabling rotation.
- Perception risk with auditors. Even if technically superior, removing a long-familiar control can alarm auditors. Prepare robust evidence and documentation showing the risk-based rationale and alternative controls.
- Incomplete deployment of modern mitigations. If MFA or banned lists are only partially deployed, skipping rotation may create gaps; a phased, measured rollout is recommended.
(Where specific regulatory claims are relevant — for example, if a given standard appears to require periodic rotation — validate those requirements against the latest regulatory texts. Some mandates in the wild remain prescriptive; these should be handled on a case-by-case basis with legal and compliance teams.
Technical facts IT teams should verify now
- Windows default maximum password age: Many Windows deployments show a default Maximum Password Age of 42 days for domain and standalone settings. This value remains configurable and remains the product default unless changed within Group Policy or local security policies.
- Microsoft baseline history: Microsoft’s older baselines have historically included 90-day and later 60-day recommendations; the v1903 security baseline removed password expiration from the recommended baseline settings and advised organizations to adopt modern mitigations.
- Baseline vs. default: Microsoft’s baseline removal is a recommendation change — it does not remove the Windows setting or its defaults. Administrators must act deliberately to change behavior in production environments.
These are verifiable configuration facts administrators should confirm in their own environments before altering policy.
The future: what password policy will look like over the next five years
The industry is increasingly moving toward identity models that de-emphasize memorized secrets.
- Passwordless becomes common. Platform authenticators (biometrics backed by secure hardware), passkeys (FIDO2), and certificate-based authentication will continue to expand — especially for privileged access and high-value resources.
- Stronger automated defenses. Risk-based adaptive authentication and real-time anomaly detection will be the norm, automatically applying step-up authentication, blocking, or forced resets based on behavior rather than a time calendar.
- Secrets management replaces service-account passwords. Infrastructure and automated workflows will rely on secrets vaults, managed identities, and ephemeral credentials rather than long-lived passwords, mitigating rotation headaches.
- More precise regulatory language. Compliance frameworks will likely evolve to accept risk-based approaches and modern mitigations over prescriptive rotation requirements — though some industries will lag, maintaining legacy requirements longer.
In short, passwords won’t disappear overnight, but the
role of scheduled expiration will likely become rare and exceptional, reserved only for specific edge cases rather than enterprise-wide doctrine.
Real-world checklist for Windows administrators
- Confirm whether any internal or external compliance rules mandate periodic rotation.
- Map all accounts (human and non-human) and classify by risk.
- Implement banned-password screening at password set/change time.
- Roll out MFA across the organization, prioritizing privileged accounts.
- Permit and encourage password manager use; allow paste into password fields.
- Replace service accounts with managed identities or secrets vaults where possible.
- Configure and test automated detection and forced reset procedures for suspected compromise.
- Communicate changes, training, and updated policy documentation to users and auditors.
- Pilot changes, measure the impact (helpdesk volume, sign-in failures, anomalous events), and refine.
Conclusion
Microsoft’s removal of periodic password expiration from its Windows 10 security baseline marks an important, practical evolution in enterprise security guidance. It acknowledges what modern research and operational experience have shown: forcing people to rotate memorized secrets on a schedule is a blunt instrument that often reduces security in exchange for an illusion of hygiene. The better path is the combination of
preventive measures (banned‑password lists, passwordless authentication, strong hashing, password managers) and
detective/response measures (MFA, anomaly detection, rapid reset on compromise).
This is not a license to relax identity protections. Rather, it’s an invitation to adopt a smarter, user‑friendly, and evidence-based identity strategy — one that reduces predictable human error, embraces stronger authentication options, and focuses incident response where it counts. Administrators who treat the baseline change as a catalyst for modernizing identity controls will improve both security and usability; those who casually drop rotation without embracing compensating controls will increase risk. The path forward is deliberate, measurable, and centered on modern authentication and detection-first defenses.
Source: Mashable
Microsoft realizes password expiration is poor security