Magento admin hardening checklist for 2026

Attackers who reach the Magento Admin can add a skimmer to checkout, export customer data or create a hidden admin user for later. Most successful compromises start with a weak point that a checklist would have caught: a reused password, an old extension, a missed security patch or a forgotten test account.

Use the list below as an audit. Each item includes what to check and, where it helps, the exact command. Run commands from the Magento root as the file system owner, and test on staging first.

1. Enforce two-factor authentication for every admin user

Since 2.4.0, the Magento_TwoFactorAuth module is enabled by default and requires 2FA before an admin user can sign in through the UI or web API. Supported providers include Google Authenticator, Duo Security and U2F hardware keys such as YubiKey. In 2.4.9, admin users only need to configure one of the enabled providers to get in.

Check that the module has not been disabled, often by a developer during local testing:

bin/magento module:status Magento_TwoFactorAuth
bin/magento security:tfa:providers
# Force specific providers (comma-separated codes)
bin/magento config:set twofactorauth/general/force_providers google,u2fkey

If someone loses their device, reset only their provider instead of disabling the module:

bin/magento security:tfa:reset <admin_username> google

2. Use a non-default admin path

Adobe recommends against admin, backend or any common word. A random path will not stop a targeted attacker, but it removes you from the bulk of automated login attempts.

bin/magento info:adminuri
bin/magento setup:config:set --backend-frontname="ops_7k2m9x"
bin/magento cache:flush

The admin URI accepts letters, numbers and underscores only.

3. Restrict admin access by IP

Adobe’s security best practices recommend IP allowlisting. Magento has no built-in admin IP filter, so do it at the web server, load balancer, CDN or WAF. An Nginx example:

location ~* ^/(index\.php/)?ops_7k2m9x {
    allow 203.0.113.10;     # office
    allow 198.51.100.0/24;  # VPN range
    deny all;
    try_files $uri $uri/ /index.php$is_args$args;
}

Test this carefully. The PHP handler block in your Nginx config must still process the allowed requests. If your team works remotely, route admin access through a VPN rather than maintaining a long list of home IPs.

4. Tighten Admin security settings

Under Stores > Configuration > Advanced > Admin > Security, review session lifetime, lockout, password lifetime and account sharing. You can set them from the CLI so they live in version control through config.php or env.php:

bin/magento config:set admin/security/session_lifetime 900
bin/magento config:set admin/security/lockout_failures 5
bin/magento config:set admin/security/lockout_threshold 30
bin/magento config:set admin/security/password_lifetime 90
bin/magento config:set admin/security/password_is_forced 1
bin/magento config:set admin/security/admin_account_sharing 0
bin/magento config:set admin/security/use_form_key 1

PCI DSS v4.0.1 Requirement 8.3.6 calls for passwords of at least 12 characters (8 if the system cannot support 12). Magento’s historical admin minimum is 7. Adobe Commerce 2.4.9 makes the admin minimum password length configurable in the same Security section, which is one more reason to plan that upgrade.

Also enable reCAPTCHA for the admin login and forgot-password forms under Stores > Configuration > Security > Google reCAPTCHA Admin Panel.

5. Apply least privilege to roles and integrations

• Give each person their own account. No shared “marketing” or “agency” logins.
• Create roles in System > Permissions > User Roles that cover only the resources each team needs. Content editors do not need access to System or Stores > Configuration.
• Remove or deactivate accounts for former staff and agencies on the day access ends.
• Scope API integrations to the minimum resources and rotate their tokens.

Review admin users every quarter. A quick query helps spot accounts nobody recognizes:

SELECT user_id, username, email, is_active, created, logdate
FROM admin_user
ORDER BY created DESC;

An unknown account created recently is a strong sign of compromise. Treat it as a security incident and start your response plan.

6. Keep Content Security Policy enforced on payment pages

Since 2.4.7, Adobe configures CSP in restrict mode by default for payment pages in both the storefront and the Admin, and in report-only mode everywhere else. Adobe made this change, along with Subresource Integrity support, to help merchants with PCI DSS 4.0 requirements. Requirement 6.4.3 asks for an inventory, authorization and integrity check for every script on payment pages, and Requirement 11.6.1 asks for change and tamper detection on payment pages. Both became effective on 31 March 2025.

The common mistake is switching checkout back to report-only because an extension’s inline script broke. Fix the script instead by allowlisting it, using SecureHtmlRenderer or a nonce from CspNonceProvider. Check that no module has overridden the default:

