SharePoint 2016/2019 is unpatchable now. Exchange has until 31 October.

Two dates, stated precisely, because most coverage has blurred them. Exchange Server 2016 and 2019 left extended support on 14 October 2025 — Microsoft's lifecycle pages record the cut-off as 15 October 2025, 06:59:59 Pacific, which is the instant support lapsed rather than the last covered day. SharePoint Server 2016 and 2019 left extended support on 14 July 2026, listed the same way as 15 July 2026, 06:59:59 Pacific. Both figures are extended support, not mainstream. Mainstream ended years earlier in every case.

Neither date is the one that governs your week. For Exchange, the operative deadline is 31 October 2026, when the second and final period of the paid Extended Security Update programme closes. For SharePoint there is no operative deadline, because there is no ESU programme at all. Microsoft has not announced one and is not going to.

Seven weeks of purchased patches on one product. Nothing whatsoever on the other.

The Exchange runway is real but short

Period 1 of the Exchange ESU programme ran from October 2025 to 14 April 2026. Microsoft then announced Period 2, covering 1 May to 31 October 2026, with any licence bought from 15 April 2026 counting automatically as Period 2. Microsoft's wording on what follows is unambiguous: there will be no further extensions of the programme.

That matters because the most consequential Exchange bug of the year only reached 2016 and 2019 through that programme. CVE-2026-62911, fixed on 11 August 2026, carries a CVSS score of 8.0 and is described by Microsoft as an authentication bypass by capture-replay. The mechanism is an MRSProxy endpoint that fails to enforce Extended Protection for Authentication, opening the door to NTLM relay and, from there, to reading and sending mail from other people's mailboxes and pulling down their attachments. Orange Tsai of DEVCORE reported it through Trend Micro's Zero Day Initiative.

The Shadowserver Foundation counted 21,899 exposed servers still unpatched on 31 August 2026, with roughly 6,200 in the United States and 5,100 in Germany. Germany's BSI reportedly put the share of vulnerable German on-premises Exchange servers at around 85 per cent in late August. NCSC-NL, the Dutch national CERT, has said a working exploit is circulating publicly.

If you did not buy Period 2, you are already carrying an unfixed CVSS 8.0 authentication bypass with a public exploit on an internet-facing mail server. Buy the licence today if that describes you. It is the cheapest control on this page by a wide margin.

SharePoint has no runway at all

The last security update SharePoint 2016 and 2019 will ever receive shipped on 14 July 2026 — the same day their support ended. It fixed CVE-2026-55040, a JWT token validation failure that Rapid7 scores at CVSS 9.1 and describes as allowing an unauthenticated remote attacker to impersonate any SharePoint site user whose Active Directory SID or UPN they know. Rapid7 published a proof of concept on 12 August; attackers were exploiting it within days, and CISA added it to the Known Exploited Vulnerabilities catalogue on 18 August 2026.

Take the arithmetic seriously. A critical pre-authentication bypass was disclosed on the final day of support, weaponised four weeks later, and only closed for organisations that applied that very last patch. The next one will not be closed at all.

An unpatchable internet-facing server is not a vulnerability you manage. It is a perimeter you have already conceded. The only remaining question is what sits behind it.

This is not hypothetical for SharePoint specifically. CISA's 14 July 2026 alert named six on-premises SharePoint flaws under active exploitation, including CVE-2026-32201, CVE-2026-45659 and CVE-2026-55040, all affecting Subscription Edition, 2019 and 2016 alike. CVE-2026-45659, a deserialisation bug patched in May, was flagged by CISA as abused by ransomware operators. And the ToolShell chain of July 2025, headlined by CVE-2025-53770, ended with Warlock ransomware on on-premises farms. SharePoint Server is a proven ransomware entry point with a live research community pointed at it.

What this costs you on paper

PCI DSS requirement 6.3.3 obliges you to protect system components from known vulnerabilities by installing applicable vendor security patches, with critical and high severity fixes applied within one month of release. On software where the vendor no longer produces patches, that control cannot be satisfied. Requirement 12.3.4, which covers periodic review of technologies that are no longer supported, exists precisely to make you notice before the assessor does. An unsupported SharePoint farm in scope is a finding, not a risk acceptance.

