Legacy authentication: the quiet back door in older tenants

01 / 10

A door most tenants forgot was still open

Consider a fictional 25-person dental practice. The front-desk scanner emails patient intake forms straight to a staff inbox as a PDF, and the copier in the back has done the same with scanned charts since it was configured in 2016. Nobody has touched either setting since. That is legacy authentication in one sentence: an old sign-in method, set up once, working quietly for a decade.

Legacy authentication is not a specific product. It is a category: any sign-in where the client hands over a username and password directly, with no step in the exchange where a second factor gets requested. Whoever holds that password holds the account. No push notification, no code, no interruption.

The good news, checked against Microsoft's own documentation, is that most of that door is already welded shut in every Microsoft 365 tenant, whether anyone asked for it or not. The less good news is that one hinge is still moving, and it is worth knowing exactly which one before you assume you are covered.

02 / 10

Why a password alone is the whole story here

A modern sign-in can pause partway through and ask for a second factor: a push notification, a code, a security key. Legacy protocols predate that pattern. POP, IMAP, older Exchange ActiveSync, and the SMTP AUTH mechanism used for automated mail all authenticate in a single username-and-password exchange, with nowhere in it to insert an MFA prompt.

That is the entire reason this matters. Legacy authentication is not unusually broken for its era. It is that whatever multi-factor policy you have configured for interactive sign-in is never even consulted. An account reachable through one of these protocols is protected by its password and nothing else. (Whether your accounts actually have MFA registered, versus just enabled, is a separate and worthwhile question for another post.)

03 / 10

What Microsoft has already bricked up

Microsoft has been closing this down since 2021, in stages, without most admins doing anything. Its own retirement page is specific about the sequence: Beginning in early 2021, we started to disable Basic authentication for existing tenants with no reported usage, and beginning in early 2023, we disabled Basic authentication for all tenants who had any type of extension. The protocols covered are Exchange ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, the Offline Address Book, Autodiscover, and Basic-authenticated Outlook for Windows and Mac.

As of Microsoft's current guidance, the result is unconditional: Basic authentication is now disabled in all tenants. That is true whether you have ever built a Conditional Access policy, whether you use Security Defaults, or whether you have done nothing at all. You did not turn this off. Microsoft did, tenant by tenant, years ago.

One protocol was handled separately, on purpose: We also disabled SMTP AUTH in all tenants where it wasn't being used. If your tenant had SMTP AUTH switched on and actually sending mail, which describes a lot of scanners and copiers, it was left alone. That is the hinge.

04 / 10

The one door still on a hinge: SMTP AUTH

SMTP AUTH client submission is what a scanner, copier, or line-of-business application typically uses to hand a message to Exchange Online for delivery. It is not the protocol your everyday Outlook client uses to read mail. As of 30 September 2026, Microsoft's documentation still says: Although SMTP AUTH is currently available, Microsoft has announced plans to retire Basic authentication for SMTP AUTH in Exchange Online.

The timeline behind that sentence has moved more than once. An earlier plan would have started rejecting a share of SMTP AUTH Basic-auth traffic in March 2026, ramping to all of it by the end of April 2026. Microsoft delayed that. Per Microsoft's most recent update to its retirement timeline (last revised 27 January 2026), the current plan is: SMTP AUTH Basic authentication is set to be disabled by default for existing tenants at the end of December 2026; tenants created after that point are expected to use OAuth from day one; and a final, hard removal date is due to be announced in the second half of 2027.

None of those dates have arrived yet. If a scanner is still emailing PDFs today, it is very likely doing so through SMTP AUTH with Basic authentication, and it will keep working right up until Microsoft's default-disable date does its job, unless you act on it yourself first. You can, today, one mailbox at a time.

05 / 10

Turning the hinge yourself, one mailbox at a time

You do not have to wait for December 2026. Microsoft's own recommendation is direct: we highly recommend that you disable SMTP AUTH in your Exchange Online organization, and enable it only for the accounts (mailboxes) that still require it. That is an organization-wide default with named exceptions, not everything left open in case something needs it.

