Microsoft Is Killing RC4 in Kerberos. If You Have Not Acted, Here Is What You Need To Do Now.

Your EHR is probably the most secure system on your network. The authentication protocol that gets your users to it might not be. Microsoft is enforcing a change to Kerberos encryption defaults in April 2026 that will break authentication for accounts still relying on RC4 - and in health care environments running Active Directory, that means the systems your clinicians depend on every day are at risk if you have not audited and remediated. Here is what is changing, how to find out if you are affected, and exactly what to do about it.

What Is Actually Changing

The change is tied to CVE-2026-20833, an information disclosure vulnerability in Windows Kerberos caused by the continued use of weak cryptographic algorithms. Specifically, RC4-HMAC encryption in Kerberos service tickets allows authenticated attackers to request tickets encrypted with the weaker algorithm and perform offline cracking attacks to recover service account passwords. This is the attack technique commonly known as Kerberoasting, and it has been a favorite of penetration testers and real-world attackers for years.

Microsoft's response is a phased enforcement that changes how the Key Distribution Center (KDC) on your domain controllers handles accounts that do not have an explicit encryption type configured.

Here is the timeline:

January 13, 2026 (Audit Phase): New KDCSVC events (Event IDs 201 through 209) are introduced in the System event log on domain controllers. A temporary registry key, RC4DefaultDisablementPhase, is made available for testing. No breaking changes at this point - this phase gives you visibility into where RC4 is still in play.

April 2026 (Enforcement Phase with Manual Rollback): The default value for DefaultDomainSupportedEncTypes on domain controllers changes to 0x18, which means AES-SHA1 only. Accounts without an explicit msDS-SupportedEncryptionTypes configuration will no longer fall back to RC4. Enforcement mode is enabled by default. You can temporarily revert to audit mode via registry, but the clock is ticking.

July 2026 (Full Enforcement): The RC4DefaultDisablementPhase registry key is retired. Audit mode is removed entirely. Enforcement mode becomes the only operational state. RC4 fallback from the KDC path is permanently gone unless you have explicitly configured it on specific accounts.

The critical thing to understand here is that this change affects the default behavior of the KDC. If you have already explicitly set msDS-SupportedEncryptionTypes on your accounts, or if you have manually defined DefaultDomainSupportedEncTypes on your domain controllers, your behavior will not change. The accounts at risk are the ones where nobody ever set the encryption type attribute - it was left blank, and the KDC just fell back to RC4 when needed. That fallback is what is going away.

A Quick Note on the "AES-SHA1" Name

If you are reading "AES-SHA1" and wondering why Microsoft is moving you to something that includes SHA-1 - an algorithm that has been deprecated for TLS certificates and code signing - you are asking the right question. The short answer is that the SHA-1 component in Kerberos AES encryption types (AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96) is used as an HMAC integrity check, not as a standalone hash. HMAC-SHA1 is not vulnerable to the collision attacks that made SHA-1 unsafe for certificate signatures. It remains cryptographically sound for message authentication and is approved by NIST for this use.

Newer Kerberos encryption types using SHA-256 and SHA-384 do exist (AES256-CTS-HMAC-SHA256-128 and AES256-CTS-HMAC-SHA384-192), but they require Windows Server 2025 or Windows 11 24H2 and later. For the majority of health care environments running Server 2016, 2019, or 2022, AES-SHA1 is both the target and the correct target. It is a massive improvement over RC4 and is not a placeholder for something better - it is a durable, production-grade encryption suite.

Are You Affected? It Depends on What Kind of Account - Not What Year Your Domain Was Built

Before you start querying AD, you need to understand where the actual risk concentrates. The answer is more nuanced than "everything with a null msDS-SupportedEncryptionTypes is broken."

