Block legacy authentication by creating a Conditional Access policy that targets legacy client protocols and denies access for all users except tightly controlled exceptions. Start in report-only mode, then enforce after checking which mail and sign-in clients still use basic or older protocols. Review sign-in logs for repeated legacy authentication attempts.
What legacy authentication means in Entra ID
Legacy authentication is the older protocol family that cannot handle modern controls well, so it is the main gap Conditional Access is meant to close here. In practice, you are not blocking a single app, you are blocking protocol paths such as basic authentication flows that bypass stronger sign-in requirements and make it harder to rely on modern MFA or device signals.
The policy works best when you treat it as an access boundary, not as a one-time checkbox. A clean design starts with a broad deny posture, then narrows only where a real business dependency still exists, such as a device, scanner, or mailbox client that has not been modernised yet. That is why report-only testing matters before enforcement.
How to structure the Conditional Access policy
Target the policy at legacy client protocols and make the default action deny access for users, with explicit exceptions only where you can justify the exception and track its retirement. The practical goal is to eliminate protocol-driven sign-ins, not merely reduce them.
Use report-only mode first so you can see which sign-ins would be blocked without interrupting production mail flow. Then review the affected clients, users, and apps to separate true dependencies from stale configurations, old mobile mail clients, service processes, or forgotten authentication methods. If you need an exception, keep it narrow and time-bound.
For a broader identity baseline around sign-in controls, the Conditional Access Guide is the best starting point for policy design, report-only testing, and gap analysis. For the surrounding identity posture, the Microsoft 365 Security Guide shows how Entra sign-in controls fit into a wider hardening programme.
How to find and remove the clients still using legacy auth
Sign-in logs are the operational proof point. Look for repeated legacy authentication attempts, identify the mail and sign-in clients involved, and map them to the user or workload that still depends on them. If the same client keeps appearing, treat it as a remediation priority rather than an isolated event.
This is often where older mail protocols, embedded device credentials, or outdated third-party integrations surface. The safest response is to move each dependency to a modern auth method or retire it. If the client cannot be modernised quickly, isolate it behind a narrowly scoped exception and set a deadline for removal.
Legacy protocol abuse is not theoretical. The Microsoft Midnight Blizzard breach is a reminder that weak or legacy account paths can become an entry point when stronger sign-in controls are missing. The Top 10 MFA Mistakes resource also helps when you need to understand how legacy protocol gaps undermine the protection you think MFA is providing.
Risk and Threat Considerations
Legacy authentication is attractive because it often sidesteps modern sign-in protections, making password spraying, credential stuffing, and basic-auth replay more effective than they would be against modern flows. If an attacker gets valid credentials, the lack of stronger protocol controls can turn one mailbox or app into a wider foothold.
Failure mechanism: Basic or older protocols allow sign-ins that do not enforce the same control stack as modern authentication, so compromised passwords, stale app credentials, or forgotten clients can continue authenticating after stronger controls are enabled elsewhere.
Impact: The result can be mailbox compromise, tokenless account abuse, persistence through old clients, and a much larger remediation burden because the organisation has to chase both credentials and every protocol path that still accepts them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Legacy auth blocking protects organizational sign-ins from weak authentication paths. |
| IA-5 — Authenticator Management | Legacy auth often persists through stale passwords and long-lived credentials. | |
| Recommendation — Require modern user authentication and disable legacy protocol-based access. Rotate or retire credentials that still work through blocked legacy protocols. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Conditional Access is an access control gate for legacy protocol sign-ins. |
| Recommendation — Enforce deny-by-default access rules and remove unnecessary legacy exceptions. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The topic is directly about restricting sign-in methods and access paths. |
| DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Sign-in logs are used to detect remaining legacy authentication attempts. | |
| Recommendation — Apply access control policies that block weak authentication pathways. Monitor sign-in telemetry for blocked legacy-auth attempts and residual clients. | ||
Practitioner Guidance
What to verify: Confirm that every exception is tied to a named business dependency, an owner, and a retirement date. If you cannot explain why a legacy protocol still exists, it should not remain exempt.
Decision rule: If the client can use modern authentication, block legacy auth now; if it cannot, treat it as technical debt with a short-lived exception and monitor it closely until it is removed.
What good looks like: Legacy sign-ins fall to zero or near zero, report-only findings stop revealing new dependencies, and the remaining exceptions are deliberate, documented, and rare.
Practitioner takeaway: The real control is not the Conditional Access policy alone, it is the combination of deny-by-default enforcement, exception discipline, and log-driven cleanup of every remaining legacy client.
Related resources from NHI Mgmt Group
- How do you block device code flow with Conditional Access in Microsoft Entra ID?
- How do you require compliant devices with Conditional Access in Microsoft Entra ID?
- How do you apply Conditional Access policies to AI agents in Microsoft Entra?
- How do you secure AI agent identities with Microsoft Entra Conditional Access?