Out-of-Support Exchange Server Risk Containment — Exchange 2016 and 2019

Support for both versions ended on 14 October 2025 per Microsoft's product lifecycle. Microsoft no longer produces security updates for them, no longer takes support cases for them, and has moved on-premises Exchange to Exchange Server Subscription Edition (SE), the only supported on-premises release. In practice you are running an internet-facing mail server that will never receive another fix, which is exactly the profile the large Exchange exploitation campaigns of the last few years targeted. Your insurer's questionnaire and your auditor's checklist both tend to ask about unsupported software for that reason. This service does not change that status; it lowers the exposure while you schedule the upgrade.

Yes, in stages, and it is already in effect. Exchange Online's transport-based enforcement system classes out-of-date and out-of-support on-premises Exchange servers as persistently vulnerable; per Microsoft's Exchange Team guidance it has applied to every Exchange Server version since February 2025. Affected servers appear first in a report in the Exchange admin center, then their mail to Exchange Online is progressively throttled (senders see a 4.7.230 response), then blocked (5.7.230). Administrators can request a pause of up to 90 days per year from the report. On day 1 we read the report with you and record each server's stage; on day 5 we request the pause where a server needs it. The pause buys time for the SE upgrade — it is not a way to stay on 2016 or 2019 indefinitely.

No, and the remediation plan will say so in writing. There is no configuration that turns Exchange 2016 or 2019 back into a supported product; only Exchange Server SE or Exchange Online does that. What containment does is remove the well-known attack paths (unpatched builds, relay attacks Extended Protection closes, unscanned web requests, Basic authentication, an internet-facing admin console, a server with no endpoint detection) and give you dated evidence of it. If someone tells you a hardening service satisfies a 'supported software' requirement, be careful with that vendor.

If you can, do — an Exchange 2019 CU14 or CU15 organization can take an in-place upgrade to SE, and that is the better use of the money. Containment is for organizations where the upgrade is genuinely months away: a 2016 estate that needs new servers and a side-by-side migration, a licensing decision that is still with procurement, a change freeze, or a hybrid topology nobody wants to touch before the audit. A week of containment now costs less than the exposure of running unhardened for those months, and the remediation plan we hand over is the scoping input for the SE work — or for the SE upgrade readiness assessment if the path is still open. Microsoft has also announced that a future SE cumulative update will end coexistence with 2016 and 2019 entirely, so 'later' has a hard edge; the plan records Microsoft's current timing for that.

For Exchange 2016 the final cumulative update is CU23; for Exchange 2019 it is CU15, with CU14 still the practical target where CU15's prerequisites cannot be met in the week. Microsoft's last security updates were released for those builds only, so a server on an older CU has been missing security updates for longer than its administrators usually realize — the CU has to be installed before the last SU can be. A CU install updates Active Directory schema and takes the server out of service for the duration, so it is sequenced on day 2, one DAG member at a time, in your window. If a server's operating system cannot host the final CU, that is written down on day 1 and the plan says what to do about it; we do not pretend a partially updated server is 'as patched as it can be'.

Extended Protection binds the authentication channel to the TLS session so that credentials or tokens captured by a relay or a man-in-the-middle cannot be replayed against OWA, EWS, MAPI, PowerShell and the other Exchange web services — it closes the class of attack used in several widely reported Exchange compromises. Microsoft enables it by default from Exchange 2019 CU14 setup and provides a management script for other builds. It is unforgiving about prerequisites: TLS settings must be identical across all servers, SSL offloading on a load balancer must become bridging with the same certificate or be removed, NTLMv1 must be disabled, and it must be enabled consistently or servers stop talking to each other. Enabling it without that work is the most common way a well-meant hardening change becomes a mail outage, which is why day 3 starts with verification and ends with every client path tested.

The Antimalware Scan Interface lets the antimalware engine on the server — Microsoft Defender, or another AMSI-capable product — inspect HTTP requests to Exchange before Exchange processes them, so a malicious request aimed at a known or unknown vulnerability can be blocked on the way in rather than after a web shell has been written. Exchange 2016 and 2019 have had AMSI request scanning since 2021, and Microsoft added request-body scanning in a late-2024 security update; it is off by default and enabled with a setting override, which we do on day 3 and test with a benign request. It is one of the few controls that keeps working against exploits that appear after the last patch, which is why it matters more, not less, on an unsupported server.

It costs nothing to keep and can only help, so we confirm it is running, enabled at the organization level and able to reach Microsoft's endpoint. The service applies mitigations Microsoft publishes for urgent threats — typically IIS rewrite rules or the disabling of a vulnerable feature — before or instead of a patch. Whether Microsoft will publish mitigations for an out-of-support version is Microsoft's decision and we make no promise about it; what we can say is that a server on which the service is broken or blocked by the proxy, which is common, would not receive them even if they were published.