Regular user accounts are generally not the concern. A null msDS-SupportedEncryptionTypes on a standard user account is completely normal in Active Directory. It does not mean that account only has RC4 keys. When a user changes their password (or the password is reset) on a domain controller running Windows Server 2008 or later, the DC generates AES keys for that account automatically, regardless of whether msDS-SupportedEncryptionTypes is set. The attribute controls what the KDC advertises as supported during ticket negotiation, but the key material itself is generated at password change time based on the DC's capabilities. In a healthy environment where users change passwords regularly and all your DCs are Server 2008 or newer, your standard user accounts already have AES keys.

Service accounts with SPNs are the primary risk. Service accounts are the problem because their passwords are manually managed and are often set once and never changed. If a service account's password was last set when your environment still had Windows Server 2003 domain controllers - or even 2008 DCs that had not yet been configured for AES - that account may genuinely lack AES keys. These are also the accounts that Kerberoasting specifically targets, which is exactly what CVE-2026-20833 addresses.

Computer accounts are generally safe in healthy environments. Domain-joined computers automatically rotate their machine account passwords every 30 days via the Netlogon service. As long as that rotation is happening (it is, by default, unless someone explicitly disabled it via Group Policy), and your DCs are Server 2008 or later, your computer accounts have been cycling through AES-capable DCs for years. The exceptions are machines that have been offline for extended periods, machines where the automatic rotation was disabled via the DisablePasswordChange registry key, or very old systems that predate AES entirely.

The AZUREADSSOACC account is a specific, high-impact risk. If your organization uses Entra ID (formerly Azure AD) Seamless Single Sign-On, you have a computer account in AD called AZUREADSSOACC. This account was historically created with RC4 encryption by default, regardless of how modern the rest of your domain is. If this account does not have AES keys when enforcement hits, Seamless SSO will break - and that means every user in your environment will start getting unexpected Microsoft 365 authentication prompts. The fix is not a simple password reset; it requires a coordinated Kerberos key rollover through Microsoft Entra Connect (formerly Azure AD Connect). Check this account first.

Modern domains are not automatically safe. If your domain was built on Server 2019 or Server 2022 and you have never had a Server 2003 DC, your regular user and computer accounts are almost certainly fine. But AZUREADSSOACC can still be affected. Service accounts with SPNs can still be affected if their passwords were set once and never changed. The determining factor is not when the domain was created - it is which DC processed the last password change for each specific account.

Upgraded domains need extra scrutiny. If your domain was originally built on Server 2003 and has been upgraded over the years, the question for every account is: has this account's password been reset at least once while a Server 2008+ DC was handling the request? For user accounts with regular password expiration policies, the answer is almost certainly yes. For service accounts with passwords that were set in 2010 and never touched? Maybe not.

How To Find Your At-Risk Accounts

With that context in place, here is how to identify the accounts that actually need remediation. The priority order matters - start with the highest-risk, highest-impact accounts and work outward.

Priority 1: Service Accounts with SPNs

These are the accounts most likely to have stale passwords and the ones most targeted by Kerberoasting. This query finds service accounts with SPNs registered, sorted by when their password was last set:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes, @{N='SPNs';E={$($_.ServicePrincipalName -join '; ')}} |
    Sort-Object PasswordLastSet

Any service account whose password was last set before your environment had AES-capable DCs is a remediation target. Any service account with msDS-SupportedEncryptionTypes explicitly set to 4 (RC4 only) is a remediation target.

Priority 2: The AZUREADSSOACC Account

Check this one explicitly:

Get-ADComputer -Identity "AZUREADSSOACC" -Properties msDS-SupportedEncryptionTypes, PasswordLastSet |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes

If msDS-SupportedEncryptionTypes is null, 0, or 4, this account needs a Kerberos key rollover through Entra Connect before April. Do not just reset the password manually in AD - the rollover must be coordinated through Entra Connect to maintain the Seamless SSO trust. Microsoft documents this process in the Entra Connect Seamless SSO FAQ.

Priority 3: Computer Accounts with Stale Passwords

In a healthy environment, this list should be short. But check for machines that have not rotated their passwords recently:

