In This Article
- What actually changes at the end of December 2026
- What in your institution still sends mail this way
- How to find every dependency before it breaks
- Four ways to keep the mail flowing
- Why Microsoft is doing this at all
- Closing the protocol so it cannot drift back open
- Who owns the scanner in December
- Frequently Asked Questions
Somewhere in your institution there is a device nobody thinks about. A branch scanner that emails signed disclosures to the processing team. A loan origination system that fires status notifications overnight. A reporting server that drops a nightly balance file into three inboxes. None of it is on anyone's project list, because none of it has failed in a decade.
All of it authenticates to Microsoft 365 with a username and a password, over a protocol called SMTP AUTH. At the end of December 2026, Microsoft changes the default for that protocol, and a good number of those quiet senders stop working on a Tuesday morning with no warning and no obvious owner.
This is the last one. Basic authentication has already been switched off permanently for every other Exchange Online protocol. SMTP AUTH is the only survivor, and it is now on the clock. The good news is that this particular deadline is softer than most of the coverage suggests, and the work it creates is finite and easy to scope if you start from an inventory rather than from a switch.
The distinction that matters
December 2026 is a default change, not a removal. Microsoft turns SMTP AUTH basic authentication off by default for existing tenants, and administrators can still turn it back on. That is very different from what already happened to POP, IMAP, and the other legacy protocols, where the door was closed permanently and nobody, including Microsoft support, can reopen it. Treat December as the date your untracked dependencies surface, not the date your mail dies.
What actually changes at the end of December 2026
Microsoft's Exchange team published the current timeline on January 27, 2026, replacing the schedule it had announced earlier. Four milestones, and the wording of each one carries weight.
Two things follow from reading that carefully. First, an institution that hits December unprepared has an escape hatch, and it is a legitimate one: an administrator can re-enable SMTP AUTH basic authentication while the real remediation gets scheduled. Second, that escape hatch has an expiry nobody has published yet. Planning against it is planning against a date Microsoft has not told you.
If you were briefed on this in 2025, your date is wrong
Microsoft superseded its earlier schedules for this deprecation. A September 2025 permanent removal, a March 1, 2026 start of partial rejections, and an April 30, 2026 hundred percent rejection were all announced and then replaced by the January 2026 update. Those older dates are still sitting on vendor pages, university IT bulletins, and MSP newsletters that were never revised.
If someone handed your team a remediation plan built around April 2026, the plan is not wrong about the work. It is wrong about the clock, and it was probably shelved when the date passed without incident. Pull it back out.
Want the dependency list before December?
This discovery runs inside the Microsoft 365 tenants ABT already administers, and the same pass feeds a broader read on tenant posture.
What in your institution still sends mail this way
Microsoft's own documentation names the categories, and they map almost perfectly onto a community bank or a mortgage operation. Network-connected scanners that send scanned documents as attachments. Line-of-business applications that need to send email. POP3 and IMAP4 clients, which can only receive, and therefore need authenticated SMTP in order to send.
Translated into what actually sits in a branch or a back office:
- Multifunction printers and scanners that email documents to a shared mailbox or straight to a borrower
- The loan origination system's notification and status email, especially anything self-hosted
- Core banking and servicing platform alerting, nightly batch reports, and exception notices
- Ticketing, facilities, and building access systems that email on an event
- Fax gateways and document capture appliances
- Scheduled scripts and reporting servers that someone wrote years ago and left running
- Legacy on-premises applications that were never in scope for the last modernization pass
The pattern worth noticing is that almost none of these belong to a person. They belong to a process. When a user's mail breaks, the user calls the help desk within the hour. When a scanner stops emailing disclosures, the failure shows up days later as a file that never made it into the loan folder, and it gets diagnosed as a workflow problem rather than an authentication problem.
That delay is the actual operational risk here, and it is the reason discovery comes before configuration.
How to find every dependency before it breaks
You cannot remediate an inventory you do not have, and this is one of the rare cases where the inventory is genuinely available rather than something you have to reconstruct by asking around. Microsoft gives you two views, and they answer different questions.
Start in the Microsoft Entra admin center. Go to Monitoring and health, then Sign-in logs. Add the Client App column if it is not already shown, then filter on the legacy authentication protocols. Do this on the interactive sign-ins tab, and then do it again on the user sign-ins (non-interactive) tab. That second pass is the one people skip, and it is where unattended devices and service accounts live. Microsoft also publishes a "Sign-ins using legacy authentication" workbook that presents the same data without the manual filtering.
Then check the Exchange admin center. Microsoft has pointed administrators to an SMTP AUTH clients submission report under Reports, then Mail flow, as the practical first step for identifying which clients are still submitting with basic authentication. Between that report and the Entra sign-in logs you get both halves of the picture: which mailboxes are being used to submit, and which client applications are doing the submitting.
Three things to write down for every hit, because you will need all three at the remediation step:
One practical caveat about the discovery itself: the sign-in logs answer the question only for the window they retain. A device that submits monthly, or quarterly at a reporting boundary, can sit entirely outside a thirty-day look-back and never appear. In the tenants ABT manages this runs as a standing pass rather than a one-time project, for exactly that reason. Across an institution with more than one entity, or a tenant inherited through a merger, that is where a Tier 1 Cloud Solution Provider relationship stops being a licensing arrangement and starts being an operational one: the discovery, the change window, and the rollback all happen inside the tenant we already administer.
If you would rather not run the discovery by hand, our SMTP AUTH sender count walks through the same report and we will run it with you and hand back the sender list.
If your institution has run a Conditional Access hardening pass, some of this work is already done. The same legacy authentication signal drives both efforts, and our walkthrough of Conditional Access policies for financial institutions covers the policy side of blocking these protocols once the dependencies are cleared.
Four ways to keep the mail flowing
Here is the reframe that saves most of the panic, and it is the single most commonly misunderstood point about this deprecation: migrating off basic authentication does not mean abandoning SMTP AUTH. Microsoft shipped OAuth 2.0 support for POP, IMAP, and SMTP AUTH back in 2020. A device or application that can speak OAuth keeps using the same protocol, on the same port, to the same endpoint. Only the credential changes.
That reframe collapses a scary protocol migration into a much smaller question asked device by device: can this thing do OAuth, and if not, what else can it do?
Four paths cover almost every device in a financial institution. Microsoft documents others for narrower cases, so treat this as the shortlist rather than the complete catalogue, and check the current guidance for anything unusual.
| Path | How it authenticates | External recipients | Best fit |
|---|---|---|---|
| SMTP AUTH with OAuth | OAuth 2.0 token. Microsoft documents a client credentials flow for SMTP using the SMTP.SendAsApp application permission, so an unattended device need not authenticate as a user |
Yes | Anything whose vendor has shipped OAuth support. Always check this first, because it is the smallest change |
| SMTP relay | Authenticated by an inbound connector, typically tied to a static public IP address or a certificate, rather than a mailbox credential | Yes | Older devices that cannot do OAuth but sit behind a known static IP address |
| Direct Send | Unauthenticated submission straight to your Microsoft 365 MX endpoint | No, internal recipients only | Internal-only notifications. Read the caveat below before choosing this |
| Microsoft Graph | OAuth 2.0 against the Graph API, no SMTP at all | Yes | In-house applications and scripts you control the code for |
Direct Send earns a specific warning because it is the path teams reach for when a device cannot do OAuth and there is no time left. It is genuinely unauthenticated: the sending device presents nothing. SPF is a published statement about which hosts may send for your domain, which is a different thing from authenticating the device, and the two get conflated constantly. Microsoft intends Direct Send for delivery to recipients inside your own organization. If the scanner in question emails closing documents to a borrower or a title company, Direct Send is not the answer, and discovering that in January is worse than discovering it now.
On the OAuth path, the detail worth knowing before you ask a vendor about it is that Microsoft supports a client credentials grant flow for SMTP, POP and IMAP. On that page Microsoft names the SMTP application permission as SMTP.SendAsApp, has a tenant admin register the application's service principal in Exchange, and grants access one mailbox at a time. That is the difference between an unattended device holding a service account password and an unattended device holding a scoped application permission, and it is the right question to put to the vendor of any device you are told cannot be migrated.
Sequencing is where these migrations succeed or fail, and delegated administration changes what sequencing is available. Because basic authentication keeps working until the end of December 2026, every device can be moved to its new path and watched through a full business cycle with the original credential still live behind it. That matters most for the senders that only fire monthly or at a quarter boundary, which are precisely the ones a single verification test will not exercise. In the tenants we administer, the old credential stays in place until the replacement has survived a real cycle, and the mailbox is only reassessed for closure once nothing on it still submits over SMTP AUTH.
Why Microsoft is doing this at all
The case for retiring basic authentication is not subtle, and Microsoft states it plainly in its own guidance on blocking legacy authentication.
Those are Microsoft's aggregate figures for legacy authentication as a whole, not a measurement of SMTP AUTH specifically. What they establish is the shape of the problem: attackers concentrate on the authentication paths where a username and a password are sufficient on their own. Microsoft's own stated reasoning is more carefully hedged than the way most people repeat it. Microsoft writes that the enforcement of multifactor authentication is not simple, and in some cases not possible, when basic authentication remains enabled. That is a claim about the difficulty of enforcing MFA at all while a password-only path exists, which for an institution that has already invested in phishing-resistant MFA is the argument that lands.
One nuance that catches remediation plans
Microsoft states that calls made by service principals are not blocked by Conditional Access policies scoped to users. If your plan is to block legacy authentication with a Conditional Access policy targeting all users and consider the matter closed, workload identities need to be handled separately through Conditional Access for workload identities. This is a common gap in otherwise careful plans, and it is easy to close once you know it is there. We covered a related mismatch between the policy layer and the protocol layer in the Conditional Access password spray gap.
Closing the protocol so it cannot drift back open
Once every dependency on a mailbox has been dealt with, the last question is whether that mailbox still needs SMTP client submission at all. Two outcomes are possible here, and conflating them is the most common mistake at this stage.
If the device moved to OAuth-based SMTP AUTH, the protocol stays on for that mailbox. What you retired is basic authentication, not SMTP AUTH. Closing the protocol here would break the device you just migrated. An Exchange authentication policy is the control that targets basic authentication for SMTP specifically, and it is the right instrument when the mailbox still submits.
If the device was retired, or moved to SMTP relay, Direct Send, or Microsoft Graph, nothing on that mailbox submits over SMTP AUTH any more, and the protocol can be closed for it. Confirm first that no other device shares the mailbox. Shared service mailboxes are common, which is why the discovery step asks you to record the mailbox rather than only the device.
Microsoft's stated recommendation for the mailboxes that no longer need it is to disable SMTP AUTH across the organization and enable it only for the accounts that still require it. Two settings do the work: an organization-wide switch, and a per-mailbox setting that overrides it. Microsoft is explicit that the mailbox setting takes precedence over the organization setting, which is what makes the exception model work. Turn it off everywhere, then turn it back on for the mailboxes that genuinely still submit, including the ones now submitting with OAuth, and keep that list short enough to review.
Know what these switches actually control
The SmtpClientAuthenticationDisabled settings govern the SMTP AUTH protocol for a mailbox or a tenant. They are not a filter that disables basic authentication while leaving OAuth-based SMTP AUTH working. Disabling SMTP AUTH this way stops SMTP client submission for that scope regardless of which authentication method the client was using.
Two consequences follow. Running it against a mailbox whose device has not been moved yet breaks that device immediately rather than in December. And running it against a mailbox that now submits with OAuth breaks that device too, because the switch does not care which credential was used. Close the protocol only where nothing on the mailbox submits over SMTP AUTH any more.
The commands, for the change window rather than for exploration:
- Disable organization-wide:
Set-TransportConfig -SmtpClientAuthenticationDisabled $true - Confirm it applied:
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled - Grant an exception for one mailbox:
Set-CASMailbox -Identity <MailboxIdentity> -SmtpClientAuthenticationDisabled $false - Return a mailbox to the organization default:
Set-CASMailbox -Identity <MailboxIdentity> -SmtpClientAuthenticationDisabled $null
The commands are the smallest part of this. The work is knowing which mailboxes can take them without breaking a process nobody has documented, holding the change to a window the business has agreed to, and keeping the exception list short enough that somebody will actually review it a year from now.
One more thing to check before you plan any of this: if security defaults is enabled in your tenant, Microsoft states that SMTP AUTH is already disabled. Tenants that turned security defaults on years ago and never revisited it may find this entire exercise is a documentation task rather than a configuration one. Confirm before you schedule work.
Who owns the scanner in December
Go back to the device in the first paragraph. The reason it is a risk is not that basic authentication is insecure, although it is. The reason it is a risk is that it has no owner. It was configured once by somebody who has since changed roles, it authenticates as a mailbox that appears on no application inventory, and the business unit that depends on its output does not know it exists as a separate thing from the workflow it feeds.
That is the part this deadline actually tests. The configuration work is a few hours. The exception list is where it goes wrong, because an exception without a stated reason and a named owner becomes permanent by default, and a year from now nobody can tell whether the mailbox with SMTP AUTH still enabled is a live dependency or a leftover. We described the same failure pattern in Conditional Access exclusions and the list nobody reviews, and it is the same institutional habit both times.
Three questions are worth answering in writing before December, and they outlast this particular deprecation:
- Which mailboxes are permitted to submit mail, and who approved each one? This is the artifact an examiner or an auditor will ask for, and it is far easier to write now than to reconstruct later.
- What is the review cadence for that list, and whose calendar is it on? A list nobody owns is a list that only grows.
- When a device is replaced, who closes the protocol behind it? Decommissioning is where the drift comes back.
For the institutions ABT manages, those answers are ours to maintain rather than a project handed back at the end of an engagement. That is the difference between a remediation and an operating practice: the scanner that had no obvious owner in paragraph two has one, the exception it needs is recorded with a reason and a review date, and the protocol closes behind it once nothing else on that mailbox still submits.
Find out what is still submitting with basic authentication in your tenant
ABT manages Microsoft 365 for more than 750 banks, credit unions, and mortgage companies. We run the discovery, map every device and application to a supported sending path, test the replacement while the old credential is still live, close the protocol only on the mailboxes that no longer need it, and keep the exception list with a reason and a review date against every entry. The same discovery pass is one input into a broader read on your tenant's posture, which is what the security grade summarizes.
Frequently Asked Questions
Normal user email is unaffected. Outlook, Outlook on the web, and mobile mail apps do not use SMTP AUTH to send. What is affected is device and application email: scanners, line-of-business applications, reporting servers, and scripts that authenticate with a username and password to submit mail. At the end of December 2026 Microsoft disables SMTP AUTH basic authentication by default for existing tenants, and administrators can still enable it if needed.
No, and the difference matters. Basic authentication was already removed permanently for Exchange ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, the Offline Address Book, Autodiscover, and the Outlook desktop clients. Microsoft states that no one, including Microsoft support, can re-enable it for those protocols. SMTP AUTH was the exception, and December 2026 changes its default rather than removing it.
No. Microsoft released OAuth 2.0 support for POP, IMAP, and SMTP AUTH in 2020, so a device or application that supports OAuth can keep using SMTP AUTH with a token instead of a password. SMTP AUTH also supports application-only OAuth scenarios, which means an unattended device does not have to authenticate as a user. Moving off basic authentication and moving off SMTP AUTH are two different projects, and most institutions only need the first one.
Use two sources together. In the Microsoft Entra admin center, go to Monitoring and health, then Sign-in logs, add the Client App column, and filter on the legacy authentication protocols, checking both the interactive tab and the non-interactive user sign-ins tab. Microsoft also provides a Sign-ins using legacy authentication workbook. In the Exchange admin center, Microsoft points administrators to an SMTP AUTH clients submission report under Reports and Mail flow. One caveat either way: the logs only cover the window they retain, so a device that submits monthly can fall outside a short look-back. That is why ABT treats it as a repeating pass on the tenants it administers rather than a single check.
Only for internal recipients. Direct Send is unauthenticated submission to your Microsoft 365 MX endpoint, and Microsoft intends it for delivery to recipients inside your own organization. If the device emails borrowers, title companies, or any external party, Direct Send is not a supported answer. SMTP relay through an inbound connector is usually the better fallback for older devices, because it authenticates the connection rather than the device.
Microsoft has not published one. Its stated plan is to announce the final removal date in the second half of 2027. The announcement is what is scheduled, not the removal itself. Planning to rely on the administrator re-enable option past December 2026 therefore means planning against a deadline that has not been set yet, which is the case for tracking the timeline continuously rather than revisiting it once a year. For the institutions ABT manages, watching that timeline is part of the service rather than something handed back to the customer.
