Microsoft is disabling RC4 encryption for Kerberos authentication in Entra Domain Services, and the first fire drill lands on Monday, July 6, 2026. If any of your workloads still rely on that legacy cipher, they’ll likely break during a region-wide test that temporarily forces AES-only encryption—seven days before the change becomes permanent.

The company designed this advance dependency test to expose hidden RC4 dependencies before they cause a real outage. You can spot them now by turning on specific security audits, running a single Kusto query, and tracing every event 4768 and 4769. The deadline is tight, but the remediation path is specific.

Your region’s test date: Mark the calendar

The test isn’t a single global event. Microsoft runs it in three waves, each starting at 10:00 local time:

  • Americas – Monday, July 6
  • Europe – Tuesday, July 7
  • Asia-Pacific and China – Wednesday, July 8

During the test window, managed domain controllers in your region switch RC4 to enforcement mode. That means any Kerberos authentication or LDAP bind that still uses RC4 will fail. The disruption lasts until you either fix the dependency or manually revert the setting. One week later, starting July 13, RC4 is permanently disabled across all regions.

The two events that reveal every RC4 dependency

Microsoft’s documentation points you straight to two Windows security audit events: 4768 (a ticket-granting ticket request) and 4769 (a service ticket request). Both appear in the Entra Domain Services security logs once you enable auditing. Together, they show exactly which client, which service, and which account requested an RC4 ticket—down to the timestamp and the service principal name.

Use Sample query 7 from Microsoft’s official guidance. It’s a Kusto query designed to surface RC4 ticket issuance events. Run it before the test, reproduce your critical business transactions, and look for any 4768 or 4769 events that indicate RC4 usage. If you find one, you’ve found a dependency that will break during the enforcement window.

Do not skip the verification phase. A successful interactive Windows sign-in does not prove a workload is safe; it might use a different authentication path. Only a fresh audit trail showing no RC4 activity for the same client-to-service path confirms a fix.

Who is affected—and what the impact could be

For service owners and IT admins: Any application, scheduled task, Linux host, network appliance, or LDAP integration that authenticates against Entra Domain Services could be impacted. The failure will look like an authentication error, a failed service start, or an LDAP bind rejection. The business impact depends on what the workload does—a broken payroll import is more urgent than a stale lab script.

For developers and DevOps teams: Java apps, keytab-based services, and older middleware stacks are common culprits. An AES setting on the service account alone won’t fix them. You also need to verify that the client library, runtime, and the keytab itself support AES. For Linux services, the keytab must be regenerated with AES-capable encryption types, and the application may need a restart to pick up the change.

For home users: This doesn’t touch your personal device or Microsoft account. Entra Domain Services is an enterprise product. The risk lives entirely within managed cloud domains.

How we got here: The long goodbye to RC4

RC4 has been insecure for years. The Kerberos protocol in Windows Server had already been steering toward AES, but many organizations never removed the RC4 fallback. Microsoft accelerated the timeline with the January 2026 Windows update tied to CVE-2026-20833, a vulnerability that made an RC4 switch in managed domains urgent. That patch introduced the auditing capabilities and the phased enforcement model now rolling out.

In the background, a health alert called AADDS123 started flagging RC4 usage during service ticket issuance. Microsoft also released the advance dependency test concept to give customers a controlled way to find and fix problems. The logic is simple: better a scheduled fire drill than a surprise outage.

Pre-test survival kit: Audit, query, track, fix

Here is the sequence that works, drawn from both official guidance and real-world feedback from Windows administrators:

  1. Enable security audits on your managed domain. Microsoft’s Entra Domain Services documentation has a straightforward toggle for this.
  2. Run Sample query 7 against your audit logs. Capture all events that use RC4 ticket encryption types.
  3. Reproduce the critical business transaction that you suspect might be affected. Don’t just guess—actually trigger the login, the service start, or the LDAP bind while auditing is active.
  4. For every RC4 finding, create an incident record. Note the client host, the service principal name (SPN), the time window, and the business owner. Do not assume the account name in the event is automatically the broken component. The real dependency could be the application runtime, an embedded Kerberos library, or a stale keytab.
  5. Investigate the specific path. Check the client workload’s execution account, the target service’s encryption types, any keytabs in use, and the configuration of network appliances or middleware. Ask vendors directly: “Does this exact release support AES for Kerberos?”
  6. Fix the dependency. This might mean upgrading a library, regenerating a keytab, reconfiguring an application, or—in a worst case—replacing an unsupported appliance. Document the change.
  7. Retest and verify. Repeat the transaction and confirm the new audit trail shows no RC4 activity for the same client-service pair. Only then close the incident.

A common trap: resetting the service account password or changing its encryption type in Active Directory without first checking the client. That often masks the failure without solving it. Start with the evidence, not account settings.

If the test breaks your apps: The emergency rollback

Microsoft left a self-service escape hatch. Members of the AAD DC Administrators group can immediately restore RC4 during the test window. The steps are in the advance dependency test documentation: set rc4DefaultDisablementPhase to 1 (audit mode) and defaultDomainSupportedEncTypes to 60. Changes apply within about 10 minutes.

Use this only as a temporary continuity measure. Microsoft explicitly warns against relying on the rollback long-term because permanent enforcement begins July 13. Pair every rollback with a named owner, a remediation plan, and an expiration date. A restored RC4 path still needs the same evidence-based investigation it would have needed before the test.

After the test: A permanently AES-only environment

Assuming you remediate all dependencies, the permanent switch on July 13 will be a non-event. Your workloads will already be running AES. But if you skip the test and ignore the audit warnings, you’ll face a hard outage that Monday—with fewer options to recover quickly. Microsoft may not provide the same self-service rollback after the enforcement deadline.

The real win is an operational one: an AES-only domain eliminates a whole class of credential theft attacks and simplifies your security posture. The advance dependency test isn’t just a hurdle; it’s the last practical chance to get your house in order before the lock clicks shut.