The Magento and Adobe Commerce admin is secured in three layers: two-factor authentication, which is native and mandatory since version 2.4.0; single sign-on through Adobe Identity Management Services for Adobe Commerce; and role-based permissions that give each user only the access their job needs. Configure all three, then harden the controls beyond login.
The admin panel is the most valuable target on any store. One compromised admin account can place fraudulent orders, exfiltrate customer data, inject skimming code into checkout, or take the site down. Yet admin security is often the last thing a team hardens, left at “everyone is an administrator with the same password policy.” This runbook walks the controls that actually protect a Magento or Adobe Commerce backend, in the order a careful team should apply them.
Why admin access is the highest-value target
Attackers do not usually break Magento’s encryption. They log in. Credential stuffing, phishing an admin, and reused passwords from an unrelated breach are the common paths, and they all end at the same door: /admin. Once inside, an attacker with full rights owns the store. That is why the platform made two-factor authentication mandatory, and why access control is not an optional nicety on a Magento or Adobe Commerce build. The goal of everything below is simple: make a stolen password insufficient on its own, and limit what any single account can do.
Two-factor authentication: native and mandatory
Since Magento 2.4.0, two-factor authentication ships enabled by default and is required before any admin user can log in, through the UI or the web API. Adobe strongly advises against disabling the module, and there is no good reason to. Configure it rather than fight it.
The native module supports several second factors, so teams can standardize on what fits their security posture:
| Provider | What it is | Best for |
|---|---|---|
| Google Authenticator | Time-based one-time codes in an app | The simple default, no cost |
| Duo Security | Push-approval and enterprise policy | Teams wanting centralized control |
| Authy | Time-based codes with multi-device backup | Small teams sharing device access |
| U2F / WebAuthn keys | Hardware security keys (YubiKey and similar) | Highest assurance, phishing-resistant |
Hardware keys are the strongest option because they cannot be phished the way a typed code can. For most merchants, Google Authenticator is a fine baseline, and stepping the most privileged accounts up to a WebAuthn key is a cheap, high-value upgrade. Configure the requirement per admin role so sensitive roles carry a stricter factor than a read-only reporting login. Enterprise second-factor tools such as Duo sit in Bemeir’s technology partner ecosystem, so standardizing on one across a team is a configuration decision rather than a custom build.
Adobe IMS single sign-on: when Adobe ID replaces native 2FA
Adobe Commerce customers have a second path: Adobe Identity Management Services (IMS). With IMS enabled, admins sign in with their Adobe credentials, and the platform’s native 2FA is disabled because Adobe IMS handles authentication for the session. This is the right model for organizations that already run Adobe accounts and want central control over who can reach the store, with the enterprise identity policies (SSO, provisioning, deprovisioning) applied at the Adobe layer. Follow Adobe’s two-factor authentication guidance to decide between native 2FA and IMS, and do not run half-configured versions of both. Pick one authentication model per environment and apply it consistently.
For merchants on Magento Open Source, IMS is not available, so native 2FA is the model. The practical difference between the two editions, including where identity and B2B features diverge, is laid out in the comparison of Adobe Commerce and Magento Open Source.
Role-based permissions: least privilege in the admin
Authentication proves who someone is. Authorization decides what they can do, and it is where most stores are dangerously loose. Magento’s admin uses roles built from a resource tree (an access control list). Each role grants or denies specific resources, and each user is assigned one role. The security principle is least privilege, the OWASP-recommended default for authorization: give every account the minimum access its job requires, and nothing more.
In practice that means:
- A content editor gets CMS, catalog, and category resources, not system configuration, not customer data export, not the ability to add admin users.
- A customer service agent gets orders, returns, and customer view, not price rules or payment configuration.
- A developer or agency gets the technical resources they need for the engagement, scoped and time-bound, not a permanent super-admin login shared across a team.
- Finance and reporting get read access to the reports they need, nothing that can change store state.
Reserve full administrator rights for a tiny number of named individuals, never a shared account. When an agency finishes an engagement, its access is revoked, not left active. This discipline is a standing line item in any serious Magento technical audit, because loose roles are one of the most common findings.
Beyond login: the hardening controls that finish the job
Two-factor and roles are the core, but a hardened admin uses several more controls that cost little and close real gaps:
- A custom admin URL. Move the admin off the default path so opportunistic bots hammering
/adminnever find the login form. This is obscurity, not security on its own, but it cuts noise and slows automated attacks. - Admin CAPTCHA. Enable it on the admin login and forgot-password forms to blunt credential-stuffing scripts.
- IP allowlisting. Restrict admin access to known office and VPN addresses at the web server, Varnish, or WAF layer. The admin does not need to be reachable from the entire internet.
- Session and password policy. Set a sensible admin session lifetime, enforce password complexity and rotation, and cap failed-login attempts so accounts lock before a brute-force succeeds.
- The admin actions log. Adobe Commerce records who changed what in the admin. Review it, because attribution is how you catch misuse and scope an incident. This is also where a slow, cluttered admin hides problems, so keep the backend healthy using the steps in speeding up the Magento admin.
Layered on top of a disciplined patching routine, these controls turn the admin from an open target into a hard one. The wider hardening context, including PCI DSS 4.0.1 obligations and the CosmicSting lesson, sits in the Adobe Commerce security and PCI compliance runbook.
Managing agency and client teams together
Real stores are run by more than one organization: an in-house team, an agency, sometimes a second specialist agency, and various contractors. Admin security has to survive that reality. Give each organization its own named accounts, never a shared “agency” login, so access can be granted and revoked per person and every action is attributable. Scope each role to the engagement, review the user list quarterly, and remove accounts the day a contract ends. A note about theme choice: Hyva does not change any of this. The Hyva frontend replaces the storefront theme, not the admin, so admin security is identical whether you run Luma or Hyva. As a Hyva Gold Partner and full-service Magento shop, Bemeir sets these controls up as part of onboarding, and the practice of working as a named extension of the client team is described on the about page; the ongoing side is covered in a real Magento support and maintenance plan.
The same discipline applies on any platform
Admin access control is not a Magento-only concern. The principles here, mandatory strong authentication, least-privilege roles, named accounts, and prompt deprovisioning, apply to every commerce platform a merchant might run. On Shopify, staff permissions and two-step authentication play the same role. On BigCommerce and Shopware, user roles and admin access controls exist for the same reason. The platform changes the settings screens, not the goal: make a stolen credential useless on its own, and make sure no single account can do everything. A team that internalizes the model carries it across whatever stack it operates.
If an admin account is compromised
Prevention is most of the work, but a plan for the bad day matters too. If you suspect an admin account is compromised, act in a fixed order: disable the account immediately, force a password reset and re-enrollment of the second factor for every admin, and review the admin actions log to scope what the account touched. Rotate integration and API credentials the account could have seen, check for new or modified admin users and for unexpected changes to payment or checkout configuration, and confirm no unauthorized code was added. Then patch whatever let them in. The speed of the first three steps is what limits the damage, which is why the actions log and a current user list are worth keeping clean before you ever need them.
Frequently asked questions
Can I disable two-factor authentication in Magento?
Technically yes, through a command or a bypass module, but you should not. 2FA is enabled by default and mandatory from Magento 2.4.0 onward, and Adobe advises strongly against disabling it. If 2FA is inconvenient, fix the workflow (standardize on an app or hardware key), do not remove the protection. The one legitimate exception is Adobe Commerce with IMS, where Adobe handles authentication instead.
What is the difference between native 2FA and Adobe IMS?
Native 2FA adds a second factor (an authenticator app or hardware key) on top of the Magento password, and it works on both Open Source and Adobe Commerce. Adobe IMS is single sign-on with Adobe credentials, available only on Adobe Commerce; when it is enabled, native 2FA is turned off because Adobe handles authentication. Choose one model per environment.
How should I set up admin roles for an agency?
Create named accounts for each agency user, never a shared login, and assign a role scoped to exactly the resources the engagement needs. Time-box the access, review it regularly, and revoke it when the contract ends. Full administrator rights should belong to a small number of named individuals, not a team-wide account.
Does moving to Hyva affect admin security?
No. Hyva is a frontend theme that changes the storefront, not the admin panel. Two-factor authentication, roles, and every other admin control work identically before and after a Hyva migration. Admin security and frontend performance are separate concerns.
Is a custom admin URL enough to secure the backend?
No. Moving the admin off the default path reduces automated bot noise, but it is obscurity, not a control. Real security comes from mandatory 2FA, least-privilege roles, IP allowlisting, CAPTCHA, and session and password policy. Treat the custom URL as one small layer in a stack, never the whole defense.
Securing the Magento and Adobe Commerce admin is not a single setting. It is authentication that survives a stolen password, authorization that limits what any account can do, and a set of hardening controls that close the remaining gaps. Apply the three layers in order, keep the user list clean, and the highest-value target on your store stops being the easiest one.
