Magento admin security: hardening the backend without breaking the checkout
Most Magento compromises start in the admin: a guessed or reused password, an old account nobody removed, an extension with an admin route. Hardening the backend is cheap, and most of it is configuration. The one rule that matters for revenue: every change ends with a real order through the storefront.
Move and fence the admin
Change the admin path from `/admin` with `bin/magento setup:config:set --backend-frontname=<something>` and keep it out of robots.txt and public docs. It does not stop a targeted attack, but it removes you from the mass scans that try `/admin` on every Magento they find.
If your team works from fixed addresses or a VPN, allow only those IPs to the admin path at nginx or Cloudflare level. Put the rule in the web server, not in a Magento extension, so it holds even when Magento itself is broken.
Two-factor authentication
Magento 2.4 ships the `Magento_TwoFactorAuth` module, enabled by default. Keep it on, use Google Authenticator or a hardware key, and do not disable it on production because it is annoying on staging: use `bin/magento security:tfa:reset` per user instead.
Many hacked stores had 2FA disabled during an upgrade and never turned back on. Check it with `bin/magento module:status Magento_TwoFactorAuth` after every release.
Accounts, roles and sessions
Give every person their own admin user, remove leavers on their last day, and use roles: a content editor does not need System → Configuration or Payment Methods. Review the user list every quarter.
Set Stores → Configuration → Advanced → Admin → Security: session lifetime, lockout after failed logins, password lifetime and "Add Secret Key to URLs" on. Audit who changed payment settings with the admin action log (Adobe Commerce) or an extension that records config changes.
Patches, extensions and file integrity
Apply Adobe security patches within days, not at the next upgrade, and remove extensions you no longer use: unused code with an admin controller is still attack surface. The security patches guide covers how to test them.
Watch for new or changed files in `pub/`, `app/code` and the database tables that hold CMS blocks and config (`core_config_data`). Injected payment skimmers usually live there; see Magecart skimming.
Prove the checkout still works
Hardening changes headers, IP rules, cookies and caches. Any of them can block the payment provider callback, a payment iframe or the checkout itself. After each change place a test order, or let a monitor do it every hour.
Run the free Magento checkout test after a hardening change: it walks product, cart, shipping and payment in a real browser and shows the step where it stops.
Common questions
Is changing the Magento admin URL enough?
No. It cuts automated scans, but you still need 2FA, strong unique passwords, IP rules for the admin and prompt security patches.
Can I disable Magento 2FA?
You can, but you should not on production. Reset a single user with bin/magento security:tfa:reset instead of turning the module off.
Can hardening break the checkout?
Yes. Stricter headers, firewall rules or cookie settings can block payment iframes and callbacks. Run a real checkout test after each change.