Microsoft retiring Basic Auth in Exchange — the migration pain is real
Microsoft enforced Basic Authentication deprecation in Exchange Online in October 2022. The pain for unprepared organisations was real. Here's what the migration actually looked like.
Microsoft announced the deprecation of Basic Authentication in Exchange Online back in 2021, gave organisations extensive notice, delayed the enforcement date multiple times, and then finally enforced it on October 1st, 2022. Despite all of that runway, a lot of organisations were still caught out.
I spent a significant portion of September and October helping customers scramble to get compliant. Here's why it was painful and what actually needed to happen.
What Basic Authentication actually is (and why it's a problem)
Basic Authentication in the context of Exchange Online means clients sending a username and password directly with each API request: no tokens, no multi-factor authentication, just credentials in a header. It's the authentication mechanism that older email clients, some line-of-business applications, and a lot of scripted integrations relied on.
The security problem is straightforward: Basic Auth credentials can be captured in network traffic, are vulnerable to password spray attacks and, crucially, bypass MFA completely. You could have MFA enforced for interactive logins and still have Basic Auth connections that completely circumvent it. Microsoft's telemetry showed these connections being exploited regularly.
So deprecating it was right. The challenge was how many things relied on it.
What people were still running on Basic Auth
The sources of pain varied, but the most common were:
Legacy email clients: Older versions of Outlook, iOS Mail configured with Exchange credentials (rather than Modern Auth), and third-party email clients that hadn't been updated.
Printer/scanner email: The copier in the corner that sends scanned documents to email using an Exchange mailbox and SMTP basic auth. This is ubiquitous in SMBs. The fix is usually using Azure AD app passwords, or switching to direct SMTP relay, but it requires identifying every device.
Line-of-business applications: Any application that was sending email via Exchange, or connecting to Exchange data via EWS (Exchange Web Services) or MAPI, without having been updated to use Modern Auth.
Scripts and automation: PowerShell scripts connecting to Exchange Online with Get-Credential or stored plaintext credentials. These are everywhere in IT departments.
The challenge is that many of these weren't visible from the Microsoft 365 admin centre. You had to enable sign-in logging, export it, and look for Basic Auth connection events. For organisations that hadn't done this, October 1st was when they found out what they had.
The migration approach that actually works
The only sustainable approach I found was:
-
Turn on Azure AD sign-in logs and export 30 days of Basic Auth connection events. This tells you what's connecting and from where.
-
Classify what you find into: email clients (user action required), printer/scanner (device reconfiguration), LOB applications (vendor engagement or app password workaround), scripts (remediation).
-
Fix by category rather than trying to address everything at once. Email clients are the easiest: usually just reconfigure the account to use Modern Auth. Printers need the most field time. LOB apps need vendor involvement.
-
Use Conditional Access to block Basic Auth rather than waiting for Microsoft to enforce it at the protocol level. This gives you control of the timeline and the ability to grant exceptions while you work through the list.
-
Test, then enforce. Create a Conditional Access policy in report-only mode first, confirm the scope via sign-in logs, then switch to enforce.
The organisations that had done any of this work proactively before October 2022 were fine. The ones that hadn't had a difficult few weeks. The lesson: don't wait for Microsoft's enforcement dates. When they announce a deprecation, treat it as a project start date, not a warning.