Fix ERROR_NT_CROSS_ENCRYPTION_REQUIRED (0x56A) Password Change

What this error actually means

Windows throws 0x0000056A (ERROR_NT_CROSS_ENCRYPTION_REQUIRED) when you try to change a user password and the system decides the new password must be encrypted with a different algorithm than the one your account currently uses. This usually happens in Active Directory environments where Kerberos is configured with strict encryption types, or when a third-party tool calls NetUserChangePassword and the client and server don't agree on which hash to send.

I've seen this on Windows 10 and Server 2016+ when an admin tries to reset a user's password via net user or PowerShell, and the domain policy forces AES while the client is trying to send an RC4 hash. The old password is fine, the new password is fine, but the protocol handshake chokes.

Here's the flow. Try the quick fix first. If it doesn't stick, move down. You can stop at any point.

Fix 1: Change the password via a different method (30 seconds)

The fastest workaround is to bypass whatever tool you're currently using. If you're in PowerShell trying Set-ADAccountPassword, try the interactive Ctrl+Alt+Del password change instead. If that fails too, try net user username newpassword from an elevated command prompt.

net user jsmith NewP@ssw0rd123

Why this often works: the interactive logon path and the net user command use a different code path than the managed API. They sometimes negotiate the encryption type differently, and the error disappears. It's not a real fix, just a sidestep, but if you just need the password rotated, this gets it done.

If this works, you're done. The underlying encryption mismatch still exists, and it'll bite you again later, so schedule a deeper fix anyway.

Fix 2: Align Kerberos encryption types (5 minutes)

The real issue is usually a mismatch between what the client is willing to send and what the domain controller expects. On the client machine that's throwing the error, check the local security policy or registry for Kerberos encryption types.

Open an elevated Command Prompt and run:

reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Look for SupportedEncryptionTypes. If it's set to something like 0x7FFFFFFF (all types) or 0x8 (RC4 only), that's the problem. You want to include AES. Set it to 0x1C (AES128 + AES256 + RC4) or just 0x10 (AES256 only) if your domain supports it.

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters /v SupportedEncryptionTypes /t REG_DWORD /d 0x1C /f

Reboot, then retry the password change. What's happening here is that the client is advertising an encryption type it can handle, and the DC takes that as permission to request a cross-encrypted change. By forcing AES support, you remove the conflict.

If you're the domain admin, also check Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options and look for Network security: Configure encryption types allowed for Kerberos. Make sure AES is enabled there too.

Fix 3: Reset the password as a domain admin (15+ minutes)

If the error persists, the account itself might be in a weird state where the existing password hash is only stored in one encryption type, and Windows refuses to do a cross-encrypted change. The nuclear option is to reset the password from a domain controller, which bypasses the cross-encryption requirement because the DC can regenerate all the hashes.

1. Log into a domain controller (or use RSAT with admin rights).
2. Open Active Directory Users and Computers.
3. Right-click the user, select Reset Password.
4. Enter the new password, uncheck User must change password at next logon if you don't want to force it.

This works because the DC handles the change natively and computes the new AES and RC4 hashes from the plaintext you supply. There's no cross-encryption negotiation because the DC is the authority.

But wait—if you're not a domain admin, you can't do this. Ask your IT team, or if you're stuck, there's one more trick.

Bypass with a local account (if applicable)

If this is a local account (not a domain account), you can burn the account and recreate it, but that loses the profile. Better: boot into Safe Mode and use the built-in Administrator account to change the password. Safe Mode with Networking still works.

net user jsmith NewP@ssw0rd123

In Safe Mode, the encryption requirements are relaxed because the domain isn't involved, if it's a local account. For domain accounts, Safe Mode won't help unless you're on a DC.

Why the error happens in the first place

This error is Microsoft's way of saying "I could change this password, but I'm not allowed to because the encryption types don't match." Windows stores multiple hashes for each account—RC4, AES128, AES256—but when you change a password, the system uses the hash of the old password to prove you know it. If the client only has the RC4 hash and the DC refuses to accept RC4 for the change operation (usually because of policy), you get this error.

The reason step 3 works is that the DC resets the password with its own authority, not by proving knowledge of the old password. So there's no cross-encryption check at all.

If this error is happening on a regular basis, your environment has a policy that restricts RC4 and some clients aren't configured for AES. Fix the clients, not the passwords.

Tip: If you're using a third-party password manager or a script that calls NetUserChangePassword, you'll hit this more often. Those tools often send the old password hash in a single encryption type. Switch to Set-ADAccountPassword with the -Reset flag if you're an admin, or use the interactive UI.

That's the whole story. Start with the quick workaround, then align encryption types, then escalate to a DC reset. The error is annoying but never fatal.