Most of a baseline is organised by control. This part is organised by calendar, which is why it does not fit in a table with the others. Exchange Online is removing capability on published dates, and the expensive half of each removal is not the change itself but finding out what in your estate depended on it. Alongside those sit three decisions that cannot be reversed once taken. Both categories share a property that nothing else in this series has: waiting does not leave you where you were.
I am writing dates in this article knowing some of them will move, because one already has. Where a date is unstable I say so, and I would rather hand you a schedule with a stated confidence than a vague warning that something is coming. Verify each one before you commit a client to it.
Exchange Web Services, which is the one that will hurt
Exchange Web Services begins phased disablement on the first of October 2026 and is permanently off on the first of April 2027, and Microsoft has said there are no extensions or exceptions past that second date. That is unusually firm language and I would take it at face value.
The mechanic is worth understanding precisely, because the interesting part is not the off switch. There is an organisation-level setting whose current state in most tenants is unset, and on the October date Microsoft changes unset to disabled. If you have explicitly enabled it, the meaning of that enabled state changes on the same day: it stops meaning that the protocol works and starts meaning that only applications on an allow list may use it. So the tenants that survive October are the ones holding an accurate allow list.
Microsoft’s own word for the August work is optional, and that is worth taking literally rather than reading as a softened deadline. It will populate the allow list for you, from its own telemetry of what has been calling the protocol in your tenant, for any customer who has not built one by September. Being handed an inferred allow list is not the same as knowing what is on it. What building your own through August actually buys is not the survival of the protocol, because an administrator can switch it back on afterwards. What it buys is the absence of an unplanned outage. Configure the list and set the value to enabled before the end of August and the tenant is excluded from the October change altogether. Miss it and the change lands, applications stop, and somebody sets the value back at the moment of the interruption rather than ahead of it. That is a smaller failure than losing the protocol outright and a larger one than it sounds, because it arrives on an ordinary Thursday, on an integration nobody wrote down.
The work itself is discovery: which line-of-business applications, which backup or archiving product, which room-booking panel, which signature manager, which meeting recorder still speaks this protocol. In most estates the answer includes at least one thing nobody remembers buying.
There is a better argument for acting early than the calendar, and Microsoft has stated it plainly. It reserves the right to run temporary shutdowns before the final cutoff, turning the protocol off and then back on again to surface dependencies nobody has declared. A tenant that has already set the value to enabled is excluded from those too. So the case for doing this in August is not that a deadline falls there. It is that afterwards you stop being a participant in somebody else’s test.
One further detail that catches people. The organisation-level setting overrides the per-mailbox ones, so an inventory built from mailbox settings will tell you a comforting and irrelevant story.
Basic authentication over mail submission, and a date that already moved
This is the last basic-authentication flow standing in Exchange Online and it is kept alive entirely by devices: multifunction printers, alarm panels, building management systems, and applications written when a username and password over SMTP was simply how it was done.
An earlier retirement window in the first half of 2026 was withdrawn. The current position is that basic authentication for mail submission is disabled by default for existing tenants at the end of December 2026, that an administrator can still re-enable it per tenant or per mailbox after that, that tenants created afterwards never have it, and that the final removal date will be announced during the second half of 2027. Microsoft’s documentation now carries no dates at all and defers to an announcement, which is the clearest possible signal that the schedule is still moving. Treat December 2026 as the date to plan against and re-read the announcement before you act on it.
The migration is where judgment is needed, because the obvious answer is usually wrong. Applications that can hold a token should move to modern authentication on the same protocol, which is the smallest change and preserves everything else. Anything being rewritten anyway should send through the Graph rather than SMTP at all. High-volume internal notification traffic has a purpose-built path, but understand what you are signing up for: it cannot deliver outside the organisation, and it now requires consumption billing attached to an Azure subscription before an account will send a single message. That is a procurement conversation, not a configuration one. Genuinely external bulk delivery belongs on a service built for it, which is again a subscription and a project rather than a setting.
For a printer in a branch office, the honest answer is often none of the above. It is a scan-to-folder change, or a replacement device, or accepting that the thing scans to one internal address through an unauthenticated path you have deliberately scoped. Say that plainly rather than pretending a migration exists where it does not.
One more that is closer than any of the above and easy to miss, because it was announced after most of this year’s baseline material was written: TLS 1.0 and 1.1 are being retired for POP3 and IMAP4, with the administrative deadline at the end of July 2026 and the rollout running from August to the end of December. Nothing negotiates down afterwards, it simply fails. The population at risk is the same population as the SMTP one, older devices and applications nobody has looked at, which means the inventory you build for one of these answers the other.
Three things that have already gone
Client access rules are fully deprecated as of September 2025. Any inherited baseline that recommends them for scoping protocol access by address range is describing a control that no longer exists, and I still see them in documents dated this year.
The legacy identity and callback tokens that Outlook add-ins used are off across all tenants, so an add-in built against them fails rather than degrades. The replacement is a newer authentication model, and the practical consequence is that a vendor add-in nobody has updated has already stopped working, whether or not anyone reported it.
Classic eDiscovery and content search retired during 2025, and the older mailbox search command went the year before. This one matters more than it sounds, because it means any mailbox investigation runbook written before mid-2025 contains a step that no longer executes. The capability still exists, in a new place with a different shape, but the runbook does not know that and neither does the person following it at two in the morning.
The one-way doors
Three decisions in Exchange Online cannot be walked back, and none of them announces itself as permanent at the moment you make it.
Auto-expanding archiving is the sharpest. It cannot be turned off once enabled, for the organisation or for a mailbox. That much is documented and reasonably well known. What is not well known is the second half: enabling it removes your ability to recover or restore an inactive mailbox later. If a mailbox with expanded archiving becomes inactive, the only route to its contents is an eDiscovery export. So the decision is not really about archive size. It is a permanent trade of leaver-mailbox recoverability against headroom, taken on behalf of every mailbox in scope, usually because a handful of people had large mailboxes. Enable it where the growth is real. Do not enable it tenant-wide as housekeeping.
The high-volume mail path is a commercial commitment, not a setting. Wiring consumption billing to an Azure subscription to unblock a printer is a decision someone will be paying for in three years, and the person who made it will have left. Treat it as procurement.
Backup creates an ungoverned copy. If you turn on the first-party Microsoft 365 backup for Exchange, understand what you have created: a year of retention governed solely by the backup policy, which your Purview retention design does not reach; a copy that is not discoverable through eDiscovery; and deletions performed for a data subject request that do not touch the backup and must be repeated after any restore. That may be an acceptable trade for the recovery capability. It is not an acceptable surprise during a regulator’s questions, and it belongs in the retention design rather than in the operations backlog.
The calendar, in brief
| When | What | What it costs you to ignore |
|---|---|---|
| 31 July 2026 | Admin deadline for TLS 1.0 and 1.1 on POP3 and IMAP4; rollout runs 1 August to 31 December | Clients still negotiating those versions simply fail to connect |
| 5 August 2026 | The EWS-based Personal Bookings controls retire | Management moves to the Outlook web mailbox policy; an admin surface changes with no end-user signal |
| Through August 2026 | Build your own Exchange Web Services allow list and set the value to enabled. Microsoft calls this optional | You inherit an inferred list, you are not excluded from the October change, and you stay eligible for the interim shutdown tests. Both are recoverable by an administrator and both arrive unannounced |
| 1 October 2026 | Phased disablement begins; unset becomes disabled | Anything not on an allow list stops working, with no per-mailbox reprieve |
| End of December 2026 | Basic auth for mail submission disabled by default, still admin-reversible | Devices stop sending; reversible, but at the moment of the outage |
| End of 2026 | Direct Exchange ActiveSync certificate-based authentication retires | Certificate auth for ActiveSync stops; the path forward is Entra ID certificate-based authentication |
| 1 April 2027 | Exchange Web Services permanently off, no exceptions | Nothing left to negotiate |
| Second half of 2027 | Final removal date for basic auth announced | Plan the migration before the announcement, not after |
| Already gone | Client access rules, legacy add-in tokens, classic eDiscovery and content search | Runbooks that reference them fail at the moment you need them |
| Irreversible | Auto-expanding archiving | Inactive-mailbox recovery, permanently, for everything in scope |
| Irreversible in practice | Consumption billing for high-volume mail | A subscription commitment made to fix a printer |
| Design decision | First-party backup for Exchange | A year of undiscoverable, ungoverned copy outside your retention design |
The last article in this series is the checklist: everything from all three tiers as a scannable list, with each row pointing back to the article that argues for it.
Best Practices
‹ Previous: [BP 2.2] The Exchange Online Baseline: Recommended and Optional Tiers
Next: [BP 2.3.1] Build Sheet: Protocol Retirement Discovery ›
