On 11 August 2026 two Adobe support windows closed on the same day. Extended support for Magento Open Source and Adobe Commerce 2.4.5 ended, and regular support for 2.4.6 ended, with 2.4.6 moving into extended support that runs to 31 August 2027. Adobe's published dates put 2.4.4 and 2.4.5 outside its support windows entirely as of 24 August 2026: regular support for 2.4.4 ended 12 April 2025 and its extended support ended 14 April 2026. PCI DSS requirement 6.3.3 expects critical security patches to be installed within 1 month of release, which a release outside its support window cannot satisfy. Adobe publishes regular support for 2.4.7 to 31 May 2027 with extended support to 31 May 2028, regular support for 2.4.8 to 31 May 2028, and regular support to 31 May 2029 for 2.4.9, which was released on 12 May 2026. The upgrade target and its budget line belong in the retainer plan before the next renewal.
### How Adobe ships security fixes now
Adobe publishes 1 full patch release a year in May for the 2.4.x line, plus individual non-cumulative isolated security patch files released between them to enable faster remediation. The operational catch sits in the eligibility rule. Adobe states isolated security patches are tested against the latest security-only patch release, so they apply only to a store already running the latest -p version, and each isolated file is folded into the next full security patch. A store that has fallen behind on its -p version cannot take an isolated fix until it catches up, which converts a same-week security response into an upgrade project with a regression run attached. The retainer question is therefore who tracks isolated patch releases, who keeps the store on the current -p version, and who pays for the regression run on each.
### Where patches actually break
Patches apply cleanly on a stock 2.4.x install and fail on customized ones. The recurring failure modes are di.xml preference overrides on a class the patch rewrites, plugins whose around methods no longer match the patched signature, core files edited in place by a previous vendor instead of being patched through Composer, and third-party extensions pinned to a version constraint that blocks the patched dependency. None of these surface during the patch download. They surface in checkout, in an admin grid, or in a cron job that stops running quietly. Rocket Web states automated full-regression testing against changes and patches on its $3,500 per month Covered plan.
### The 24/7 gap
Rocket Web states 24/7 uptime and error monitoring on its $3,500 Covered plan, while urgent response first appears at $5,500 as next business day and becomes same-business-day emergency response at $9,500. JetRails states 24/7 USA-based support by phone, email and optional Slack, and a 15-minute emergency response SLA as an enterprise add-on. A store can therefore be monitored around the clock, alerted at 2am on a Sunday, and still have nobody contractually obliged to touch it until Monday. Monitoring coverage and out-of-hours human response by severity are 2 separate contract lines.
### The ownership boundary
Most incidents on a mature Magento estate land on a seam: a WAF or CDN rule change and an application deploy in the same window, an expired certificate on a CDN the agency does not administer, a Cloud deploy that fails on a config the host owns. Name the owner of root access, the CDN and WAF layer, and the deploy pipeline before signing. Then name the notice period and what gets handed back, including the CI/CD configuration. Of the 8 provider pages checked for this page, 1 publishes a contract term of that kind: JetRails states there are no lengthy contracts and that services are billed hourly.