grep -rn "report_only" app/code vendor/*/*/etc/config.xml | grep -v "vendor/magento"

For reference, restrict mode for the storefront checkout looks like this in a module’s config.xml:

<csp>
  <mode>
    <storefront_checkout_index_index>
      <report_only>0</report_only>
    </storefront_checkout_index_index>
  </mode>
</csp>

7. Patch on a fixed cadence

Adobe publishes regular security releases (for example, 2.4.8 received patches -p1 through -p5 between June 2025 and May 2026) and, when needed, isolated security patches outside the schedule. In September 2026 Adobe released APSB26-146, a critical fix for a vulnerability it said was being exploited in the wild, and advised merchants to rotate credentials as well as apply the hotfix.

A workable routine:

• Subscribe to Adobe security bulletins and the Commerce Security Scan notifications.
• Apply critical fixes within days.
• Check which patches are applied with the Quality Patches Tool:

vendor/bin/magento-patches status
composer audit

Stay on a supported release line. Standard support for 2.4.6 ended on 11 August 2026, according to Adobe’s lifecycle policy.

8. Make production code read-only

Run in production mode and remove write access from code directories so that a web-level exploit cannot easily drop files. Adobe’s documented command for a two-user setup:

bin/magento deploy:mode:show
find app/code lib pub/static app/etc generated/code generated/metadata var/view_preprocessed \
  \( -type d -or -type f \) -exec chmod g-w {} + && chmod o-rwx app/etc/env.php

Restore write access only during deployments, then lock it again.

9. Disable what you do not use

Every enabled module and endpoint is attack surface. List what is active, then disable modules you do not use after checking dependencies:

bin/magento module:status --enabled
bin/magento module:disable Vendor_UnusedModule
bin/magento setup:upgrade && bin/magento setup:di:compile

Also confirm that anonymous access to REST resources stays off:

bin/magento config:show webapi/webapisecurity/allow_insecure   # expect 0 or empty

Remove unused third-party extensions with Composer rather than leaving them disabled. Disabled code still ships with your release and still needs patching.

10. Monitor, log and back up

• Malware and integrity scanning. Adobe’s free Commerce Security Scan checks sites for known risks and malware. Server-side scanners such as Sansec eComscan look for malware, vulnerable extensions and unauthorized admin accounts in files and the database.
• Admin activity. Adobe Commerce includes the Admin Action Log. On Magento Open Source, ship web server and var/log logs to a central system and alert on admin logins from new IPs.
• Change detection. Alert on changes to checkout templates, CMS blocks and core_config_data entries that hold scripts.
• Backups. Keep encrypted database and media backups off the server, include app/etc/env.php (it holds your encryption key) in a separate secure vault, and test a full restore at least once a quarter.

Quick reference checklist

Frequently asked questions

Can I disable 2FA for developers on staging?

Many teams do on local machines, but keep it on for any internet-facing environment. Staging often holds a copy of production data and the same admin usernames, which makes it an attractive target.

Is a custom admin URL enough protection?

No. It reduces automated noise. Combine it with 2FA, an IP allowlist or VPN, lockout settings and monitoring.

Does CSP alone make my checkout PCI compliant?

No. CSP restrict mode and SRI help with script authorization and integrity on payment pages, but PCI DSS covers much more, and your scope depends on how you take payments. Confirm your obligations with your acquirer or QSA.

How fast should we apply Adobe security patches?

For critical bulletins, especially ones Adobe marks as exploited in the wild, aim for days. Regular security releases can follow your normal test-and-deploy cycle, as long as that cycle runs at least monthly.

Sources

• Adobe Experience League: Secure your Commerce site and infrastructure
• Adobe Experience League: Two-factor authentication
• Adobe Experience League: Display or change the Admin URI
• Adobe Experience League: Configure Admin security
• Adobe Developer: Content Security Policies
• Adobe Commerce 2.4.7 release notes
• Adobe Commerce 2.4.9 release notes
• Adobe Experience League: Released versions
• Adobe Experience League: Software lifecycle policy
• Adobe: Critical security update APSB26-146
• Adobe Experience League: File system access permissions
• PCI SSC: Payment page security and preventing e-skimming (6.4.3 and 11.6.1)
• SecurityMetrics: Password requirements in PCI DSS 4.0.1
• Sansec eComscan