Get-ADComputer -Filter {PasswordLastSet -lt "2020-01-01"} -Properties msDS-SupportedEncryptionTypes, PasswordLastSet, OperatingSystem |
    Select-Object Name, OperatingSystem, PasswordLastSet, msDS-SupportedEncryptionTypes |
    Sort-Object PasswordLastSet

If you get results here, those are machines that either have been offline for years (and may not even exist anymore), have had automatic password rotation disabled, or are running operating systems old enough to warrant a closer look.

Priority 4: The Broad Query (With Context)

You can query all accounts with null msDS-SupportedEncryptionTypes, but understand what the output means before you react:

Get-ADObject -Filter {(objectClass -eq "user" -or objectClass -eq "computer")} -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -eq $null -or $_."msDS-SupportedEncryptionTypes" -eq 0 } |
    Select-Object Name, ObjectClass, DistinguishedName, msDS-SupportedEncryptionTypes

This query will return virtually every standard user account in your domain. That is expected and does not mean your environment is broken. A null msDS-SupportedEncryptionTypes on a regular user account whose password has cycled through a modern DC is not a problem - the account has AES keys even though the attribute is not set. Use this query for awareness, not as a remediation target list. The service account and AZUREADSSOACC queries above are your actual action items.

Configuration Manager (SCCM/MECM/ConfigMgr) or Intune for Scoping

If you are running Microsoft Configuration Manager (formerly SCCM) or Intune, use your device inventory to scope the computer account risk. Configuration Manager's hardware inventory tells you what OS versions are deployed. Any device running Windows Server 2003 or earlier is a definite problem - those systems predate AES support entirely. Anything running Server 2008 or later supports AES, and if machine account passwords have been rotating normally, the computer accounts are fine.

Intune-managed devices are typically running modern Windows versions, so the bigger risk in Intune environments is usually around hybrid join configurations and the AZUREADSSOACC account rather than individual device encryption types.

Group Policy Audit

Check whether you have the following policy configured:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos

If this policy is configured and set to only allow AES128 and AES256, you are already in a better position than most. If it includes RC4_HMAC_MD5, or if it is not configured at all, you need to look deeper.

Also check the domain controller registry directly:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC\DefaultDomainSupportedEncTypes

If this value exists and is set to 0x18 (decimal 24), your domain controllers are already defaulting to AES-SHA1 only and the April update will not change your operational behavior. If this value does not exist, the April update will create it for you - and that is where things break if you have accounts that still need RC4.

Domain Controller Event Logs

If you have already applied the January 2026 cumulative update to your domain controllers (and you should have by now), check the System event log for the new KDCSVC events. The key ones to look for are:

Event ID 201: RC4 usage detected because the client advertises only RC4 and the service account does not have msDS-SupportedEncryptionTypes defined.

Event ID 202: RC4 usage detected for a service account that is at risk.

Event ID 205: Insecure configuration of DefaultDomainSupportedEncTypes detected.

Event ID 206 and 207: Additional warnings about at-risk configurations.

Microsoft's own guidance is direct: if you see Event IDs 201, 202, 206, or 207 in the System event log on your domain controllers, you are at risk for breaking changes when enforcement mode is enabled. The absence of these events does not guarantee safety - it means the KDC has not encountered the specific conditions that trigger them yet. You still need to audit proactively using the PowerShell queries above.

Microsoft has also published two PowerShell scripts in the Kerberos-Crypto GitHub repository specifically for deeper analysis:

List-AccountKeys.ps1 queries the Security event log on your domain controllers to enumerate the encryption keys available for each account. This tells you which accounts have AES keys and which ones only have RC4.

Get-KerbEncryptionUsage.ps1 identifies the Kerberos encryption types actually being used in your environment. Run it with the -Encryption RC4 parameter to find active RC4 usage:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Why Health Care IT Should Care About This Specifically

If you are in health care IT, this change has the potential to cause real operational disruption. Here is why.