Basic authentication is what an attacker uses with a password from a breach dump, and it is also what a ten-year-old scanner uses to send scans to a mailbox. On day 1 we pull the IIS and protocol logs to find every user, device and application still authenticating that way. Each one is either moved to a modern method, replaced by an SMTP relay path that does not need mailbox credentials, or held under a written exception with an owner and an expiry date that you approve before anything is blocked. Exchange 2019 supports authentication policies that block legacy authentication per protocol; Exchange 2016 does not, so there we remove Basic authentication per virtual directory and rely on hybrid modern authentication where hybrid exists. Nothing is switched off before the exception register is signed.

Outlook on the web is the endpoint that most benefits from pre-authentication, and Microsoft Entra application proxy handles it well (Entra ID P1 required, Microsoft's charge). The Exchange Control Panel should not be reachable from the internet at all — its options pages are needed by OWA, so this is a publishing-rule decision rather than a simple 'disable'. Outlook desktop over Outlook Anywhere or MAPI over HTTP, ActiveSync for phones, EWS and Autodiscover each get a decision on day 4: pass-through publishing, access over your VPN or Entra Private Access, or hardened direct exposure behind Extended Protection, AMSI and Defender. The decision record states which trade-off you chose for each, so a future auditor sees a reasoned posture rather than a default.

Because an unsupported, internet-facing server is where you most need to see a web shell being dropped or credentials being dumped in real time. Defender for Endpoint gives you that visibility and the ability to isolate the host from the Defender portal. It coexists with Exchange when Microsoft's current antivirus exclusions are applied — and only those: in 2023 Microsoft deliberately removed several folder and process exclusions from its Exchange guidance precisely so that web shells in the ASP.NET temporary and IIS paths get scanned, and the exclusion lists still circulating from older build guides undo that. Licensing is a Microsoft Defender for Servers plan or Defender for Endpoint server licensing per host, Microsoft's charge; ongoing monitoring of what Defender finds is a separate service.

Yes. In 2025 Microsoft moved Exchange hybrid off the shared service principal it had used for years and onto a dedicated Exchange hybrid application in your Entra tenant, after a vulnerability (CVE-2025-53786) that let an attacker who controlled an on-premises server escalate into Exchange Online; it was serious enough for a US federal emergency directive, and Microsoft has been blocking hybrid traffic that still uses the old identity. On day 2 we confirm the dedicated application is configured and the old service principal's leftover credentials are cleaned up, record the OAuth and hybrid modern authentication state, and validate free/busy and mailbox moves after every change. Hybrid also changes the enforcement picture — it is exactly the mail path Exchange Online throttles — so the report reading on days 1 and 5 matters more for hybrid customers.

The whole week for up to four Exchange 2016/2019 servers in one Exchange organization: inventory and baseline, the update work, Extended Protection, AMSI and mitigation-service verification, legacy authentication removal with the exception register, exposure reduction, Defender for Endpoint onboarding, hybrid hygiene where hybrid exists, the enforcement report review and pause request, and the dated remediation plan with its closing readout. Fixed price, quoted in writing before we start; you pay after you approve delivery. A fifth server, a second Exchange organization, or an air-gapped estate is quoted per estate before day 1, not discovered on day 3. Microsoft's licences — Entra ID P1, Defender for Servers, Exchange Server SE — are Microsoft's charge and are not in this fee.

That is the insurer's call, and we will not tell you otherwise. What the week produces is what underwriters usually want to see when a system is unsupported: evidence that it is fully updated to the last release, that the known compensating controls are in place, that the admin surface is off the internet, that endpoint detection covers it, and a dated plan to retire it. IT Partner carries its own cyber insurance, verified by a third party (see our /verify page), so we know the questions from the answering side; the remediation plan is written so that a security lead can attach it to a questionnaire response as-is.

Not as a standing program. Microsoft did not create a multi-year ESU offering for Exchange the way it did for Windows Server and SQL Server; to our knowledge the short, paid bridge Microsoft offered to eligible customers around the end-of-support date is no longer available, and we confirm the current position with you at scoping. The realistic choices are the ones the remediation plan lays out: contain now and upgrade to Exchange Server SE, or contain now and migrate to Exchange Online — in either case, containment is the bridge, not the destination.

Time-bound access that you create and disable afterwards: Organization Management in Exchange and local administrator on the servers for the update and hardening work, a scoped administrator in Microsoft 365 for the enforcement report, the pause request, application proxy and Defender onboarding, and — only where a cumulative update is outstanding — the rights to prepare Active Directory schema, which your directory team can run instead. We never ask for standing Domain Admin, and the same least-privilege discipline we publish for our Microsoft 365 engagements applies here.