Microsoft’s announcement that it will be phasing out RC4 as an encryption algorithm in Kerberos authentication marks the next major security change in Windows environments, following on directly from the NTLM phase-out.
For IT administrators, this means concrete action is required, with deadlines looming and the potential for system failures if action is not taken now.
What is RC4, and why is it being phased out?
RC4 (Rivest Cipher 4) is a stream cipher algorithm that has been used in Kerberos authentication since the early versions of Windows. It has been retained primarily for compatibility reasons: older devices, legacy applications and service accounts that were never migrated to stronger encryption have relied on it tacitly for years.
Kerberos is the primary authentication protocol in Active Directory environments. When a user or service logs in, a domain controller (Key Distribution Centre, KDC) issues an encrypted ticket that proves the identity of the requester to other services.
The problem: RC4 is now considered cryptographically broken. Its weaknesses enable specific attacks:
- Kerberoasting: Attackers request service tickets encrypted with RC4 and crack the passwords of the associated service accounts offline, without direct access to the system.
- Pass-the-Hash / Credential Theft: Stolen hashes are sufficient to authenticate.
- Lateral Movement: Compromised service accounts with excessive privileges enable the complete compromise of the domain.
RC4 is therefore a key attack vector in modern Ransomware campaigns targeting Active Directory environments.
The official Microsoft timeline
Phase 1, Audit Phase: January 2026 (completed / active)
Microsoft launched the audit phase with the Windows Cumulative Update of 13 January 2026. RC4 is not yet blocked, but new event IDs are being introduced into the domain controllers’ event logs: 201, 202, 206, 207, 4768, 4769.
Ticket Encryption Type 0x17 in the security events indicates RC4 usage. Microsoft has made two new PowerShell scripts available on GitHub: List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1.
Anyone already seeing audit events during this phase has RC4-dependent systems and will experience outages in Phase 2.
Phase 2, Enforcement Phase: April 2026 (currently active, most critical phase)
The enforcement phase comes into effect with the April 2026 update:
- The default value for
DefaultDomainSupportedEncTypeswill be set to0x18 (AES-SHA1 only)set - RC4 will no longer be negotiated for any accounts without explicit configuration
- Service accounts without the
msDS-SupportedEncryptionTypesattribute will now only receive AES-encrypted tickets - A rollback to audit mode is still possible, but is classified as a purely temporary measure
Phase 3, Final Enforcement: July 2026 (forthcoming)
With the July 2026 update, audit mode will be completely removed:
- The registry key
RC4DefaultDisablementPhasewill no longer be read - RC4 will be completely removed from the Kerberos KDC path
- Only accounts with an explicitly set
msDS-SupportedEncryptionTypesvalue can use RC4 (strongly discouraged) - Rollback is no longer possible
Specific implications
Service accounts
Service accounts whose password has never been reset since the introduction of AES-SHA1 (Windows Server 2008) may only have RC4 keys. Typically affected:
- SQL Server service accounts
- IIS application pools
- Scheduled Task accounts
- Backup services
NAS systems and file shares
Network storage devices integrated into Active Directory via Kerberos will fail without explicit AES configuration. Particularly affected are Synology (older firmware), QNAP, NetApp and FSLogix profile shares on Azure Virtual Desktop and RDS.
Printers and multifunction devices
Devices that use Kerberos for Scan-to-Folder or SMB authentication will no longer be able to obtain tickets after the enforcement phase. This affects, amongst others, older devices from HP, Canon, Kyocera and Ricoh.
Linux systems with Samba
Older Samba configurations use RC4 as a fallback. Unless the settings are updated in the smb.conf or krb5.conf authentication will fail.
Active Directory: krbtgt account
Often overlooked: if the krbtgtaccount has never been changed since the upgrade to Windows Server 2008, it may not have AES keys, which can lead to widespread authentication errors.
The security risk: typical attack chain
Attackers gain initial access to a client on the network.
Kerberos service tickets for all SPNs are requested via a compromised domain account.
The RC4-encrypted tickets are cracked offline using tools such as Hashcat.
Plaintext passwords for service accounts with elevated privileges are extracted.
Lateral Movement and privilege escalation, leading to complete domain compromise.
This attack method requires no administrator rights and initially leaves hardly any traces in the event log.
Mint Secure GmbH
What administrators need to do now
Enable Kerberos auditing
On all domain controllers running Windows Server 2019/2022/2025 or later:
Audit Kerberos Authentication Service -> Aktivieren
Audit Kerberos Service Ticket Operations -> AktivierenAdditionally: Use Microsoft’s PowerShell scripts on GitHub (List-AccountKeys.ps1, Get-KerbEncryptionUsage.ps1).
Identify RC4-dependent accounts and systems
Use the new event IDs and scripts to carry out targeted checks: Which service accounts lack AES key material? Which computer accounts and NAS devices are affected?
Set the msDS-SupportedEncryptionTypes attribute
Explicitly set the attribute to AES for all affected service accounts and then reset the password; only then will new Kerberos keys be generated.
Reset the krbtgt account password
Rotate the krbtgtaccount once to generate AES keys. This should be carried out in a controlled manner and documented.
Test enforcement in audit mode
Before automatic activation, set the registry key RC4DefaultDisablementPhase = 2 on non-production domain controllers for testing purposes and identify any failures.
Carry out a Security Audit and Pentesting
Only a targeted audit will reveal which attack vectors are already exploitable in the current configuration and where RC4 is still being used in the background.
How Mint Secure supports you
As a specialist IT security service provider, Mint Secure supports organisations in the secure migration and hardening of their Active Directory infrastructure.
RC4 & Kerberos Audit
We analyse which accounts, systems and services still use RC4 and whether the krbtgt account holds AES key material.
AD Security Audit
We check delegations, trust relationships, Kerberos configuration, privileges and anomalies in the encryption configuration.
AD Penetration Testing
We simulate Kerberoasting, AS-REP Roasting, Pass-the-Hash and Lateral Movement to identify attack vectors.
Legacy System Analysis
We check printers, NAS systems, embedded devices and applications for RC4 dependencies and develop migration strategies.
Not sure whether your environment is affected? We’ll analyse your domain controller logs together with you. Get in touch.
Conclusion
The deprecation of RC4 in Kerberos is not a theoretical recommendation, but an ongoing, mandatory change with specific deadlines.
The audit phase began in January 2026, the enforcement phase will come into effect in April 2026, and from July 2026 there will be no turning back. Organisations that act now will avoid unplanned outages in their authentication infrastructure, close one of the most commonly exploited attack vectors in Active Directory environments, and significantly reduce the risk of complete domain compromise through Kerberoasting.
Now is the right time to act, before Microsoft makes the decision for you. Talk to us.
