Thanks for the detailed clarification around the RC4 roadmap and the upcoming enforcement phases.
While testing these changes in a lab and reviewing multiple customer environments, one important operational takeaway is that relying only on Event IDs 4768 and 4769 in the Security log does not always clearly show which scenarios are actually at risk for breaking when enforcement mode arrives.
The new System log events (201, 202, 206 and 207) introduced with the January 2026 updates are extremely valuable because they specifically identify situations where RC4 is being used due to configuration gaps such as:
- service accounts without AES keys (often due to very old passwords)
- services where msDS-SupportedEncryptionTypes is undefined or still allowing RC4
- clients that only advertise RC4 capabilities
In several environments I analyzed, the majority of RC4 usage visible in 4769 events was not due to hard dependencies on RC4, but rather due to legacy account configurations or passwords that had never been reset since AES support was introduced.
Because of this, correlating the new System events with traditional Kerberos ticket events across all domain controllers becomes a very effective way to identify the true sources of RC4 usage before moving to enforcement mode.
I documented some of these observations and analysis approaches here for anyone preparing for the RC4 enforcement phases:
https://github.com/v-jfanca/cve-2026-20833-rc4-kerberos/blob/main/docs/kerberos-rc4-cve-2026-20833-EN-US.md