Two-factor auth and admin access hardening in Magento 2

Part 3 of the Magento 2 security series — implementation-focused. The overview is at /blog/magento2-security.

The admin is the crown jewels

A storefront compromise is bad; an admin compromise is catastrophic — order manipulation, customer-data exfiltration, and arbitrary code deployment. Most admin breaches are not exploits of Magento itself but of weak credentials and missing second factors. This post hardens the admin surface.

Enforce 2FA for every provider

Magento's native Magento_TwoFactorAuth module supports TOTP, Duo, and WebAuthn. Do not leave it optional: enforce it so no admin account can authenticate with a password alone.

The enforcement is a config flag, but the operational discipline is what matters — every account, including service and integration accounts, needs a second factor or a dedicated mechanism (see below).

Provider choice and rotation

• TOTP (authenticator app) — universal, but a shared secret that can leak from a screenshot or backup. Rotate when staff leave.
• WebAuthn / hardware key — phishing-resistant and the strongest option for privileged accounts. Prefer it for superusers.
• Duo / push — convenient, but depends on the vendor being reachable; keep a fallback factor.

Rotate provider secrets on offboarding. A former developer's TOTP seed that still works is a standing backdoor.

Lock down by IP and role

2FA stops credential reuse; network and role controls stop everything else:

• Restrict admin by IP where the ops team has stable egress. A allowlist at the edge (or a Require ip in the web server) means an attacker needs both valid creds and a permitted network.
• Principle of least privilege roles. Do not grant Administrator to everyone. A content editor does not need the ability to install modules. Magento's ACL roles should mirror actual job functions.
• Separate integration accounts. API/CI integrations should authenticate via API tokens or app credentials with scoped ACL, not via a shared admin login. If a script "needs admin," that is a scope bug to fix, not a login to share.

The offboarding checklist

The breach path most teams ignore is the one that stays open:

• Disable the admin account on day one of departure.
• Revoke API tokens and integration credentials.
• Rotate the TOTP/WebAuthn secrets for any shared or reused enrollment.
• Review var/log / admin action log for the account's last activity.

Common mistakes

• "We'll enable 2FA later." Later is after the breach. Enforce before launch.
• One shared admin login for the whole agency. No accountability, no offboarding, no ACL. One account per human.
• Admin exposed on the default /admin with no IP limit. Even with 2FA, hiding and narrowing the surface reduces attack volume.
• Forgetting the API surface. Admin 2FA does not cover token-based API access; scope and rotate those separately.

What's next

Accounts and access are one layer; the code and its dependencies are another. The next post covers the supply-chain risk — Composer dependencies, CVEs, and how to patch without breaking the store.

Next in this series: Dependency supply-chain and CVE patching — /blog/magento2-security-dependencies