Patched on time. Out of patches in July.

The patch shipped. That part worked. The July 21 out-of-band update replaced the deserialization blocklist with an allowlist, the AMSI integration got tightened, the KB articles went up, and the operators who applied them on schedule closed the door. On the bug itself, the chain ends. On the product the bug lives in, the clock is the part that matters now.

SharePoint Server 2016 and SharePoint Server 2019 reach end of extended support on July 14, 2026. That is sixty days from this writing. After that date Microsoft does not ship security updates for either product through the public channel. There is no announced Extended Security Updates program for on-premises SharePoint. The Subscription Edition, introduced in 2021 as the modern on-prem track, is the explicit upgrade path; for organizations that have not started the migration, the path on offer is “buy SharePoint Subscription Edition or move to M365.” Both options require a real migration project. Neither is the “apply this patch and reboot” pattern the same operators just executed on July 21.

The pattern this lands inside is older than ToolShell. Long-lived application platforms — Exchange, SharePoint, Confluence, GitLab on- prem — produce a critical-rated CVE on a public-facing endpoint on a roughly annual cadence. The endpoint that processed the attacker- controlled deserialization input on /_layouts/15/ToolPane.aspx does not stop being attacker-reachable when the product hits end of support. It stops being patchable. SharePoint Server 2013, end of extended support April 11, 2023, never received a ToolShell patch; CISA’s guidance for 2013 farms in July 2025 was disconnect from the internet, which is the guidance every EOS application gets when the next chain lands. The operators running 2013 in July 2025 were not neglectful — they were on a product that ran out of patches twenty- seven months earlier. The operators running 2016 or 2019 in August 2026 will be in the same posture.

The compliance dimension is the part most likely to force the conversation. PCI DSS Requirement 6.3.3 puts a one-month clock on critical security patches; an EOS product has no patches, so the clock cannot be satisfied by patching. FedRAMP control SI-2 reads the same way against the authorization boundary. SOX 404 ITGC reviews that test patching as a control narrative will produce a finding when the underlying product is no longer receiving updates. None of this is theoretical for 2016 or 2019 after July 14. The QSA, the 3PAO, and the SOX auditor all arrive in the second half of the year with the same question: what is the plan for the SharePoint farm that just lost its patch supply.

The narrow lesson is product-specific: the migration plan is the remediation now, not the next emergency patch. The wider one is that on a long-lived application platform with a near-term EOS date, the patch you applied this month is one of the last ones on offer. The runbook that says “patch when the vendor ships a fix” is the right runbook until the vendor stops shipping fixes. After that the runbook is the migration plan, and the migration plan is on a different calendar than the one the patch queue lives on.