How do you find sign-ins using legacy authentication in Microsoft Entra ID?

What legacy authentication usually means in Entra ID sign-in data

Legacy authentication is not a single protocol, it is the older sign-in traffic that still uses basic or non-modern methods and bypasses the protections that modern authentication can enforce. In practice, the signal is usually visible in sign-in logs as older mail and client protocols, older client app types, or sign-ins that do not satisfy the conditions you expect from MFA and Conditional Access.

For Entra ID triage, the key is to separate who is still using legacy auth from what they are using it for. That usually means identifying the user, the app or mailbox, and the protocol path. Once you have that, you can tell whether the traffic is a real business dependency, a stale configuration, or an exposure that should be blocked. Microsoft’s own guidance on hardening identity providers and sign-in policy design is a useful companion when you are turning that analysis into policy decisions, as reflected in the Conditional Access Guide and the Identity Provider and SSO Security Guide.

The practical outcome is not just detection, but remediation. Legacy auth findings should feed a cleanup queue for clients, mailboxes, service dependencies, and exception handling, because these sign-ins are often the last route around modern controls.

How to isolate the legacy authentication sign-ins you actually care about

Start by reviewing sign-in activity for protocols and client patterns that are commonly associated with older authentication paths. Focus on the records that show a protocol or client type inconsistent with modern interactive sign-in, then group the results by user, application, and mailbox dependency. That gives you a defensible inventory of where legacy auth is still alive instead of a broad list of noisy failed attempts.

Once you have that inventory, look for concentration. A single shared mailbox, a small number of users, or one line-of-business application can make legacy auth look minor while still representing the main business dependency. That is why the useful question is not simply “did we see legacy auth?”, but “which identities and services still need it, and are they supposed to?”. If you need a broader control reference for the policy layer behind that review, NIST guidance on digital identity and authentication assurance is a good external anchor, including NIST SP 800-63 Digital Identity Guidelines.

When you compare sign-in records, pay attention to whether the same user also has modern sign-ins. Mixed behaviour often means the account is partially migrated, the client estate is inconsistent, or a fallback path is still enabled somewhere. That is the point where remediation becomes specific: upgrade the client, retire the protocol, or move the workload to a supported authentication method.

What to do after you find legacy authentication in Entra ID

Block legacy authentication where the business does not truly require it, then use the remaining findings to prioritise remediation. The highest-value targets are accounts and mail paths that still depend on older protocols for core access, because those are the easiest places for an attacker to bypass MFA and Conditional Access if the protocol remains available.

Where blocking is not immediately possible, treat the result as an exception with an owner and a deadline. Document why the legacy path still exists, what will break if it is removed, and what modernization step is replacing it. For teams that need an implementation checklist around MFA and legacy protocol gaps, the Top 10 MFA Mistakes and MFA Guide are practical references because they connect legacy protocol exposure to the controls attackers commonly bypass.

Use the sign-in results to drive an ordered cleanup: confirm exposure, isolate the protocol, block what can be blocked, then remediate the dependency. That sequence matters because it prevents teams from spending time on account cleanup before they have eliminated the weakest path into the tenant.

Risk and Threat Considerations

Legacy authentication is risky because it often sits outside the protection model you think you have in place. If a protocol cannot enforce modern controls, attackers who obtain a password or abuse a weaker client path may still be able to authenticate even when MFA and Conditional Access are otherwise expected.

Failure mechanism: The legacy protocol remains enabled, a user or mailbox continues to accept it, and the sign-in path bypasses the stronger controls that protect modern interactive access.

Impact: Attackers get a simpler route to mailbox access, message read access, or account abuse, and defenders lose the policy leverage needed to stop that access at the edge.

Practitioner Guidance

What to prioritise: Prioritise any legacy-authenticated account that touches mail, high-value collaboration data, or administrative workflows. Those are the cases where one old protocol can preserve a large amount of unnecessary access.

What to verify: Verify whether each legacy sign-in is an expected dependency, a stale client, or an avoidable exception. If you cannot name the business owner and the reason it still exists, it is usually a remediation candidate rather than a tolerated control gap.

Practitioner takeaway: The useful outcome is not a list of legacy sign-ins, it is a short, owned backlog of dependencies you can eliminate or formally accept before they become the tenant’s easiest bypass path.

Related resources from NHI Mgmt Group

• How do you investigate AI agent sign-ins in Microsoft Entra Agent ID?
• How do you block risky sign-ins with Conditional Access in Microsoft Entra ID?
• How do you block sign-ins from specific countries with Conditional Access in Microsoft Entra ID?
• How do you block legacy authentication with Conditional Access in Microsoft Entra ID?