In July 2026 Microsoft is making a change that may impact your environment. The change being implemented will make your environment more secure by no longer accepting the RC4 algorithm for the Kerberos protocol by default. The problem though is it could cause authentication failures, services to not start, and Kerberos to stop working. Microsoft has been working to implement this change since January 2026, and July 2026 is the final phase.
What’s Changing and Why
The change Microsoft is making is related to an information disclosure security vulnerability found in CVE‑2026‑20833. To fix this vulnerability Microsoft is stopping the default use of the RC4 encryption algorithm in Kerberos authentication. RC4 encryption has been around since the 80s, has several known vulnerabilities associated with it, and is no longer recommended for use in production environments. The specific risk is “Kerberoasting” an attacker requesting service tickets and cracking the weaker RC4 encryption offline to recover service account passwords.
How Microsoft Has Rolled This Out
Microsoft has been preparing for these changes in phases since January 2026. The first step was an Audit phase, which started recording messages in domain controller event logs. In the System event log, watch for the new events created specifically for this change:
- Event ID 201, 202, 206, 207 – RC4 default disablement / at-risk interactions and service accounts
- Event ID 205 – logged when an explicit configuration still allows RC4
In the Security event log, you can also review:
- Event ID 4768 – Kerberos Authentication Service (AS request / Ticket Granting Ticket)
- Event ID 4769 – Kerberos Service Ticket Operations (Ticket Granting Service – TGS)
Inside these events, an encryption type of 0x17 indicates RC4 is being used.
The next change came with the Windows update in April 2026, which moved domain controllers into enforcement mode by default . This blocked RC4 connections from non-compliant devices for accounts using the default encryption configuration. If you started encountering issues after the April update, you could modify the Active Directory account and set the attribute msDS-SupportedEncryptionTypes to include RC4 (0x24). This was meant to be a workaround, not a permanent fix.
The final phase arrives in July 2026, when the temporary registry escape hatch goes away… Microsoft removes support for the RC4DefaultDisablementPhase registry key that some organizations used to postpone the change. After July, that delay option is gone, and you’ll no longer have the choice of putting off tomorrow what you now get to fix today. (Note: explicitly configured per-account overrides are still honored even after July but relying on them keeps you exposed to the very vulnerability this change exists to close, so they should be a controlled last resort, and a plan to open up vulnerabilities, not succeed…)
What to Review in Your Environment
The key parts of your environment that should be reviewed are service accounts, applications using Kerberos or Windows Authentication, older systems, and with SQL Servers: linked servers and the accounts being used. Have a sysadmin review your domain controller event logs for the event IDs above and check whether RC4 (0x17) is in use. A bigger lift will be verifying your application libraries and drivers are up to date and checking whether older software in your environment supports AES encryption.
“We Deployed April and Had No Problems… Do I Still Need to Check?”
You may be asking yourself, “We’ve deployed the April update and haven’t had any problems, do I really need to check all these things?” The impact of not checking means that in July you may start to experience one, or all, of the following:
- Failed database connections (Windows-authenticated SQL Server)
- Linked server authentication failures
- Application login issues
- Service startup failures
- Kerberos delegation failures
If your environment is up to date on Windows updates and your system administrators have kept up with this change, your chances of experiencing any of these issues are much lower. As we all know, that chance is almost never zero, and taking one last look isn’t going to hurt. If anything, you may find the one thing that was overlooked which could save the company from coming to a grinding halt when RC4’s default support ends for good.
Where to Learn More
If you would like to read more about the change, you can look up CVE‑2026‑20833 or review Microsoft’s official guidance. Reviewing your environment now can help ensure a smooth transition and avoid unexpected disruptions.
- How to manage Kerberos KDC usage of RC4 (CVE-2026-20833) — Microsoft Support (KB5073381)
- Detect and Remediate RC4 Usage in Kerberos — Microsoft Learn
- Kerberos and the End of RC4: Protocol Hardening and Preparing for CVE‑2026‑20833 — Microsoft Community Hub
Check Your SQL Server Security and Upgrade!
While you are at it – don’t forget to check your own SQL Server security. We can definitely help with our health checks, but you can also just download our free SP_CheckSecurity proc and check your own security. And if you are on an unsupported SQL Server (which will include SQL Server 2016 soon) Check out some of our posts on SQL Server 2016’s final countdown and upgrade best practices.