STATUS_PWD_TOO_RECENT (0XC000025B) — password change blocked by domain policy

You're sitting at a domain-joined Windows machine — probably Windows 10 or 11, maybe Server 2022 — and you try to change your password. Either through Ctrl+Alt+Del → Change a password, or via the Settings app, or through a remote desktop login prompt. The system kicks back error STATUS_PWD_TOO_RECENT (0XC000025B). The message reads: "The policy of your user account does not allow you to change passwords too frequently." You just set the password last week, and now it's telling you to wait. This is frustrating when you suspect a compromise or you've got a new password manager rollout.

Why this happens

What's actually happening here is that your Windows domain (usually Active Directory) has a Minimum password age policy configured. This policy sets a minimum number of days you must keep a password before changing it again. The default for most domains is 1 day. Some paranoid admins set it to 7 or even 14 days. The system tracks the last password change timestamp per user. When you try to set a new password before that minimum age expires, the domain controller (DC) rejects the change with 0XC000025B.

The reason this exists is to enforce password history — if you could change your password 10 times in a minute, you'd cycle through old passwords and bypass history restrictions. Microsoft's logic: block rapid-fire changes to keep the history meaningful.

The fix — three approaches

Pick the one that fits your situation. Most people need approach 1 or 2.

Approach 1: Wait it out (for end users)

1. Check how many days are left. Open Command Prompt or PowerShell and run:

net user %username% /domain | find "Password last set"

This shows the date you last changed your password. Compare it to today. If your domain's minimum password age is 7 days, and you set it 3 days ago, you've got 4 to wait.

2. Wait until that minimum age passes. There's no user-side override. This is enforced at the domain-level.

Approach 2: Admin changes the minimum password age

If you're a domain admin, you can drop the minimum age to 0 (allows immediate changes) or a lower value. Here's how:

1. On a domain controller, open Group Policy Management Console (gpmc.msc).
2. Find the Default Domain Policy or your custom password policy GPO.
3. Right-click → Edit → navigate to: Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy.
4. Double-click Minimum password age. Set it to 0 days (allow immediate changes) or a shorter interval like 1 day.
5. Run gpupdate /force on the DC and affected clients. Alternatively, wait for the next automatic refresh (90 minutes by default).

Approach 3: Reset password via admin tools (bypasses age check)

What's happening here is that a password set by an administrator doesn't enforce the minimum age — only password changes by the user do. So a domain admin can use Active Directory Users and Computers (ADUC) or PowerShell to set a new password directly, and it'll take effect immediately.

1. Open Active Directory Users and Computers (dsa.msc).
2. Find the user account. Right-click → Reset Password.
3. Enter the new password. Check User must change password at next logon if desired.
4. Click OK. The password is changed immediately, regardless of the minimum age.

Alternative using PowerShell:

Set-ADAccountPassword -Identity "username" -Reset -NewPassword (ConvertTo-SecureString "NewP@ssword123" -AsPlainText -Force)

What to check if it still fails

• Password history limit: If the new password matches one of your last N passwords (where N is the history size, often 20), you'll get a different error. Make sure the password is genuinely new.
• Fine-grained password policies (FGPP): Your user may be in a different password policy applied via a PSO (Password Settings Object). Check with Get-ADUserResultantPasswordPolicy -Identity username. That policy might have a higher minimum age.
• Password complexity: Some domains require uppercase, lowercase, digits, and special characters. If your new password fails complexity, you'll see a different error (STATUS_PASSWORD_RESTRICTION typically). But sometimes the system throws this error incorrectly. Double-check password meets requirements.
• Replication delay: An admin just changed the policy but it hasn't replicated to all DCs. Force replication with repadmin /syncall or wait.
• Local account vs domain account: This error only occurs for domain accounts. If you're on a local account, you're hitting a different error. Check that you're authenticating against the domain.

I've seen this most often when a helpdesk admin changes a user's password, and then the user tries to change it again within a day — thinking the temp password is insecure. The fix is either approach 3 (admin reset it) or educate the user to wait. If you're the admin and keep hitting this while testing, just set the minimum age to 0 during rollout, then revert it back to 1 day when done.