A phone that signs in to an internal web app with NTLM writes no Windows event of its own. It only shows up on the server side, as a user name, a client name and a client IP. None of the events Microsoft documents for an NTLM inventory has a field for the client's operating system.
Microsoft calls enhanced NTLM auditing "the foundation of any NTLM migration effort", and on Windows 11 24H2 and Windows Server 2025 it is already switched on by default. The next date on Microsoft's list is October 2026, when the default for the BlockNTLMv1SSO registry value is due to move from Audit to Enforce. That change is narrow. The work it points to is not: knowing where NTLM still runs before network NTLM is disabled by default.
Microsoft has already removed the NTLMv1 protocol from Windows 11 24H2 and Windows Server 2025. What remains are NTLMv1-derived credentials used for single sign-on, which Microsoft says turn up in Wi-Fi, Ethernet and VPN deployments using MS-CHAPv2. With BlockNTLMv1SSO set to 1, Windows blocks the request to generate them (KB5066470).
The scope is small. The new default only applies where the value has not been deployed. Devices with Credential Guard enabled are not affected. Users who lose single sign-on can still connect by typing their credentials. And Microsoft still labels the date tentative, including in the article's latest update of 13 July 2026.
Phones and tablets are not touched in October; the value lives on Windows. The date that matters for them comes later. With the next major Windows Server release, network NTLM is disabled by default and needs explicit re-enabling through policy (Microsoft, 29 January 2026). The opening post of this series covers the full plan and what it means for Android and iOS.
Enhanced NTLM auditing ships with Windows 11 24H2 and Windows Server 2025, domain controllers included. Microsoft rolled it out gradually, clients first and servers later (KB5064479). Older servers and domain controllers do not produce these events. There, the existing policy "Network security: Restrict NTLM: Audit NTLM authentication in this domain" keeps doing what it did; Microsoft states the new events leave the existing logs unchanged.
The events are on by default. On clients and servers, the "NTLM Enhanced Logging" policy under Administrative Templates > System > NTLM controls them. On domain controllers it is "Log Enhanced Domain-wide NTLM Logs" under System > Netlogon. Everything lands in Microsoft-Windows-NTLM/Operational.
Each event comes as a pair with the same content: Information for ordinary NTLM, Warning for a downgrade such as NTLMv1, Extended Protection for Authentication marked as unsupported or insecure, or a missing message integrity check.
Client events carry a "Usage Id/Reason" field that says why Windows picked NTLM over Kerberos. That field also tells you who fixes it. For no line of sight to a domain controller (reason 9) and local accounts (reason 2), Microsoft is building IAKerb and Local KDC for the second half of 2026. For a target name Kerberos could not resolve (reason 6) or a target given as an IP address (reason 7), built-in handling is only planned for the next major Windows Server release, so those stay your job until then. Reason 1 means the application called NTLM directly, which makes it a question for whoever maintains that application.
The October change has its own two events in the same log. Event 4024, a warning, is written in Audit mode whenever NTLMv1-derived credentials are used. Event 4025, an error, means an attempt was blocked. Each 4024 on a device is a sign-in that will lose single sign-on there once the default flips, and the event names the target server, the user and the calling process. Setting the value to 0 yourself keeps today's behaviour. That buys time to replace MS-CHAPv2, but it does not replace it.
Because Android and iOS write no Windows events, a phone only shows up at the far end of the connection: on the target server as 4022 or 4023, and on the domain controller as 4032 or 4033.
So read the server events on the systems mobile users actually reach: intranet, internal web apps, SharePoint, file servers. If those still run an older Windows Server, they write no enhanced events, and you are left with the domain controllers and the existing NTLM auditing.
The events give you user names and addresses, not devices. The link to a device sits in the UEM. ISEC7 SPHERE pulls devices from the connected UEM systems, such as Microsoft Intune, Ivanti or BlackBerry UEM, into one database with operating system, patch level and installed apps. A user name from an NTLM event becomes a list of that user's devices across platforms. From version 20.9.0, individual apps can be tracked as "Monitored applications". Once you know which app is behind the NTLM sign-ins, ISEC7 SPHERE shows which users and devices have it installed. ISEC7 SPHERE sees what a connected UEM knows; a device outside management does not appear in any report.
Once a service moves to Kerberos, the change has to show from both ends. On the domain controller, the sign-in appears in the Security log as event 4768, "A Kerberos authentication ticket (TGT) was requested", provided "Audit Kerberos Authentication Service" is enabled (Microsoft Learn). It records the account, the client address and the pre-authentication type: 2 is a standard password sign-in, while Microsoft assigns 15 to 17 to smart card, that is certificate-based, scenarios. At the same time, the NTLM events for that user disappear from the target server. Only the two together prove the switch.
For mobile devices, Hypergate described this in our webcast of 23 September 2026 (in German, free recording after registration), presented by Simon Kolb of ISEC7 and Caglar Cölkusu of Hypergate. According to Hypergate, the Android or iOS device fetches its Kerberos ticket directly from the domain controller, and the mobile sign-in then shows up as event 4768 rather than as an NTLM logon. The two checks above tell you whether that holds in your environment.
If mobile devices sign in with certificates, check the mapping as well. Since the February 2025 update, domain controllers run in Full Enforcement mode and deny a certificate that cannot be strongly mapped to an account. Since the update of 9 September 2025, the registry switch back to Compatibility mode is no longer supported. Rejected certificates show up in the System log as event 39, source Kdcsvc (KB5014754).
Windows provides the events; reading them is work on your own network. For the mobile side, ISEC7 SPHERE supplies the device inventory from your existing UEM. As a Hypergate partner for Germany, the United Kingdom and the United States, ISEC7 then moves Android and iOS devices to Kerberos. For email, ISEC7 MAIL supports Hypergate as a sign-in method, as the webcast slide on supported methods showed. Our overview page on Acronis Cyber Files and NTLM is in German; for an initial assessment in English, contact us.
The next post in this series, due on 21 October 2026, walks through replacing Acronis Cyber Files step by step.