Quick answer
If you're on a domain, you can't bypass this without admin help — request a password reset or use a brand-new password. On a local machine, you can clear the password history via secpol.msc or reset it with net user if you have admin rights.
What's actually happening here
Windows enforces a password history policy that remembers the last N passwords you've used (default is 24 on domain-joined machines, 0 on standalone Windows 10/11 unless you've set it). When you try to set a password that matches one of those remembered ones, the logon process returns 0XC000025C — a STATUS_PWD_HISTORY_CONFLICT. This isn't a bug; it's a deliberate security control to stop people from cycling back to a favorite password after a forced change.
The error typically appears on domain-joined machines where an admin set a history requirement. I've seen it bite people right after a mandatory 90-day password expiration — you change it, then a week later try to switch back to your old one, and bam, this error. On a local account, it only shows if someone manually configured the local security policy.
Fix steps
If you're on a domain (most common)
- Try a completely new password — not one you've used before. The policy remembers the last N (often 10 or 24), so you need something truly fresh. Add a number or symbol you've never used.
- If you need to reuse an old one, you can't. The domain controller enforces this, not your local machine. You'd have to ask your IT admin to either reset your password (which bypasses history in some setups) or raise the history count in Group Policy.
- Pro tip: When an admin resets your password via Active Directory Users and Computers, the "User must change password at next logon" option doesn't count as a historical password. So a reset genuinely clears the slate.
If you're on a standalone machine (local account)
- Open
secpol.msc(Local Security Policy) as admin. - Go to Account Policies → Password Policy.
- Double-click Enforce password history and set it to 0 (or a lower number than what you need).
- Click OK, then close. Now you can reuse an old password.
- If you want to keep the history but still change back, you can temporarily set it to 0, change the password, then set it back to the original value. The history is cleared when you set it to 0.
Alternative: Reset via command line (admin required)
net user <username> <newpassword>This works for local accounts. It doesn't check password history for the user being reset — I think that's a known quirk, but it's consistent. Run net user <username> first to see the account name if unsure.
On a domain-joined machine, net user only works on local accounts unless you're a domain admin and use net user <username> <newpassword> /domain. That resets a domain password, but again, it should bypass history.
If the main fix fails
If you're on a domain and the admin says you must reuse an old password for compliance, they can't easily do it without breaking policy. The only workaround is to temporarily lower the history requirement in Group Policy — which is a bad idea if you care about security. Another route: some organizations have a "password reuse exemption" group or a custom password filter. Check if your org offers that.
For local accounts, if secpol.msc isn't available (Windows Home edition), you can edit the registry:
HKLM\SAM\SAM\Domains\Account\Users\000001F4But messing with SAM is risky and not worth it. Use the command line instead.
How to avoid this next time
The real prevention here is understanding your org's password policy before you change it. Ask IT for the history count — it's usually in the same document that lists expiration cycles. Then generate a password that's genuinely new, not a variation of an old one. A common mistake I see people make: they change Summer2024 to Summer2024! and wonder why it's rejected. The history check hashes the password and compares it exactly — it doesn't do fuzzy matching, but a single character change often still matches if the base is the same? No, wait — it's exact hash comparison. So adding a character is fine, but if the history includes the exact same string (with or without the exclamation), it'll fail. To be safe, change the core word entirely.
If you're an admin, consider setting history to something reasonable like 10. Beyond that, users start writing passwords down, which defeats the purpose. And if you're on Windows 11 22H2 or later, passwordless options like Windows Hello or security keys might reduce the pain — but they don't remove the policy for traditional logons.