Windows News
Microsoft has set July 2026 as the final cutoff for Exchange Online POP3 and IMAP4 clients that still negotiate Transport Layer Security (TLS) versions 1.0 or 1.1. After that date, every connection that hasn’t moved to TLS 1.2 will fail outright. The move pulls the last escape hatch Microsoft created five years ago for organizations with older devices and applications that couldn’t upgrade in time for the original deprecation wave.
The clock has been ticking since 2020. That year, Microsoft disabled TLS 1.0 and 1.1 for most Exchange Online client protocols—including Outlook on the web, Exchange ActiveSync, and Outlook for Windows—while giving POP3 and IMAP4 a temporary reprieve. The company introduced an “allow legacy TLS” setting that admins could enable on individual mailboxes via PowerShell. It was a lifeline for aging printers, security cameras, line-of-business apps, and monitoring tools that needed more time to shed outdated encryption.
That carve-out disappears in July 2026. After the deadline, the allow-legacy-TLS flag stops working. Any client that still offers only TLS 1.0 or 1.1 during the handshake will get a hard protocol error. No amount of PowerShell tweaking will bypass it. The server will simply refuse the connection.
Microsoft’s Exchange Team has stressed that the original opt-in was always meant to be temporary. Now the message is blunt: finish the transition to TLS 1.2. There will be no further extensions.
Why TLS 1.0 and 1.1 are dead tech
TLS 1.0 debuted in 1999. TLS 1.1 followed in 2006. Both are riddled with cryptographic weaknesses that modern attacks exploit with ease. The POODLE attack, BEAST, and various downgrade vulnerabilities have rendered them unacceptable for any environment that handles sensitive data.
Regulatory standards such as PCI DSS have mandated TLS 1.2 or higher for years. Browsers dropped support long ago, and the broader industry is marching toward TLS 1.3. Letting Exchange Online POP and IMAP clients cling to 1.0/1.1 was an anomaly that Microsoft now intends to close permanently.
What changes in July 2026
Right now, a mailbox can have POP3 or IMAP4 configured with the EnableExplicitTLS property set to $false. That setting allows the server to accept TLS 1.0 or 1.1 in addition to 1.2 during the handshake. After July 2026, that property becomes moot. All POP and IMAP connections will need to use TLS 1.2—no fallback, no exceptions.
The change only affects inbound POP3 (port 995) and IMAP4 (port 993) connections to Exchange Online. Outbound SMTP AUTH submissions are not touched directly by this update, but Microsoft has separately announced a phase-out of TLS 1.0/1.1 for SMTP AUTH starting in September 2025, with full enforcement planned across 2026. Together, the two measures leave no room for insecure mail transport.
Who gets hit
Any device or app that uses POP3 or IMAP4 to pull email from Exchange Online and hasn’t been upgraded to TLS 1.2 is at risk. The list typically includes:
- Multifunction printers and scanners that email documents
- Older VoIP systems, door controllers, and IoT sensors
- Legacy CRM or ERP software with built-in mail retrieval
- Custom scripts written in Python, Perl, or PHP that use outdated libraries
- Monitoring platforms that check mailboxes for alerts
- Long-forgotten service accounts with POP/IMAP enabled
Many of these devices have been running untouched for years. Their firmware may not even offer TLS 1.2 as an option, which means replacement is the only path.
A tight timeline: start scanning now
July 2026 sounds distant, but hardware refresh cycles, compliance reviews, and application rewrites can easily consume a year or more. The first step is to identify every mailbox that still leans on the legacy TLS setting. Exchange Online PowerShell makes this straightforward.
# Find all mailboxes where POP3 or IMAP4 still allows legacy TLS
Get-Mailbox -ResultSize Unlimited | Get-CASMailbox | Where-Object {
$_.PopEnableExplicitTLS -eq $false -or $_.ImapEnableExplicitTLS -eq $false
} | Select-Object Name, PopEnableExplicitTLS, ImapEnableExplicitTLS
Run that script and you’ll have a clear list of accounts that need attention. Keep in mind that service accounts and shared mailboxes often get overlooked. If you see a mailbox in the list and can’t immediately identify what uses it, check sign-in logs in Azure AD (now Entra ID) to trace the client IPs and device types.
For a more granular view, you can also test a single mailbox by simulating a legacy TLS connection. Tools like openssl s_client let you probe the endpoint:
# Attempt a POP3 connection with TLS 1.1 — should fail now or show a warning
openssl s_client -connect outlook.office365.com:995 -tls1_1
Microsoft has been sending preparatory error codes for a while. Connections that negotiate TLS 1.0 or 1.1 already receive a warning that support will end. If you see log entries with phrases like TLS1.0_Warning in your client applications, that mailbox is on the list.
How to move off legacy TLS
The path forward depends on the type of client. For most scenarios, the steps break down into four buckets:
1. Update firmware or software
Check with device manufacturers for firmware that adds TLS 1.2 support. Many printer and scanner vendors released updates years ago. Apply them and test. If no firmware exists, the device must be retired or its email functionality disabled.
For line-of-business applications, updates might involve a patch or a configuration change. Some older .NET applications, for example, can be forced to use TLS 1.2 by adding a registry key that overrides the default security protocol, but this isn’t guaranteed to work for all versions.
2. Replace incapable hardware
When firmware updates aren’t available, budget for new devices. Plan a phased hardware refresh that prioritizes the most critical workflow components. Don’t forget to update network documentation so no device slips through the cracks.
3. Switch to a modern API
One of the best long-term fixes is to abandon POP and IMAP entirely. Microsoft Graph API offers a rich, OAuth 2.0-secured method to access Exchange Online mailboxes. It inherently enforces TLS 1.2 (or better) and aligns with Microsoft’s Zero Trust model. Modern applications, scripts, and monitoring solutions can use Graph to read, send, and manage email without ever touching legacy protocols.
If a third-party app insists on IMAP, check whether it supports OAuth 2.0 authentication with Exchange Online. Microsoft’s documentation on "Authenticate an IMAP, POP or SMTP connection using OAuth" steps through the setup. Moving to OAuth not only kills the TLS problem but also eliminates the need for basic authentication, which Microsoft is aggressively deprecating.
4. Rethink your email integration patterns
Some processes might not really need to pull mail at all. Alerts and notifications can often be routed through webhooks, Power Automate, or Azure Logic Apps instead of monitoring a dedicated mailbox. Re-architecting the workflow might be simpler than patching ancient code.
Testing before the deadline
Don’t wait until July 2026 to find out whether your environment is ready. Microsoft usually provides a grace period during which the legacy setting simply stops being honored, but by then it’s too late to avoid outages. Instead, pick a non-critical mailbox and forcefully disable legacy TLS now:
Set-CASMailbox -Identity "[email protected]" -PopEnableExplicitTLS $true -ImapEnableExplicitTLS $true
Then try to connect with the client in question. If it fails, you have your answer. Work through the remediation steps and repeat the test until the connection succeeds.
What happens if you miss the date?
After July 2026, any device still attempting POP3 or IMAP4 over TLS 1.0/1.1 will see a protocol error. The exact error depends on the client but typically reads "SSL/TLS handshake failed" or "Connection reset." There is no backdoor. The connection never reaches the authentication stage, so basic authentication problems don’t even come into play.
For organizations that ignored earlier warnings, this will manifest as a sudden, unexplained failure of all legacy-connected devices. Help desks may see a flood of tickets from users whose printers can no longer scan to email or whose automated reports stop arriving. The only recovery is to upgrade the client or switch to a supported protocol.
The larger picture: TLS everywhere in Microsoft 365
The POP/IMAP move fits into a sweeping security overhaul. Over the past four years, Microsoft has:
- Retired TLS 1.0/1.1 for Exchange Online web services and REST APIs (2020)
- Removed support for legacy TLS in SharePoint Online and OneDrive for Business
- Announced the retirement of TLS 1.0/1.1 for SMTP AUTH, starting with a phased block in September 2025
- Enforced TLS 1.2 for all admin interfaces and PowerShell modules
- Pushed Outlook clients to use modern authentication and TLS 1.2 by default
Together, these changes signal that any service reaching into Microsoft 365 must be capable of TLS 1.2 at a minimum. There is no scenario where allowing weaker encryption is acceptable, and the infrastructure is being hardened accordingly.
Beyond TLS: a nudge toward modern authentication
This change also serves as a reminder that POP and IMAP, even with TLS 1.2, are legacy protocols that lack the security benefits of modern authentication. Basic authentication over these protocols leaves credentials vulnerable to password spray and phishing. Microsoft has been clear that basic authentication for Exchange Online will be permanently disabled for all tenants in the second half of 2025.
Thus, the July 2026 TLS deadline isn’t an isolated event. It’s the last step in a multi-year project to secure email access. Organizations that use it as an excuse to move away from POP/IMAP entirely will emerge with a simpler, safer infrastructure.
What to do this quarter
The immediate actions are straightforward:
- Run the PowerShell inventory described above to uncover every mailbox with legacy TLS enabled.
- Map those mailboxes to physical devices or applications using sign-in logs and internal asset records.
- Categorize each client as updatable, replaceable, or removable.
- Start a test migration for a small subset of non-critical devices. Update firmware and confirm TLS 1.2 connectivity.
- Budget for replacements where updates aren’t possible. Order lead times can be long, so start the procurement process now.
- Review your mail flow architecture to see where Graph API or other modern connectors can replace POP/IMAP workflows.
Microsoft has promised not to grant another extension. The legacy endpoint has served its purpose, and the industry has moved on. July 2026 will arrive quickly—the surest way to avoid disruption is to treat the deadline seriously and act now.