Exchange Online Basic Auth Deprecation: What's Still at Risk
Key takeaway: Basic authentication is already disabled in Exchange Online for the major client protocols. The remaining planning item is SMTP AUTH with basic credentials, still found in printers, scanners, and application relays. Microsoft has updated the SMTP AUTH retirement timeline, so do not rely on older milestone dates without checking the current Exchange Team announcement.
In This Article
What Already Happened (October 2022)
Microsoft's Exchange Online documentation now states plainly that Basic authentication is disabled in all tenants and cannot be re-enabled by admins or Microsoft support. The affected protocol set includes:
- Exchange ActiveSync (EAS)
- POP3 and IMAP4
- Exchange Web Services (EWS)
- Remote PowerShell (RPS)
- Offline Address Book (OAB)
- MAPI over HTTP (the protocol Outlook for Windows and Mac use to connect to Exchange Online)
- Autodiscover (disabled as a sequenced follow-on after EAS and EWS were already disabled in a given tenant, described in the same October 2022 announcement)
The practical result is the same for administrators: there is no supported path to turn Basic authentication back on for these protocols. Modern authentication, the Exchange Online PowerShell module, Microsoft Graph, or another supported path is required.
Note on Outlook versions: Outlook 2016 and later for Windows support modern authentication by default. Outlook 2013 requires a registry key to enable it. Outlook 2007 and 2010 cannot use modern authentication and cannot connect to Exchange Online at all as of October 2022.
The Remaining Risk: SMTP AUTH
SMTP AUTH, the protocol used on TCP port 587 to submit outbound mail with a username and password, was not included in the October 2022 cutoff. Microsoft kept it available to avoid breaking mail submission workflows that were harder to migrate: printers, scanners, line-of-business applications, monitoring systems, and automated scripts.
That window is now closing. Microsoft announced the following timeline for SMTP AUTH basic credential retirement:
- Oct 2022 Major Basic auth retirement. Microsoft began disabling Basic authentication for the affected Exchange Online client protocols. SMTP AUTH was treated separately.
- Oct–Dec 2022 Autodiscover sequencing. Autodiscover basic authentication was disabled as a follow-on to EAS and EWS, Microsoft described this sequencing in the same basic auth deprecation announcement rather than as a separate cutoff event.
- Early 2023 Extensions ended. Microsoft Learn says Basic authentication was disabled for tenants that had received extensions, and SMTP AUTH was disabled in tenants where it was not being used.
- 2025–2026 SMTP AUTH timeline updated. Microsoft updated the Exchange Online SMTP AUTH Basic Authentication deprecation timeline. The current retirement date is in the Exchange Team blog post linked from the Microsoft Learn basic auth deprecation article, check that post directly rather than relying on third-party date summaries, which reflect earlier milestones.
- Current state Audit and migrate now. Microsoft Learn still documents SMTP AUTH as available, recommends OAuth where supported, and points admins to the updated Exchange Team post for the current SMTP AUTH Basic authentication milestones.
Do not plan from copied timeline fragments. The safe operating assumption is simpler: inventory every mailbox or device still using SMTP AUTH with a password, then migrate it to HVE, Azure Communication Services Email, Microsoft Graph, SMTP AUTH with OAuth, an on-premises relay, or an Exchange Online SMTP relay connector depending on the use case.
Who Is Exposed
The organizations most at risk are those with devices or systems that cannot be updated to use OAuth. The typical offenders:
- Network printers and multifunction devices (MFDs): Scan-to-email features on copiers and laser printers almost always use SMTP AUTH with a service account username and password. Firmware rarely supports OAuth, and vendor update cycles are slow.
- Monitoring and alerting systems: On-premises network monitoring tools, backup software, and server alert mailers often have hardcoded SMTP relay settings using Exchange Online credentials.
- Line-of-business applications: ERP systems, ticketing tools, and internally developed apps that send transactional email through Exchange Online using basic SMTP.
- PowerShell and batch scripts: Automated reports or notifications built with
Send-MailMessageor similar cmdlets using plaintext credentials. - Shared mailbox relay accounts: Service accounts created for application mail submission that were never migrated to app registrations with OAuth.
What is not at risk: Outlook, mobile email clients, Teams, SharePoint notifications, and any application already using OAuth 2.0 or the Microsoft Graph API for mail. These were addressed in the 2022 cutoff or never used basic auth to begin with.
How to Audit Your Tenant
Before you can migrate, you need an accurate inventory of what is still using SMTP AUTH with basic credentials.
1. Microsoft Entra Sign-In Logs
In the Microsoft Entra admin center, navigate to Identity > Monitoring & health > Sign-in logs. Filter by Client app = Legacy Authentication Clients and look for entries where the resource is Exchange Online. The user principal name on each entry will identify which service accounts or mailboxes are still being authenticated with basic credentials.
2. Exchange Admin Center Reports
In the Exchange admin center, go to Reports > Mail flow > SMTP AUTH clients report. This report shows which sender addresses have submitted mail via SMTP AUTH in the last 90 days, along with the TLS version and authentication type.
3. PowerShell
You can query current authentication policy settings and SMTP client activity via the Exchange Online PowerShell module:
# Check tenant-level SMTP AUTH setting
Get-TransportConfig | Select SmtpClientAuthenticationDisabled
# Check per-mailbox SMTP AUTH overrides
Get-CASMailbox -ResultSize Unlimited | Where {$_.SmtpClientAuthenticationDisabled -eq $false} | Select Name, PrimarySmtpAddressAny mailbox returned by the second command has SMTP AUTH explicitly enabled at the mailbox level, these are your highest-priority items to migrate.
Migration Paths
Microsoft documents several supported send paths for devices and applications. The right choice depends on whether the device must reach external recipients, whether it can support OAuth, and whether it is hosted on-premises or in the cloud.
Option 1: High Volume Email for Microsoft 365 (best fit for internal device and application mail)
For printers, scanners, monitoring systems, and applications that send mail to internal recipients only, High Volume Email (HVE) is the cleanest Microsoft 365-native replacement for SMTP AUTH. Microsoft describes HVE as designed for automated, transactional, operational, application, and device-generated email. It uses dedicated HVE accounts, no M365 user license is required for HVE accounts.
HVE connects on port 587 with TLS to smtp.hve.mx.microsoft (note: the older smtp-hve.office365.com endpoint will be deprecated, use the current endpoint for new deployments). Authentication uses HVE account credentials or an OAuth token; use OAuth where possible. Billing is consumption-based at approximately $42 per million delivered recipients, charged through Microsoft 365 pay-as-you-go billing.
Key constraint: HVE cannot deliver to external recipients (addresses outside your tenant). It also enforces a 50-recipient limit per message, for sends to large internal distribution lists, address the list rather than individual recipients. If the device or application must reach external addresses, use Option 2 (ACS Email), Option 3 (SMTP AUTH with OAuth), or Option 4 (SMTP relay connector) instead.
Option 2: Azure Communication Services Email (best fit for apps that must send externally)
For applications that need to reach external recipients, Microsoft Learn points to Azure Communication Services (ACS) Email as an alternative to SMTP AUTH with Basic authentication. ACS Email is provisioned as an Azure resource with its own verified sending domains, it is not tied to Exchange Online mailbox limits and can deliver to any recipient address.
Option 3: SMTP AUTH with OAuth 2.0
Applications that can be updated can continue using SMTP AUTH on port 587 with OAuth instead of a password. This preserves the SMTP protocol while removing the Basic authentication dependency. It is a reasonable path for code you control, updated vendor applications, and automation that can obtain OAuth tokens reliably.
Option 4: SMTP Relay via Mail flow > Connectors
SMTP relay is still supported for specific environments, especially when the device or app has a static public IP address or certificate and must send as an accepted domain. Configure it in the Exchange admin center under Mail flow > Connectors by creating an inbound connector. This is not a “Send Connectors” page in Exchange Online; that wording belongs to on-premises Exchange terminology.
SMTP relay uses the tenant MX endpoint on port 25, does not require a cloud mailbox, and can send to internal and external recipients. It is not appropriate for third-party hosted apps such as Azure-hosted workloads, and misconfiguration can create deliverability or spoofing problems.
Option 5: Microsoft Graph API
For applications with development resources, Microsoft Graph sendMail is the most future-proof modernization path. It uses modern authentication and avoids SMTP entirely. This is usually the right answer for new development and for custom line-of-business systems that are already being refactored.
| Use case | Recommended path | Key limit / note |
|---|---|---|
| Printers / MFDs / scanners sending to internal recipients only | High Volume Email (HVE) | Internal recipients only; 50 recipients per message max; ~$42/million via M365 pay-as-you-go |
| Apps that need to reach external recipients | Azure Communication Services Email or Graph API | ACS Email: Azure resource, own verified domains; Graph API: most future-proof for dev teams |
| Updated apps or scripts that must keep SMTP | SMTP AUTH with OAuth | Requires OAuth-capable client/code |
| Static-IP on-premises devices or relay hosts | Exchange Online SMTP relay connector | Configure in EAC under Mail flow > Connectors; port 25; SPF matters |
| Legacy devices behind on-premises Exchange or SMTP relay | Authenticated or anonymous relay to an on-premises mail server | Must be locked down carefully; never create an open relay |
Blocking Legacy Auth via Conditional Access
Once you have completed your SMTP AUTH migration, block legacy authentication at the Entra ID level so it cannot be re-introduced. This is a single Conditional Access policy:
- Users: All users
- Cloud apps: Office 365 Exchange Online
- Conditions > Client apps: Select all legacy authentication client types (Exchange ActiveSync, Other clients)
- Grant: Block access
A critical point: you cannot add MFA to legacy authentication. The basic auth protocol has no mechanism to trigger or handle an MFA challenge, it sends credentials and expects a binary accept or reject. The only safe control for legacy auth is a hard block. Any policy that says "allow but require MFA" for legacy auth clients will not actually enforce MFA; the MFA condition will be skipped.
Before enabling the block policy: Run it in Report-Only mode for at least one week to identify any remaining dependencies your audit missed. Check the Entra sign-in logs for blocked events and remediate them before switching to Enabled.
Frequently Asked Questions
Is Exchange Online basic auth deprecation finished?
For the affected Exchange Online protocol set, yes. Microsoft Learn now states that Basic authentication is disabled in all tenants and cannot be re-enabled by admins or Microsoft support. SMTP AUTH is the separate remaining item to audit because its Basic authentication retirement follows a separate, updated timeline.
What devices are most at risk from the SMTP AUTH deadline?
Network-connected printers, multifunction devices (MFDs), copiers with scan-to-email, monitoring tools, and older line-of-business applications that send alerts or notifications via SMTP. For devices sending to internal recipients only, HVE is usually the cleanest path. If the device must reach external addresses (customers, vendors), use SMTP AUTH with OAuth, an Exchange Online SMTP relay connector, ACS Email, or Microsoft Graph instead, HVE cannot deliver outside the tenant.
Can I keep using SMTP AUTH with Basic credentials?
Do not build a plan around it. Microsoft has updated the SMTP AUTH Basic authentication deprecation timeline since the original October 2022 announcement. The current retirement date is in the Exchange Team blog post linked from Microsoft Learn's basic auth deprecation article, check that post for the active milestone rather than any third-party summary, including this one.
How do I find which accounts are still using basic auth in my tenant?
Use the Microsoft Entra admin center Sign-in logs filtered for Legacy Authentication Clients, or run the SMTP AUTH clients report in the Exchange admin center (Reports > Mail flow). PowerShell: Get-CASMailbox -ResultSize Unlimited | Where {$_.SmtpClientAuthenticationDisabled -eq $false} returns mailboxes with SMTP AUTH explicitly enabled.
Can I add MFA to a service account that uses SMTP AUTH with basic credentials?
No. Multi-factor authentication is fundamentally incompatible with basic authentication, the protocol has no mechanism to present or respond to an MFA challenge. The correct control is a Conditional Access policy that blocks legacy auth entirely. Attempting to "enforce MFA on legacy auth" in Conditional Access will not actually trigger MFA; the challenge will simply not be issued to the legacy client.
Does this affect hybrid Exchange environments?
Hybrid mail flow between Exchange on-premises and Exchange Online uses dedicated connectors and does not rely on SMTP AUTH with Basic credentials. The SMTP AUTH issue is separate: any device or application that submits mail through Exchange Online using a cloud mailbox username and password needs to move to HVE, OAuth, ACS Email, Graph, an on-premises relay, or an Exchange Online SMTP relay connector.
Sources Checked
This article was revised on September 17, 2026 against current Microsoft documentation, including Microsoft's Exchange Online Basic authentication deprecation article, Microsoft's multifunction device/application mail setup guidance, and Microsoft's High Volume Email documentation. Where Microsoft says the SMTP AUTH timeline has been updated, this article avoids repeating older milestone dates as current facts.