ERROR_PWD_HISTORY_CONFLICT (0x00000269) — Password Reuse Fix

I know this error is infuriating — you've picked a password that follows every rule you can see, and Windows still slams the door with 0x00000269. Let's get you unstuck.

The message “You have attempted to change your password to one that you have used in the past” is literal. Windows isn't guessing. Your new candidate matches one of the last N passwords stored in the password history — and on a domain, the match is fuzzy, not exact.

The fastest fix

For a local Windows account (Windows 10 or 11, not joined to a domain):

1. Sign in with an admin account.
2. Open Local Security Policy: press Win+R, type secpol.msc, hit Enter.
3. Go to Account Policies → Password Policy.
4. Set Enforce password history to 0, and Minimum password age to 0.
5. Change your password to something genuinely new.
6. Put the settings back to what they were (typically 24 history and 1 day minimum age).

If you're on a domain — most corporate laptops are — those settings are locked by Group Policy and you can't touch them with secpol.msc. You'll see the values greyed out. In that case, you have two options: pick a password that clears the history and complexity checks, or ask IT to reset it for you (a domain admin can reset without history restrictions from Active Directory Users and Computers).

Why “something completely different” still fails

Here's the part that trips almost everyone up. On an Active Directory domain, the password filter doesn't do a naive string compare. It normalizes the password (lowercases it, strips non-alphanumerics, splits on whitespace) and then checks whether any token of your new password appears in any token of your old passwords.

So if your old password was Summer2023!Work and you try Winter2024!Work, it rejects with 0x00000269 — because the token work is shared. Same for Contoso#Finance1 → Contoso#Finance2. The digits changed; the meaningful chunk didn't.

Rule of thumb: at least three of the four character classes (upper, lower, digit, symbol) need to be genuinely different, and no word longer than three characters can repeat from the previous password.

The real fix when you're on a domain

You can't edit domain policy from your workstation. What you can do:

• Change the whole phrase. Old: Blue-Laptop-2024! → New: FernPuffer-Tin-92#. Unrelated words, no shared tokens.
• Ask IT to force-reset. In ADUC, right-click the user → Reset Password → tick User must change password at next logon. This bypasses the history check once.
• Check for cached credentials. If you changed a different account's password recently (a service account, admin account) and you're now seeing this on your own, that's usually a credential manager leftover. Open Credential Manager → Windows Credentials and delete stale entries.
• VPN or RDP sessions. If you're connected over VPN, the policy applied on the DC is authoritative — nothing you do locally matters.

Less common variations of 0x00000269

1. Microsoft 365 / Entra ID sync

You change the password on-prem, then Entra Connect syncs it to the cloud, and your next cloud login fails with the same code. The cloud copy of the password history is checked by Entra ID, and the sync can lag by up to 30 minutes. Wait, then retry. If it still fails, check that password hash sync is enabled — if you're on pass-through auth, the check happens on-prem and the error is genuine.

2. Windows Hello PIN still using the old password

You reset the account password successfully, but Windows Hello keeps failing and throws 0x00000269 at the PIN prompt. That's not a history conflict — it's a stale PIN. Go to Settings → Accounts → Sign-in options → PIN (Windows Hello) → I forgot my PIN, and set it up again. The PIN is device-bound and doesn't auto-update when the underlying password changes.

3. Smart card / certificate logon

If your org uses smart card logon, the password field may be greyed out and the error appears when you try to set a new PIN via certutil. The fix is in Group Policy → Windows Settings → Security Settings → Account Policies → Password Policy, but only the domain admin can change it. Talk to your helpdesk — there's nothing you can do at the workstation.

4. Local account on a workgroup PC that was once domain-joined

This one's nasty. The machine still has the old domain's password filter cached in HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Even after leaving the domain, the local password history persists. Open Local Users and Groups (lusrmgr.msc), and check Password Policy — you'll see history is non-zero. Set it to zero, change the password, set it back.

Prevention

Honestly, the cleanest prevention is to stop reusing stems. A pattern like Spring2024!, Summer2024!, Fall2024! is going to get you flagged every 90 days on a domain with 24-password history. Use a password manager and let it generate something like gK9!mTqR$2wZ — no human memory required, no history conflict.

If you're the IT admin setting policy, think hard before dialing history up to 24 and minimum age up to 30 days. That combo is what generates most 0x00000269 tickets I've seen. A 10-password history with a 1-day minimum age accomplishes the same security goal with far fewer support calls.

One last thing: after any successful password change involving a domain account, lock the workstation (Win+L) and unlock it with the new password. Otherwise cached Kerberos tickets keep using the old one, and you'll chase ghosts for the next hour.