FSLogix and VDI/RDS environments. If your organization uses FSLogix for profile containers on SMB file shares - and many health care organizations do, particularly those running Azure Virtual Desktop or Remote Desktop Services for clinical workstation access - this change can break profile mounting at logon. FSLogix stores user profiles in VHD/VHDX containers on SMB shares. When a user logs in, the client authenticates to the file server using Kerberos. If the file server's computer account or the associated service account does not support AES, that authentication will fail after the April update. The result: users get temporary profiles or failed logins entirely. In a clinical environment where nurses and providers rely on roaming profiles to access their EMR sessions, this is not an inconvenience - it is a patient care impact.

SMB file shares carrying ePHI. Many health care organizations store electronic protected health information (ePHI) on SMB file shares. Departmental shares, scanned documents, clinical data exports, reporting databases that write to file shares - all of these authenticate through Kerberos when accessed from domain-joined workstations. If the service accounts involved in those authentication flows still rely on RC4, access will break.

Seamless SSO to Microsoft 365. If your organization uses Entra ID Seamless SSO, the AZUREADSSOACC account is in the critical path for every Microsoft 365 authentication. If that account's encryption type is not remediated before April, every clinician and staff member in your organization will start seeing unexpected sign-in prompts for Outlook, Teams, and SharePoint. In a clinical workflow where providers are moving between workstations constantly, that disruption adds up fast.

Legacy systems and medical devices. Health care environments are notorious for running legacy systems long past their intended lifespan. That Windows Server 2008 R2 box running a specialty clinical application, the interface engine on an older OS, the lab system that has not been updated in years - these are all candidates for service accounts with stale passwords and no AES keys.

The HIPAA angle. To be clear: RC4 in Kerberos is not an ePHI encryption issue. Kerberos ticket encryption protects the authentication credential exchange, not the patient data itself. The HIPAA encryption specification under 45 CFR 164.312(a)(2)(iv) is about encrypting ePHI at rest and in transit - that is a different conversation.

Where this does connect to HIPAA is through the risk analysis requirement. Under 45 CFR 164.308(a)(1)(ii)(A), covered entities are required to conduct an accurate and thorough assessment of potential risks and vulnerabilities to ePHI. Under 45 CFR 164.306(a)(2), they must protect against reasonably anticipated threats to the security of that information. RC4-HMAC in Kerberos is a known-weak protocol that enables offline credential recovery via Kerberoasting. If an attacker cracks a service account password through an RC4-encrypted Kerberos ticket, and that service account has access to systems containing ePHI, the compromised credential becomes the path to a data breach. That is a reasonably anticipated threat, and it belongs in your risk analysis.

Running a known-vulnerable authentication protocol when a supported, enforceable alternative exists is the kind of gap that should be documented, risk-rated, and remediated - not because RC4 Kerberos directly violates a specific HIPAA technical safeguard, but because it creates an exploitable weakness in the authentication chain that protects access to ePHI systems. Moving to AES-SHA1 is not just about surviving the April update. It is about closing a documented attack vector before someone uses it against you.

What To Do Right Now

If you have not acted yet, here is your action plan.

Step 1: Make sure your domain controllers have the January 2026 cumulative update installed. This gives you the audit events and the RC4DefaultDisablementPhase registry key. If you are behind on patching your DCs (which is its own conversation), get them current.

Step 2: Check the AZUREADSSOACC account immediately. If you use Entra ID Seamless SSO, this is your highest-impact single account. Use the PowerShell query above to check its encryption type and password age. If it needs remediation, initiate the Kerberos key rollover through Entra Connect - this is a coordinated process, not a simple password reset, and it requires planning.

Step 3: Audit service accounts with SPNs. Use the prioritized PowerShell query above. Any service account with a password last set before your DCs were AES-capable, or with msDS-SupportedEncryptionTypes explicitly set to RC4 only, needs a password reset. But how you reset that password matters - see the guidance below on SQL Server accounts specifically.

