What Security Service Should Magento Agencies Offer?

Executive finding

Magento agencies should sell security maintenance ownership, beginning with a paid evidence review and continuing with a defined patch, access, monitoring, and incident-readiness routine.

The strongest offer is not a public vulnerability scan or a one-time security badge. RN-007 found that public technology data usually cannot resolve exact Magento patch status. RN-008 found uneven public browser-security signals, but those signals cannot establish whether a store is vulnerable. Together, the studies reveal the more valuable problem: many merchants need someone to maintain an accurate inventory, turn new security information into decisions, deploy and verify changes, and preserve evidence that the work happened.

This is a recurring operational service. It fits an agency because the work touches the application, extensions, custom code, deployment process, CDN, hosting, accounts, and checkout integrations. It also gives the client something concrete: named responsibilities, dated evidence, response targets, and fewer unknowns.

The story worth telling

We bought the BuiltWith Magento data expecting to find a list of old or insecure stores. The data refused to give us that easy answer.

Thousands of legacy version signals are still visible, but a public label such as “Magento 2.4” is too broad to determine support or patch status. In the next study, nearly every responding site used HTTPS, while HSTS, CSP, cookie attributes, and other public controls appeared unevenly. Those observations were useful, but none proved that a merchant was secure or exposed.

The failed shortcut pointed to the real agency opportunity. A merchant does not primarily need another outside score. The merchant needs an accountable team inside the process: a team that knows what is installed, watches the relevant advisories, understands which updates apply, tests them against the customized store, deploys them safely, checks the result, and knows what to do when something looks wrong.

Security becomes valuable when it is maintained as evidence and routine, not presented as fear.

1. Why this is an agency problem

Adobe Commerce on cloud infrastructure uses a shared-responsibility model. Adobe maintains the core platform and parts of the managed infrastructure, while the merchant remains responsible for areas including custom code, third-party integrations, supported dependencies, access, applying application patches, monitoring, and incident response. Adobe explicitly states that issuing core updates is Adobe's responsibility while applying those updates to the merchant's customized application is the merchant's responsibility. Adobe Commerce shared responsibility model

The boundary differs by deployment model. Adobe Commerce as a Cloud Service removes much of the manual infrastructure and application-patching burden, while the customer still manages data, access, storefront choices, and customer-controlled components. An agency must identify the product and hosting model before assigning responsibilities. Adobe Commerce as a Cloud Service security overview

For Adobe Commerce on cloud infrastructure, on-premises deployments, and Magento Open Source, customized code and operational ownership remain substantial. These responsibilities often cross company boundaries:

• Adobe or the open-source project maintains core software.
• A host or cloud provider maintains some infrastructure.
• Extension vendors maintain their packages.
• A payment provider controls part of checkout.
• The merchant controls people, policy, and business decisions.
• An agency often controls code, deployment, configuration, and technical investigation.

Risk grows in the gaps between those parties. An agency can create value by documenting the boundary and making sure every important task has an owner, trigger, deadline, and evidence record.

2. Security work is a continuous release discipline

Adobe's security center listed four Adobe Commerce security bulletins in 2026 by the research date: APSB26-05 in March, APSB26-49 in May, APSB26-73 in July, and APSB26-92 in August. The August bulletin addressed critical, important, and moderate vulnerabilities and recommended updating to the applicable new version. Adobe Commerce security bulletins, APSB26-92

This does not mean every merchant needed four full upgrades. It demonstrates that security decisions recur. The appropriate response depends on product, version, installed modules, earlier patches, deployment model, and entitlement.

Adobe now distinguishes full security patch releases from isolated security patch files. Isolated patches are non-cumulative and may require the latest -p release plus earlier isolated fixes. For example, Adobe's August 2026 instructions required particular base patch levels and, for several release lines, the matching July isolated patch first. Adobe security patch release notes, August 2026 patch instructions

The operational lesson for an agency is simple: “Magento version” is not enough. Patch applicability needs a maintained ledger.

3. Evidence from RN-007 and RN-008

