Radioactive Directory

BlockNTLMv1SSO flips from Audit to Enforce

NTLMv1 was removed as a protocol in Server 2025 and Windows 11 24H2 — and nowhere else, so anything older still has it — but even on those newest builds, remnants of NTLMv1 cryptography survive in single sign-on paths, most visibly MS-CHAPv2 on domain-joined machines. In October 2026 the default value of BlockNTLMv1SSO changes from 0 (Audit) to 1 (Enforce) on any machine where the key has not been deployed manually.

Note the condition: if you have explicitly set the key, your value is respected and nothing moves. If you have not, it moves for you. Anyone keeping a legacy dependency alive on audit mode should set the key deliberately rather than discover the flip.

NTLM deprecation, phases 2 and 3

Microsoft's roadmap runs in three phases. Phase 1, enhanced NTLM auditing, is available now in Server 2025 and Windows 11 24H2 and is the part you should actually be using. Phase 2 brings IAKerb and a local KDC to broad availability in H2 2026, having entered public preview for Insiders in June 2026. Between them they remove the two most common reasons NTLM survives: Kerberos needing line of sight to a domain controller, and local account authentication.

Phase 3 disables NTLM by default in the next Windows Server and client release, requiring explicit re-enablement through policy. Be honest about the horizon, though: "next major release" plus enterprise adoption is a multi-year story, and NTLM is not being deleted from the OS, only switched off by default. The auditing will be useful to you long before the deprecation is.

RC4 in Kerberos: the three-phase removal, and where the bits live

DefaultDomainSupportedEncTypes controls what a KDC treats as the assumed encryption types for accounts with no explicit configuration. Historically it defaulted to 0x27, meaning DES, RC4 and AES-SHA1 session keys. On Server 2025 the default is 0x24, because DES is gone. The three phases:

13 January 2026 — audit only. Nothing changes yet: the default is untouched and the updates simply log warnings for accounts that would break, as Event IDs 201–209 in the System log. Controlled by a new registry subkey, RC4DefaultDisablementPhase.
14 April 2026 — the default actually moves. For accounts with no explicit msDS-SupportedEncryptionTypes, the KDC default becomes 0x18, AES-SHA1 only. Rollback is still possible via RC4DefaultDisablementPhase. Event 205 flags explicit configurations that are themselves insecure.
July 2026 — updates from July onward stop reading RC4DefaultDisablementPhase at all. 0x18 is enforced and there is no rollback.

Two bitmask notes worth having while you audit: 0x18 means AES128 and AES256 in both msDS-SupportedEncryptionTypes and DefaultDomainSupportedEncTypes, and 0x20 is honored only in DefaultDomainSupportedEncTypes. Why this matters beyond breakage: RC4 service tickets are what make Kerberoasting cheap. Removing the fallback removes most of the offline cracking economics with it.

Certificate-based authentication: strong mapping is mandatory and the escape hatch is gone

KB5014754 shipped in May 2022 and put domain controllers into Compatibility mode. Two dates matter since, and they get confused with each other constantly. On 11 February 2025 DCs moved to Full Enforcement automatically unless the registry key had already been set. On 9 September 2025 the StrongCertificateBindingEnforcement key stopped being supported at all, removing the ability to fall back to Compatibility mode.

Practical consequence for anyone reading the ESC literature, stated carefully because it is easy to overstate: a patched, current DC can no longer be put into the weak-mapping state via StrongCertificateBindingEnforcement, which closes one of the two routes into ESC9 and ESC10. The other route is still open. Both also work where Schannel's CertificateMappingMethods includes the UPN flag, and that is a separate registry value on a separate schedule which none of this touched. Check it independently. What broke along the way: certificates issued before the SID extension existed, and third-party CAs that do not populate it.

The Server 2025 defaults, and the upgrade trap

Server 2025 and Windows 11 24H2 ship meaningfully harder than anything before them. NTLMv1 is removed. DES is removed. Read that as narrowly as it is written: this is the newest builds only. Server 2019 and 2022, Windows 10, and Windows 11 up to 23H2 still ship NTLMv1 and still accept it unless you have hardened LmCompatibilityLevel yourself. For most estates that is still the majority of the fleet. SMB signing is required by default for all outbound connections, where previously it was required only for SYSVOL and NETLOGON and by domain controllers. An SMB authentication rate limiter is on by default, which blunts brute forcing. The SMB client can block NTLM outright for outbound connections via Disable-SmbClientNtlmAuth. New Active Directory deployments require LDAP signing by default, LDAP channel binding is set to When supported, client encryption is preferred, and channel binding auditing is on, with events 3074 and 3075 available to find the clients that would break under a stricter setting.

The trap is upgrades. These are defaults for new deployments. An environment upgraded in place keeps whatever it had, which for most estates means settings it has carried since 2012. Do not assume a Server 2025 domain controller gave you any of this.

NTLMv1 use is being logged before it is blocked

Since September 2025, attempts to use NTLMv1-derived credentials are logged under Event ID 4024 while authentication continues to work. This applies to the builds where NTLMv1 was removed, meaning Server 2025 and Windows 11 24H2 and later; on older systems NTLMv1 is not removed, not audited by this event, and simply still works. This is the audit window before the October 2026 change below. If you want to know whether that one is going to hurt, 4024 is the event that tells you, and it is telling you now.

The shape of all of these

Every one of these follows the same arc. An update ships the capability and logs what would break. A later update enforces it, with a rollback. A third update removes the rollback. The audit phase is the entire opportunity, and it is the phase everybody skips. If you take one thing from this page, take the event IDs: 4024 for NTLMv1-derived credentials, 3074 and 3075 for LDAP channel binding, 39, 40 and 41 for certificates with no strong mapping, a certificate predating the account, and a SID mismatch respectively, and 201–209 for RC4, of which 205 is the one that flags an explicit configuration that is itself unsafe. Each one is telling you in advance what the next enforcement date is going to cost you.