Step 4: Remediate service account passwords carefully. For most service accounts, the fix is a password reset on a modern DC, followed by updating the password everywhere the account is used. Yes, this means you need to know every place that service account password is configured, which is why service account management should never be left to tribal knowledge.

SQL Server service accounts require special handling. If you are resetting the password for a SQL Server service account, do not update it through services.msc. Use SQL Server Configuration Manager instead. Configuration Manager updates the service SID, internal registry entries, and permissions on SQL-specific resources as part of the password change. Updating through services.msc changes the password but does not update those ancillary components, which can cause subtle permissions mismatches that surface later - sometimes days or weeks after the change, which makes them very difficult to troubleshoot. Given how many health care environments run SQL Server for EMR databases, reporting systems, and Configuration Manager site databases, this is not an edge case.

If you want to explicitly set the encryption type for a service account to AES-SHA1 only, use:

Set-ADUser -Identity "ServiceAccountName" -Replace @{"msDS-SupportedEncryptionTypes"=24}

The value of 24 (0x18 in hex) corresponds to AES128 + AES256.

Step 5: Check your file servers and FSLogix infrastructure. If you run FSLogix, identify every computer account and service account involved in your FSLogix SMB share authentication path. Verify that every one of them has AES keys. Do the same for any file server hosting ePHI or critical departmental data. Computer accounts on modern DCs that have been rotating passwords normally should be fine, but verify rather than assume.

Step 6: Review the KDCSVC events on your DCs. After running in audit mode for at least a few days, check the System event log for Event IDs 201, 202, 206, and 207. If you see them, you have more work to do. If you do not see them, that is encouraging but not definitive - validate through the AD attribute queries as well.

Step 7: Address the krbtgt account. The krbtgt account is the Kerberos ticket-granting account for your domain, and it also needs AES keys. Resetting its password regenerates all ticket-granting keys, but this is not a simple password reset - it is a two-phase process with a mandatory wait period between resets, and doing it wrong will cause a domain-wide authentication outage. We have a dedicated article that goes in depth on that process here: The Active Directory Maintenance Task Most Hospitals Are Not Doing: Rotating the krbtgt Password. Do not attempt this without understanding the full procedure first.

Step 8: Test enforcement mode before April forces it on you. You can proactively enable enforcement mode using the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Set RC4DefaultDisablementPhase to 2 (enforce). Do this in a test environment or on a single DC in a controlled manner to validate that everything still works before April makes it the default everywhere.

Step 9: Handle legacy exceptions. If you have systems that genuinely cannot support AES - and in health care, these exist - you can explicitly set msDS-SupportedEncryptionTypes on the affected account to include RC4 with AES session keys. Microsoft's recommended value for this scenario is 0x24 (decimal 36), which allows RC4 for ticket encryption while still requiring AES for session keys. This is more secure than fully re-enabling RC4 because it limits the exposure to the ticket encryption component only. Understand that this is still a security exception and should be treated as one - documented, time-limited, and tracked for remediation. As Microsoft states in their guidance, this configuration leaves the account vulnerable to CVE-2026-20833, and the long-term recommendation is to migrate to AES entirely. Microsoft has also set up a contact channel at stillneedrc4@microsoft.com for organizations with persistent RC4 dependencies.

Do Not Ignore This

This is not one of those changes where you can wait and see. The April update will enable enforcement mode by default on all Windows domain controllers. If you have service accounts or the AZUREADSSOACC account that depend on RC4 fallback and you have not remediated them, authentication will break. In a health care environment, that could mean clinicians cannot log in, profiles fail to load, EMR sessions do not launch, Microsoft 365 starts prompting for credentials at every workstation, and file shares carrying patient data become inaccessible.

The good news is that the fix is well-documented, the tools are freely available, and the remediation for most accounts is a password reset (done through the right tool for the right account type). The bad news is that you have very little runway left. If you have not started this work, start today.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.