RN-007 compared two BuiltWith exports dated August 24, 2026:

The lists were not nested, and the general-only group contained Hyvä signals. Therefore, subtraction could not identify Magento 1. Public version pages showed thousands of legacy-version detections, but their totals could overlap and did not resolve current patch levels. The defensible conclusion was a version-visibility gap, not a percentage of insecure stores.

RN-008 then made one passive homepage request to a purposive sample of 100 domains. Eighty-five returned an HTTP response. Among those responses:

The higher-signal commercial group used several headers more consistently than the general and long-tail groups. Yet a header can be present and weak, absent but replaced by another control, or different on checkout and account routes. The result showed uneven public hygiene, not a vulnerability rate.

These studies support a two-step agency motion:

1. Use public data only to frame questions and market patterns.
2. Use merchant-authorized evidence to make security decisions.

4. The recommended service: Magento Security Maintenance

The service should have an entry engagement and a recurring phase.

Phase A: Security Maintenance Baseline

This is a bounded, paid assessment. Its purpose is to replace unknowns with an agreed operating record.

Minimum scope:

1. Responsibility map — identify the merchant, agency, host, Adobe, payment provider, and extension-vendor responsibilities.
2. Software inventory — record product, edition, exact core and patch level, PHP, database, search, cache, queue, web server, Composer dependencies, extensions, and custom modules.
3. Support mapping — map each maintained component to a vendor, support status, advisory channel, and planned replacement or update path.
4. Access review — review Commerce Admin, cloud, repository, deployment, SSH, CDN, DNS, monitoring, and vendor access; record owners and stale accounts.
5. Patch process review — document how advisories are received, assessed, tested, approved, deployed, rolled back, and verified.
6. Public control review — validate HTTPS behavior, HSTS, CSP, frame controls, cookie behavior, information disclosure, and CDN/WAF configuration on relevant routes.
7. Monitoring and incident review — identify logs, alert ownership, file or page-change monitoring, backup evidence, restore testing, escalation contacts, and evidence-preservation steps.
8. Prioritized plan — give every finding an owner, evidence, business context, action, and target date.

The deliverable should avoid a mysterious numeric grade. Use operational statuses:

“Not verified” is especially useful. It lets the agency report uncertainty without labeling it a vulnerability.

Phase B: Recurring Security Maintenance

The recurring service keeps the baseline current. A practical scope can include:

• advisory monitoring and applicability decisions;
• monthly software and extension inventory reconciliation;
• patch and dependency planning;
• staging deployment and regression checks for critical commerce journeys;
• production deployment and post-release verification;
• account and privileged-access review;
• security scan, log, WAF, and integrity-alert review;
• public-header and certificate drift monitoring;
• backup and restore evidence checks;
• incident contact and runbook maintenance;
• a dated client report showing decisions, open items, and completed work.

The cadence should follow the event. A critical applicable advisory cannot wait for a monthly meeting. Routine inventory and access work can run monthly or quarterly. Restore exercises and incident simulations may run less frequently. The contract should define the trigger, response target, maintenance window, approval owner, emergency path, and exclusions.

5. A minimum control register

Adobe's current best-practice guidance prioritizes MFA, Admin protection, least privilege, current releases and patches, protected configuration, security scans, HTTPS, and WAF use. Adobe also recommends ongoing log review and file-integrity monitoring during incident recovery. Adobe security best practices, Adobe incident-response guidance

Adobe provides a Security Scan Tool for Adobe Commerce and Magento Open Source sites, with scheduled and on-demand checks for known risks and malware. It can be one input to the service, but it does not replace inventory, testing, ownership, or incident readiness. Adobe Commerce Security Scan

6. Checkout deserves its own workstream

Ecommerce security is broader than Magento patching. Payment pages can load scripts from the theme, tag manager, analytics, personalization, consent, chat, fraud, and payment services. That makes script ownership and change detection a business process as well as a technical control.

PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 address authorization, integrity, inventory, and change or tamper detection for payment-page scripts and headers. Applicability depends on the merchant's payment implementation and assessment scope. The agency can maintain technical evidence and coordinate remediation, but should not claim to certify PCI compliance unless it has the appropriate role and qualifications. PCI SSC ecommerce guidance, PCI SSC SAQ A clarification

A checkout workstream can include:

• an inventory of browser-loaded scripts and business owners;
• removal of unnecessary scripts from payment pages;
• review of CSP and integrity controls where technically appropriate;
• monitoring for unauthorized page or header changes;
• documented approval for tag-manager changes;
• evidence for the merchant's assessor or compliance team.

The agency should confirm scope with the merchant and its payment/compliance specialists before making compliance statements.

7. What the agency is actually selling

The agency is selling four outcomes:

1. Visibility — the merchant knows what it runs and which facts remain unresolved.
2. Ownership — every recurring task and urgent decision has a named party.
3. Change capability — the team can test and deploy security work without improvising around customizations.
4. Evidence — the merchant can show what was reviewed, decided, changed, and verified.

These outcomes are more defensible than “we keep you secure.” No agency can remove all risk. The contract should promise activities and response processes the agency can control.

The best initial audience is usually existing clients. The agency already understands their customizations, deployment path, and business calendar. A baseline can also be used during a new-client takeover because unknown ownership and undocumented extensions are part of takeover risk.

8. Boundaries that protect the client and the agency

• Public observations should be used for research or an invitation to verify, not to accuse a named merchant of being vulnerable.
• Intrusive testing requires explicit authorization, an agreed target list, timing, method, contacts, and stop conditions.
• A maintenance review is not a penetration test unless the scope, personnel, method, and contract make it one.
• Security Scan, WAF, CDN, and managed hosting are inputs. None removes the need to maintain application and extension state.
• An agency should not promise 24/7 monitoring or incident response unless staffing, escalation, and response targets make that service real.
• A patch deployment should include compatibility testing, rollback planning, and post-deployment verification.
• PCI scope and compliance conclusions belong with the merchant and its qualified compliance parties.
• Incident work should preserve evidence and coordinate with legal, insurance, payment, hosting, and specialist forensic teams when relevant.

9. How to validate the service before scaling it

The research does not establish pricing, agency margin, or willingness to buy. Validate the offer with a small number of real accounts.

1. Select five existing clients with different deployment and customization profiles.
2. Run the same baseline template for each client.
3. Measure delivery hours by control area and the time spent collecting missing evidence.
4. Record how many components lack an owner, supported version, advisory channel, or deployment record.
5. Ask which deliverables the merchant actually uses in budget, compliance, or operational meetings.
6. Test two scopes: baseline only, and baseline plus three months of recurring maintenance.
7. Refine response targets, exclusions, staffing, and price after observing the real workload.

Useful service metrics include inventory coverage, percentage of privileged accounts reviewed, applicable advisories assessed within the agreed target, approved patches deployed within the agreed target, restore exercises completed, unresolved actions by age, and time taken to identify the responsible party during an exercise.

Avoid using the raw number of findings as a performance metric. A team can produce more findings by changing the threshold, and fewer findings do not necessarily mean lower risk.

Method and limitations

This brief combines the purchased BuiltWith exports and the analyses documented in RN-007 and RN-008 with current Adobe, OWASP/MDN, and PCI SSC guidance accessed on September 3, 2026.

The BuiltWith data describes detected technologies and third-party commercial signals. It does not establish exact deployed versions, vulnerabilities, incidents, client demand, or agency revenue. The RN-008 measurement was a purposive 100-domain pilot with 85 HTTP responses, so its proportions must not be generalized to the complete Magento market.

Adobe documentation applies differently across Adobe Commerce as a Cloud Service, Adobe Commerce on cloud infrastructure, on-premises Adobe Commerce, and Magento Open Source. Product, edition, entitlement, hosting, payment architecture, and contracts must be verified for each merchant.

PCI references identify technical areas an agency may help maintain. They are not a compliance determination. No merchant interviews, pricing tests, legal review, insurance review, or penetration tests were performed for this research.