How do you audit NTLM authentication usage across a Windows domain?

What NTLM audit data should you collect first?

Start with authentication events from domain controllers, member servers, and any tier-0 or tier-1 systems that still accept Windows logons. The key question is not just whether NTLM appears, but where it appears and under what service context, because that tells you whether the usage is expected legacy traffic or a path that should be removed.

A useful audit view separates user interactive logons, service logons, and machine-to-machine authentication. That distinction helps you find NTLM use that is operationally necessary today, versus usage that persists only because a workstation, application, or service has not been modernised. If you only look at one log source, you will miss a large part of the domain-wide picture.

For a structured baseline, it helps to anchor the audit in a broader Windows hardening plan such as Active Directory and Entra ID Hardening Guide, because NTLM review is most effective when it sits alongside privileged group review, delegation review, and legacy protocol removal.

How do you distinguish legitimate NTLM from risky NTLM?

Not every NTLM event is equally important. Some are legacy exceptions, for example an old application, appliance, or vendor integration that has not been updated. Others are stronger indicators of exposure, especially where NTLM appears on servers that should already be Kerberos-capable or on sensitive systems where replayable authentication materially increases attack options.

The practical test is to map NTLM use to the account, host, and service that generated it. If a line-of-business application on a known exception server uses NTLM, document the business owner, the justification, and the planned retirement date. If a domain admin, a privileged service, or a critical server suddenly starts using NTLM where Kerberos is normal, treat that as a signal worth deeper investigation rather than routine drift.

Threat researchers and incident writeups repeatedly show that credential and session material can be abused once an attacker gets into the path of Windows authentication. Cases like Cisco Active Directory credentials leak 2025 and Cisco Yanluowang breach 2022 are reminders that once credentials or machine accounts are exposed, lateral movement can follow quickly.

How should the audit results drive reduction and containment?

Use the audit to build a prioritised removal list, not just a report. Systems that are both business-critical and still dependent on NTLM deserve the most attention, because they often require a migration plan, a compatibility test, and an owner who can sign off on the change. Low-value exceptions that serve no current business purpose should be removed first.

Where NTLM cannot be turned off immediately, reduce the blast radius around it. That means limiting where the protocol is allowed, reducing privileged account use on legacy paths, and validating whether the service actually needs domain-wide authentication or just a narrow exception. If an exception is tied to a service account, review whether that account has excessive permissions or long-lived credentials that expand the risk beyond the protocol itself.

Audit findings should also feed into identity and access governance. If the same accounts keep appearing in NTLM logs, the root issue may be privilege sprawl, stale service ownership, or missing lifecycle control rather than the protocol alone. That is why account review and hardening guidance such as Ultimate Guide to NHIs — Regulatory and Audit Perspectives and Workforce Identity Security Guide are useful companions for a reduction programme.

Risk and Threat Considerations

NTLM is risky because it preserves compatibility at the cost of weaker security properties than Kerberos, especially where replay resistance and delegated trust matter. In a Windows domain, that creates an attractive path for credential replay, pass-the-hash style abuse, and lateral movement if an attacker obtains the right secret material or reaches a host that still accepts NTLM.

Failure mechanism: A system that still accepts NTLM can let an attacker reuse captured authentication material or abuse legacy trust paths when Kerberos should have been used, especially on servers, service accounts, or admin workflows that were never fully modernised.

Impact: Successful abuse can expose adjacent systems, widen lateral movement, and make a single compromised account more valuable than it should be. In practice, the biggest danger is not one NTLM event by itself, but repeated NTLM use across privileged or high-trust paths.

Practitioner Guidance

What to prioritise: Start with domain controllers, then high-value servers, then any service accounts that authenticate frequently. That order usually gives the fastest view of whether NTLM is a rare legacy dependency or a routine enterprise pattern.

What to verify: For each NTLM source, confirm the owner, the business reason, and whether Kerberos is actually feasible. If the answer is uncertain, treat the exception as temporary until someone proves it is required.

Common mistake: Teams often stop at counting NTLM events. The more useful control is to tie each event to an accountable system, then decide whether the usage should be eliminated, constrained, or explicitly accepted.

Practitioner takeaway: The audit becomes valuable when it produces a removal queue, not a raw log summary, because the real objective is to shrink legacy authentication surfaces before they become an attacker’s easiest movement path.

Related resources from NHI Mgmt Group

• What breaks when authentication, email delivery, and domain management are scattered across separate admin paths?
• How should security teams govern AI usage when retention windows differ across consumer, enterprise, and API tiers?
• How should security teams implement an API security audit program across discovery, authentication, validation, and monitoring?
• What happens when an attacker can combine session 0 access, a logged-in Domain Admin, and NTLM relay on the same Windows host?