The mechanism is one property: Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled <$true|$false|$null>. $false enables SMTP AUTH for that mailbox, $true disables it, and $null lets the mailbox follow whatever the organization-wide setting is. For the dental practice, that means one mailbox, the shared inbox the scanner sends to, gets the exception, and every other mailbox inherits the organization-wide $true.

06 / 10

The protocol landscape, at a glance

Read the first two columns together. The third column is the one that is still moving.

07 / 10

Two backstops, if you have not touched Conditional Access

Turning off SMTP AUTH per mailbox handles one protocol. Blocking legacy authentication as a category is a policy decision, and Microsoft gives you two ways to make it, depending on what you are licensed for.

Without a license that includes Conditional Access, you are not stuck: customers without licenses that include Conditional Access can make use of security defaults to block legacy authentication, in Microsoft's own words. Security Defaults is blunter but immediate: after security defaults are enabled in your tenant, all authentication requests made by an older protocol will be blocked.

With Conditional Access, Microsoft publishes a ready-made template scoped to two client-app categories, Exchange ActiveSync clients and Other clients, and it is built to be turned on carefully: this policy is put in to Report-only mode to start so administrators can determine the impact they have on existing users. Report-only logs what the policy would have blocked without blocking anything yet. Our recommendation, not a Microsoft-stated requirement: run it that way for about a week before switching it to enforce, so a forgotten scanner does not go dark without warning.

08 / 10

Finding out what is actually using it, before you flip the switch

Two Microsoft tools answer the same question from different angles: what, in your tenant, is still signing in the old way.

• Sign-in logs, filtered by Client app. Microsoft's Graph API defines the field precisely: legacy authentication clients include Exchange ActiveSync, IMAP, MAPI, SMTP, POP, and other clients. Filter on any of those and you see every legacy sign-in, one at a time, with the account and app behind it.
• The Sign-ins using legacy authentication workbook, built for exactly this decision. Microsoft frames its job as a question, how you can determine whether it's safe to turn off legacy authentication in your tenant, and says the workbook lets you see all legacy authentication sign-ins in your environment, so you can migrate a workflow before you cut it off rather than after. Microsoft lists a Premium P1 license and a Log Analytics workspace as prerequisites.
• Find it in the Microsoft Entra admin center, under Entra ID, then Monitoring and health, then Workbooks.
• Give it real time before you conclude anything. A scanner that only emails twice a week will not show up in a one-day sample.

09 / 10

Back at the dental practice

The front-desk scanner is almost certainly using SMTP AUTH with Basic authentication for the one shared mailbox it is configured to log into. The 2016 copier is a better candidate for something already blocked: if it once used Exchange ActiveSync or an old Outlook connection to drop scans into a mailbox, that stopped working years ago whether anyone noticed or not, and it has presumably been reconfigured onto something newer since, or it would not still be delivering scans today.

The office manager's actual to-do list is short. Open the legacy-authentication workbook and see what is really signing in. If the scanner's mailbox needs SMTP AUTH, leave SmtpClientAuthenticationDisabled set to $false for that one mailbox and $true everywhere else. Then turn on the Conditional Access block-legacy-authentication template in report-only mode for a week, and see what else would have broken before enforcing it.

10 / 10

Where to start

Before you touch a policy, open the Sign-ins using legacy authentication workbook, or, without the Premium P1 license it requires, filter the Entra sign-in logs by Client app, and spend fifteen minutes reading what is actually signing in today. You will either find nothing, in which case blocking legacy authentication costs you nothing, or you will find exactly which mailbox and which device needs the one exception, which is a much smaller problem than blocking blind.

Disclosure: this is a category we sell into. Avalon CloudSec includes Conditional Access policy analysis and sign-in visibility as part of its read-only Microsoft 365 monitoring, so a gap like an unblocked legacy-authentication path shows up on the same dashboard as the rest of your posture, rather than requiring a separate workbook visit. It cannot turn a policy on for you: every Graph permission it holds is a read permission, so the report-only rollout and the enforcement step both stay with your admin, in Microsoft's own screens. If that trade, visibility without write access, is useful to you, email support@awservices.org.

Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft.