krobins.dev
12 May 2026

Magento 2.4.x admin hardening checklist

A practical hardening checklist for Magento 2.4.x admin panels: URL randomisation, 2FA, IP allowlisting, session controls, and the config flags most installs skip.

The Magento admin panel is the highest-value target on most ecommerce servers. It holds customer PII, payment flow configuration, and usually enough privilege to rewrite storefront templates. A compromised admin is a compromise of the store.

Most of the work here is configuration, not code. None of it requires a developer to be on retainer. What it does require is someone to sit down and actually do it, because the defaults are not where you want them.

This is the checklist I work through on every Magento 2.4.x install I touch. It covers the settings that matter most, ordered roughly from highest impact to lowest friction.

1. Randomise the admin URL

Out of the box, Magento installs at /admin. Every automated scanner on the internet knows this. The first thing to do is move it.

Set a custom path in app/etc/env.php:

'backend' => [
    'frontName' => 'your-secret-path-here',
],

Or via CLI during setup:

bin/magento setup:config:set --backend-frontname=your-secret-path-here

Pick something that is not obvious. Not admin2, not manage, not your domain name. A short random string is fine. This does not replace authentication but it eliminates the noise of automated brute-force attempts hitting the login page at all.

After changing the path, update any bookmark references and make sure your WAF or CDN rules are adjusted if you use them to restrict /admin access.

2. Enable and enforce two-factor authentication

Magento 2.4.0 shipped with 2FA bundled and enabled by default. If you are on 2.4.x and 2FA is disabled, someone turned it off deliberately.

Check the current state:

bin/magento module:status Magento_TwoFactorAuth

If it shows Module is disabled, re-enable it:

bin/magento module:enable Magento_TwoFactorAuth
bin/magento setup:upgrade

The bundled module supports Google Authenticator, Duo, Authy, and U2F. Google Authenticator is the path of least resistance for small teams. Duo is worth the overhead if you have more than three or four admin users.

Force 2FA at the system level so individual users cannot bypass it:

bin/magento config:set twofactorauth/general/force_providers google

Do not allow users to opt out of 2FA via the admin panel. The setting exists; do not use it in production.

3. Allowlist admin IP addresses

If your admin users always connect from known IP ranges (office, VPN), enforce that at the application level. Magento 2 does not have a built-in IP allowlist for the admin panel, so this sits at the webserver or infrastructure layer.

Nginx example, restricting the admin path to specific IPs:

location ~* ^/your-secret-path-here {
    allow 203.0.113.10;
    allow 198.51.100.0/24;
    deny all;
}

Apache equivalent using .htaccess or <Location>:

<Location /your-secret-path-here>
    Require ip 203.0.113.10
    Require ip 198.51.100.0/24
</Location>

If your team connects from dynamic IPs, a VPN with a fixed egress address is the right solution. It keeps the allowlist manageable and does not require updating firewall rules every time someone works from a coffee shop.

A WAF (Cloudflare, Sucuri, etc.) can handle this at the CDN layer if you prefer not to touch the webserver config directly.

4. Configure account lockout

Brute-force protection against the login form. Set it in the admin under Stores > Configuration > Advanced > Admin > Security, or via CLI:

# Lock account after 5 failed attempts
bin/magento config:set admin/security/lockout_failures 5
 
# Lock for 30 minutes
bin/magento config:set admin/security/lockout_threshold 30
 
# Require a CAPTCHA after 3 failed attempts (see section 5)
bin/magento config:set admin/security/captcha_timeout 3

The defaults here are loose. Five attempts and a 30-minute lockout is a sensible starting point. Reduce the attempt count if you have a small, known set of admin users.

Lockouts can be cleared in the admin under System > All Users or via the database if you lock yourself out. Keep note of how to reset it before you deploy changes.

5. Enable CAPTCHA on the admin login form

Magento includes a built-in CAPTCHA for the admin login. It is off by default. Turn it on:

Stores > Configuration > Advanced > Admin > CAPTCHA

Set:

  • Enable CAPTCHA in Admin: Yes
  • Forms: Admin Login, Admin Forgot Password
  • Displaying Mode: After number of attempts to login (set to 1 or 3)
  • Number of Unsuccessful Attempts to Login: 3

The built-in CAPTCHA is a simple image-based challenge. It is not as robust as reCAPTCHA but it is self-hosted, requires no third-party dependency, and adds meaningful friction to automated attacks.

If you want reCAPTCHA instead, Magento has a separate Magento_ReCaptchaAdmin module. Enable it and configure your API keys:

bin/magento module:enable Magento_ReCaptchaAdmin
bin/magento config:set recaptcha_backend/type_for/user_login recaptcha_v3

For most installs the built-in CAPTCHA is sufficient. Add reCAPTCHA if you have had actual brute-force incidents or if your compliance requirements call for it.

6. Tighten session lifetime and security settings

