Security patch management on Adobe Commerce is the work that prevents disasters from happening. It is also the work that gets cut first when budgets tighten, deferred when other priorities push, and treated as a checkbox in support contracts rather than a discipline. The merchants who get this right have predictable, low-anxiety patch cycles and have never been breached. The merchants who get it wrong are usually one CVE away from a security incident that costs more than five years of patch management.
A support retainer should explicitly define how security patches get evaluated, tested, and deployed. Vague language about “we’ll handle patches” is not enough; the specifics determine whether your store stays secure or quietly accumulates exposure. Bemeir’s Magento team manages patch programs for clients ranging from $5M to $100M in annual GMV, and the patterns that work are concrete enough to write into a contract.
What “patch management” actually has to handle
Adobe Commerce security patches come in several flavors and each needs different handling.
Quarterly security updates. Adobe releases scheduled security patches roughly every quarter as part of the standard release cadence. These are the predictable patches and the foundation of the patch program. The patches are bundled with the next minor version release (e.g., 2.4.7, 2.4.8) and are intended for clean deployment after testing.
Out-of-band security patches. Critical vulnerabilities sometimes get individual patches released between scheduled releases. These are usually published with severity ratings and exploit indicators, and they need to be deployed faster than quarterly patches.
Adobe Commerce composer dependency updates. Many Adobe Commerce vulnerabilities are actually in PHP dependencies (Symfony, Laminas, Composer packages) rather than in the core Adobe Commerce code. The patch program needs to track and update these dependencies, not just the Adobe-released code.
Third-party extension patches. Commercial Magento extensions have their own patch cycles, and many vulnerabilities discovered in the wild are in extensions rather than in Adobe Commerce itself. The patch program needs to track every extension’s vendor advisories.
PHP and infrastructure patches. PHP versions, MySQL versions, Redis versions, web server versions, and OS-level packages all have their own security cycles. The patch program needs to coordinate these with Adobe Commerce compatibility.
A patch program that addresses only quarterly Adobe Commerce releases misses 60-70% of the actual patch surface. The retainer needs to cover all five categories.
What the retainer should specify
The contract language for patch management should answer six specific questions. If your current retainer doesn’t, it should.
Patch evaluation timeline. How quickly after Adobe releases a patch does the agency evaluate it for your store? The standard we recommend: critical and high-severity patches evaluated within 1 business day, medium-severity within 5 business days, low-severity within 10 business days.
Patch testing process. What testing happens before the patch deploys to production? At minimum: applied to staging environment, regression tested against the merchant’s critical user flows (checkout, customer registration, search, key admin functions), validated against the extension stack for compatibility.
Patch deployment SLA. How quickly after testing does the patch deploy to production? The standard we recommend: critical patches deployed within 7 days of release (or 72 hours for actively exploited vulnerabilities), high-severity within 14 days, medium-severity within 30 days, low-severity within 90 days or batched with the next scheduled deploy.
Out-of-band patch handling. When Adobe releases an emergency patch outside the normal cycle, what is the response? The standard: same-day evaluation, expedited testing, emergency deploy window within 48-72 hours for actively exploited vulnerabilities.
Patch failure handling. What happens if a patch breaks something during testing? The standard: documented incident report, escalation to senior engineering, alternative mitigation if patch cannot be applied, compensating controls until patch can be applied safely.
Patch reporting. How does the merchant know what patches have been applied and what is outstanding? The standard: monthly patch status report listing all available patches and their status (applied, scheduled, deferred with rationale), with patch level visible in a dashboard the merchant can check anytime.
A retainer that addresses all six questions with specific SLAs and processes is a real patch program. A retainer that addresses one or two is a checkbox that produces variable results.
The severity framework that actually matters
Adobe publishes severity ratings with their patches, but the severity is only one input into how urgently a merchant should apply the patch. The fuller framework:
Severity (Adobe rating): Critical, High, Medium, Low. Adobe’s published rating based on the vulnerability characteristics.
Exploit availability: Is exploit code public? Is the vulnerability being actively exploited in the wild? Sources like the Adobe Security Bulletins and CVE.org track this.
Authentication required: Does exploiting the vulnerability require authentication to the store? Unauthenticated remote code execution is dramatically more serious than authenticated privilege escalation.
Affected component: Storefront-exposed vulnerabilities are more urgent than admin-only vulnerabilities. A vulnerability in the checkout is more urgent than one in the catalog admin.
Merchant exposure: Is the vulnerable feature actually used on this specific store? A vulnerability in B2B company-account management does not matter on a B2C store.
The framework matters because it produces different urgency for different patches. A “Critical” patch in a feature the merchant doesn’t use is lower priority than a “High” patch in a feature the merchant uses heavily. A real patch program scores patches on this fuller framework, not just Adobe’s published severity.
The patch testing surface
Patch testing is the single most undervalued part of patch management. The pattern: a patch is applied, the store loads, the obvious functions work, the patch is declared “tested” and deployed. Then a customer hits the regression that the testing missed.
The testing surface that actually works covers:
Critical user flows. Add to cart, checkout end-to-end with all production payment methods, customer registration and login, customer account access, password reset, order history view, return processing.
Critical admin flows. Admin login, order management, customer management, catalog editing, attribute management, configuration changes, indexer execution.
Integration touchpoints. ERP sync, payment processor interaction, shipping rate calculation, tax calculation, search functionality, personalization (if installed).
Performance regression. Patch deployment can occasionally tank performance. Comparing key page load times before and after the patch catches regressions early.
Extension compatibility. Each major extension is exercised in a way that uses the patched functionality. Patches frequently interact with extensions in unexpected ways.
A patch program that does not test all five surfaces is testing a fraction of what could go wrong. The testing is what catches the regression before it reaches customers.
The composer dependency situation
Adobe Commerce ships with many PHP dependencies, most of them third-party packages managed through Composer. Vulnerabilities in these dependencies are real and are sometimes more serious than vulnerabilities in Adobe Commerce code itself.
The discipline:
Composer.lock auditing. Tools like Composer’s audit command, Snyk, or Sansec’s eComscan scan the composer.lock file against vulnerability databases. The patch program should run this monthly minimum, with alerting on new high-severity findings.
Selective dependency updates. Adobe Commerce ties some dependencies to specific versions; updating these out of band can break Adobe Commerce. Other dependencies can be updated freely. The patch program needs to know which is which.
Major version upgrades. Some PHP dependencies eventually require major version upgrades that change APIs. These need to be coordinated with Adobe Commerce upgrades because they often coincide with Adobe Commerce release boundaries.
The merchants who track composer dependencies separately from Adobe Commerce patches consistently find vulnerabilities the Adobe-only patch program would have missed. This is one of the easier ways to improve patch program coverage.
The patch program comparison
The pattern of what real patch programs look like compared to what most retainers cover:
| Patch program characteristic | Common retainer | Real patch program |
|---|---|---|
| Scheduled Adobe patches | Applied, often months late | Evaluated within days, deployed within weeks |
| Out-of-band Adobe patches | Often missed | Applied within 72 hours for critical |
| Composer dependency vulnerabilities | Not tracked | Monthly audit, prioritized response |
| Extension vulnerabilities | Not tracked | Per-extension vendor monitoring |
| PHP version upgrades | Done when forced by hosting | Planned 6-12 months ahead |
| Patch testing | Smoke test on dev environment | Multi-surface regression on staging |
| Patch reporting | Quarterly summary if requested | Monthly status report standardized |
| Patch SLA | Vague language | Specific timelines by severity |
| Emergency response capacity | Hope someone is available | Documented on-call rotation |
| Annual patch audit | None | Comprehensive year-in-review |
The cost difference between a real patch program and a checkbox retainer is meaningful but not enormous: typically a 20-40% retainer cost increase. The risk reduction is the difference between “we have never been breached” and “we are exposed but don’t know it.” For most mid-market stores, the math is obvious.
The internal commitments the merchant needs to make
A patch program only works when the merchant side is set up to support it. The commitments:
Maintenance windows. Patches need to deploy to production, and deployment usually requires brief maintenance windows. The merchant needs to define when these can happen (typically weekly low-traffic windows) and not block them for non-emergency business reasons.
Staging environment fidelity. The staging environment used for patch testing needs to genuinely resemble production. Drift between staging and production produces patches that test fine and then break in production.
Patch decision authority. Some patches require business decisions (deploy now vs. defer to next release window, accept a known regression in exchange for patching a vulnerability). The merchant needs a named decision-maker who can respond within the patch SLA timeline.
Budget for emergency patches. Out-of-band patches sometimes require expedited work that exceeds the standard retainer hours. The contract should have a mechanism for handling these without lengthy approval cycles.
Merchants who provide these get the patch program they pay for. Merchants who don’t sometimes blame the agency for patch program failures that were really merchant-side blockers.
The honest conversation about why this matters
The cost of a breach on a mid-market Adobe Commerce store typically includes: notification costs to affected customers, credit monitoring offers, regulatory fines, PCI penalties, payment processor surcharges, forensic investigation costs, lawsuit settlements, and reputation damage to long-term customer trust.
A representative breach for a $20M Adobe Commerce store affecting 50,000 customer records typically costs $400K-$1.5M in direct costs, plus 6-18 months of recovery work. The annual cost of a real patch program for the same store is $40K-$120K.
The merchants who do the math on this consistently invest in real patch programs. The merchants who do not do the math are the ones who eventually become case studies. Bemeir runs patch management as a deliberate practice for our clients, with the SLAs, testing surfaces, and reporting cadences described above. The investment is small relative to what it prevents, and the merchants who treat it seriously sleep meaningfully better. The right time to set up a real patch program is before the breach, not after.