Insurance is the sharper edge. Underwriters have moved towards a three-part structure: an application question about unsupported software, a policy condition warranting that the answers remain true, and an exclusion that bites when the warranty fails. Note that most of the commentary on this comes from brokers and vendors with something to sell, so read your own wording rather than theirs. Pull the policy, find the unsupported-software clause, and get a written answer from your broker before renewal — not after an incident.

Your mail flow is being cut off right now

Separately from any of this, Exchange Online began tightening its transport enforcement against out-of-date on-premises servers in the second week of September 2026. The new minimum for hybrid organisations is the October 2025 security updates: Exchange 2019 CU15 SU5 (KB5066367) and Exchange 2016 CU23 SU19 (KB5066369). Servers below that line, connecting through an OnPremises inbound connector, first see temporary 450 4.7.230 responses, then permanent 550 5.7.230 rejections with non-delivery reports to senders.

The throttle ramps rather than slamming shut — Practical365's description of the mechanism has it starting at five minutes of delay per hour and escalating across thirty days before blocking begins, with a 90-day enforcement pause available per calendar year. Use the pause if you need it, but treat it as what it is: a countdown, not a reprieve. Microsoft has signalled the bar will rise again to ESU-only builds within months.

Containment architecture for the migration window

Assume the box will not be patched again and design accordingly.

1. Terminate sessions at something you can patch. CISA's own guidance for SharePoint is to avoid direct internet exposure and, where that is impossible, to place a Layer 7 reverse proxy or application-layer control in front that authenticates requests before they reach IIS. Do the same for Exchange. Nothing should reach /ecp, /_layouts/ or /_vti_bin/ from the internet without passing an identity check on a supported device first.
2. Turn on Extended Protection for Authentication across every Exchange virtual directory. That is the exact control CVE-2026-62911 defeated on one endpoint. Microsoft ships a management script for it. Verify it is enabled rather than assuming a prior CU did it.
3. Default-deny outbound from the server VLAN. Allowlist Microsoft 365 endpoints, DNS, NTP and your antimalware update source. That is the whole list. Most webshell command-and-control and every data-staging exfil path dies at an egress policy, and an unpatchable host is where that investment pays.
4. Set AMSI to Full Mode on SharePoint. CISA specifically recommends selecting Full Mode for Request Body Scan Mode where feasible, with Defender Antivirus present on every farm server.
5. Hunt before you rotate. CISA's phrasing is worth following exactly: look for and remove intrusion artefacts, including machine-key harvesters, before rotating ASP.NET machine keys, otherwise you hand the attacker the new keys too. Rotate again after any patch and restart IIS.
6. Strip standing privilege. Treat these hosts as Tier 0. No domain admin interactive logons, LAPS on the local administrator account, no cached credentials, and a review of what the SharePoint farm account can actually do in SQL.
7. Get an immutable backup and restore it somewhere. Test restoring mailbox and content databases into the target platform. That test is also your migration rehearsal, so it is not wasted effort either way.

Detection on a box you cannot patch

Compensating detection has to be loud, because you have no fix to fall back on. Ship IIS W3C logs off the host to your SIEM before anything else — on a compromised server, local logs are the first thing to go. Then build these:

• Any process spawn of cmd.exe, powershell.exe or certutil.exe with w3wp.exe as parent. This single rule catches most SharePoint and Exchange exploitation at the point it becomes interesting, and it costs almost nothing to run.
• File creation or modification in the SharePoint LAYOUTS directory tree and in the Exchange FrontEnd HttpProxy OWA auth path. Both are long-standing webshell drop zones.
• New or modified IIS modules, and any write to web.config. ToolShell-class intrusions have used malicious modules that survive a configuration clean-up until IIS is reset.
• Kerberos and NTLM authentication originating from the Exchange computer account to hosts it has no operational reason to touch. Relay does not look like exploitation in your logs; it looks like the mail server behaving oddly.
• New-MailboxExportRequest execution and any new assignment of the ApplicationImpersonation or EWS impersonation rights.

One practical note on the exit, since it is less painful than teams assume: Exchange Server Subscription Edition follows the Modern Lifecycle Policy and, from the current Exchange 2019 CU, the move is an in-place upgrade that behaves like installing another cumulative update. SharePoint Subscription Edition needs a real migration and real time. Which means the two products need different answers, and the organisation that lumps them into one 2026 modernisation programme will finish the easy one and still be running the dangerous one in January.