Sessions that never expire are sessions that can be hijacked. The relevant settings live under Stores > Configuration > Advanced > Admin > Security:

# Session lifetime: 900 seconds (15 minutes) is aggressive but appropriate for
# high-privilege admin sessions. Default is 900 in 2.4.x but check it.
bin/magento config:set admin/security/session_lifetime 900
 
# Validate user's HTTP_X_FORWARDED_FOR header — helps detect session theft
# across network changes. Disable only if you use a proxy/CDN that rewrites it.
bin/magento config:set admin/security/validate_session_ip_address 1
 
# Invalidate sessions after password change
bin/magento config:set admin/security/use_security_key 1

The security key (use_security_key) adds a form key to every admin request and validates it server-side. It should be 1. If you have a custom integration that posts to admin endpoints without the form key, fix the integration.

7. Rotate the encryption key

Magento stores payment data, API credentials, and other sensitive values encrypted in the database using a symmetric key defined in app/etc/env.php. The default key is generated at install time and is often never rotated.

Rotate it:

bin/magento encryption:key:change

This re-encrypts all stored values with the new key and updates env.php. Take a database backup first. Do not skip the backup.

Rotation cadence: annually is a reasonable baseline. Also rotate if a developer with access to the server leaves, if you suspect a breach, or if env.php was ever committed to version control (it should not be, but it happens).

If env.php has ever been in your git history, consider all stored encrypted values compromised regardless of key rotation. Audit what is stored and change the underlying credentials (API keys, payment credentials, etc.) directly.

8. Restrict the REST and GraphQL admin APIs

Magento exposes REST and GraphQL endpoints that can accept admin-scope tokens. If you do not use these integrations, restrict or disable them.

Check active integrations:

bin/magento integration:list

Disable integrations you do not recognise or no longer use:

bin/magento integration:delete <integration-name>

For REST, you can scope token access in System > Integrations. Each integration should have the minimum resource access it needs. If an integration only reads catalogue data, it should not have access to customer PII or order management.

Admin tokens issued via /V1/integration/admin/token should not be used in production integrations. Use scoped integration tokens instead. Admin tokens do not expire by default in older Magento versions; check your configuration:

bin/magento config:show oauth/access_token_lifetime/admin

Set an explicit lifetime if it is empty:

bin/magento config:set oauth/access_token_lifetime/admin 4

That is 4 hours. Adjust to match the longest reasonable session for your actual integrations.

9. Audit admin user accounts

Run through the user list and remove anything that should not be there:

bin/magento admin:user:list

Common problems:

  • Developer accounts from old agencies left active
  • Generic admin or test accounts created during setup that were never removed
  • Former employees still with active credentials

For users that remain, check their roles match what they actually do. A customer service rep does not need access to payment configuration. A content editor does not need system configuration access.

Magento's role system maps to resources. Review them under System > User Roles and make sure no custom role has been granted All resources unless it genuinely needs them.

10. The config flags most installs skip

These are small settings that rarely get set because they require digging into the admin config tree. They matter.

Disable the Magento admin demo notice: Not a security issue, but it tells you the install was set up carefully.

Disable admin usage report collection if not wanted:

bin/magento config:set admin/usage/enabled 0

Set the admin base URL explicitly if you are behind a load balancer or reverse proxy. Magento can construct URLs incorrectly in these environments, which leads to CSRF protection failures:

bin/magento config:set web/secure/base_url https://your-domain.com/

Verify the content security policy is not reporting only. Magento 2.4.x ships with a CSP in report-only mode. It will not block anything. Moving it to enforce mode requires testing your storefront and admin against it, but the goal is to get there:

bin/magento config:set csp/mode/storefront/report_only 0
bin/magento config:set csp/mode/admin/report_only 0

Do not flip this without reviewing your CSP report logs first. A poorly configured enforced CSP will break your own checkout. Test in staging.

Turn off the default admin account if your setup wizard created one with a predictable username. Magento does not enforce a minimum entropy on usernames at setup time.

What this checklist does not cover

This covers the Magento-layer controls. It does not cover:

  • Server hardening (SSH key-only auth, firewall rules, fail2ban, OS patching)
  • PHP configuration (disable_functions, open_basedir, expose_php)
  • Database access controls (dedicated DB user with scoped grants, no root for the app)
  • Composer dependency auditing (composer audit)
  • File permission hardening (var/, pub/, app/etc/env.php permissions)
  • Monitoring and alerting (admin login anomalies, unexpected cron jobs, file integrity)

Those are each their own subject. They matter as much as what is here.

If you run a Magento store and want someone to run through this properly rather than just read about it, the security audit work I do includes a structured review of admin panel configuration alongside server and code-level controls. I have done this enough times to know which of these findings to expect on a store that has been running for a few years without a dedicated security review.

For context on the kind of work this feeds into, the JTX Fitness and Ice Headshop case studies cover long-running Magento engagements where ongoing security maintenance was part of the scope.