Kerberos RC4 Hardening: What to Check After the July 2026 Updates

What changed with the July updates?

Microsoft's staged fix for CVE-2026-20833 changes how domain controllers assume encryption support when no explicit configuration exists. The July 2026 phase removes the temporary audit-mode rollback. Explicit RC4 settings can still remain, so the result needs configuration review as well as patch verification. Check the rollout and exceptions in KB5073381.

The event date on this article follows the July 14, 2026 Windows Server security release. Use the update documentation for each server version in your environment when planning changes.

Look at the tickets your applications actually use

Microsoft's RC4 remediation guidance identifies Security events 4768 and 4769 as useful evidence of Kerberos activity. Ticket encryption, session-key encryption, and the keys available to an account are different fields. An RC4 entry in a list of available keys does not by itself prove that the current ticket used RC4. Use Microsoft's field definitions when reviewing the logs.

We recommend collecting evidence across a representative business cycle. A finance task that runs only at month end will not appear in a quick morning check. Include maintenance jobs, integrations, and the processes that run when an application switches to a standby server. Ask application owners to help define that coverage before deciding that an account is unused.

Give each service account an owner and a migration decision

Build a small working register for the accounts you find. For each entry, record the application, responsible team, hosts that use it, observed authentication, effective permissions, and the next change to test. This makes an exception a tracked piece of work instead of an unexplained setting that the next administrator inherits.

• Retire an account only after its owner confirms that the associated service is no longer needed.
• Test the normal workload and its scheduled or recovery tasks after changing authentication.
• Give temporary compatibility exceptions a review date and a specific exit condition.
• Review excessive access separately, even when the application authenticates successfully.

Where the application supports them, group Managed Service Accounts (gMSAs) provide automatic password management. Their deployment also requires deciding which hosts may retrieve the managed credentials. Compatibility and access restrictions belong in the design together. See Microsoft's gMSA management guidance.

Check the impact of an account compromise

Our assessment recommendation is to pair the migration register with an access review. If a service account were exposed, which file shares, servers, or administrative roles would become reachable? Which of those permissions does its application actually need? Stronger encryption is valuable, but that is a different question from whether the account has excessive access.

An authorized Active Directory penetration test can validate selected paths and give the infrastructure team evidence for prioritizing fixes. Define the accounts, validation methods, and stop conditions in the scope. Keep application migration, security testing, and any retest coordinated so that a successful change is recorded against both operational and security requirements.