Does admin SSO replace the native Magento admin login?

No. With IdPlug Admin SSO the native login stays available, which is what you want for a break-glass account. The gain comes from giving staff SSO instead of a Magento password, so their access depends on the identity provider.

What happens when someone is removed from the admin group in Entra ID or Okta?

Their next sign-in no longer resolves to a mapped Magento role. Without role sync IdPlug refuses the sign-in; with role sync it changes the role only if the administrator's current role is one the mapping manages.

Can a new identity take over an existing Magento admin by email?

No. An identity that is not yet linked cannot claim an existing administrator by username or email, and no administrator is created without a matching role mapping.

What does IdPlug Admin SSO cost?

On Magento Open Source it is $249 for the first year and $299 a year after that; on Adobe Commerce $349, then $399. It requires the free IdPlug Customer SSO module.

Magento Admin Accounts Are an Offboarding Risk: How Admin SSO Fixes It

Every Magento store collects admin accounts. The developer who built the checkout, the agency that ran the last migration, the marketing contractor who needed access to CMS blocks for a week, two people from customer service who left last spring. Each one is a username and a password in Magento’s own admin_user table, and each one keeps working until somebody remembers to disable it.

That is the problem with the Magento admin in companies that already run an identity provider. Everybody’s laptop, email and VPN access ends on the last working day, because HR or IT disables one account in Microsoft Entra ID or Okta. The Magento admin is not part of that process, so it doesn’t end.

Why local admin accounts are a real risk

The Magento admin is the most powerful door into a store. An administrator can export customers, change payment settings, edit CMS content that appears on every page, and create more administrators. Most account-takeover incidents on Magento don’t need a software vulnerability. A valid admin login is enough.

Local accounts create four recurring problems:

Offboarding depends on memory. Disabling the Magento account is a separate, manual step, and it is the one most often forgotten, especially for agencies and freelancers who were never on the payroll.
Shared logins. Agencies and small teams share one “admin” account because creating users is tedious. Nobody can tell who did what, and changing the password breaks everyone.
Password reuse. A Magento admin password is one more password to remember, so it gets reused. A leak from any other service becomes a way into your store.
Role drift. Somebody gets the full Administrators role “temporarily” to fix one thing. Two years later they still have it.

Two-factor authentication helps with stolen passwords, but it does nothing for the account that should no longer exist.

What admin single sign-on changes

With single sign-on, people sign in to the Magento admin through the company identity provider, using SAML 2.0 or OpenID Connect. The store stops being the place that decides who you are. Your identity provider already knows who works for you, which team they are in and whether their account is still active.

IdPlug Admin SSO adds this to Magento Open Source and Adobe Commerce. Three design choices matter most for offboarding.

Access follows the identity provider

An administrator signs in through the provider, and IdPlug looks for a persistent link between that identity and a Magento administrator. Disable the person in Entra ID or Okta and they can no longer complete a sign-in, so they can no longer start an admin session. One action in one place.

An admin session that is already open lasts until Magento’s admin session lifetime runs out, as with any login. With Sign administrators out of the identity provider enabled, signing out of Magento also ends the session at the provider, so the next person at that browser has to authenticate again.

Roles are mapped explicitly, never guessed

Magento admin roles come from groups in your directory. You map exact group names or IDs to Magento roles, and the highest-priority match wins. Nothing is assigned implicitly:

Without a matching role mapping, no administrator is created.
An identity that is not yet linked cannot claim an existing administrator by username or email.
With Create administrators on first sign-in, a new team member in the right group gets a Magento admin account on their first sign-in, with the mapped role.

So “who can access the Magento admin, and with which role” becomes group membership in your identity provider. That is the place your IT team already reviews.

Role sync without locking anybody out

With Update administrators on each sign-in, IdPlug applies the mapped role, first name, last name and email every time someone signs in. That fixes role drift: move someone from “Store Admins” to “Content Editors” in Entra ID and their Magento role follows at the next sign-in.

The sync only changes administrators whose current Magento role appears in the provider’s role mapping. An account with a role the mapping doesn’t manage, such as a break-glass account with the built-in Administrators role, is refused rather than changed. Each change is logged as admin_account_synced. With sync turned off, an administrator whose groups no longer match a mapping is refused at sign-in.

Keep one break-glass account

Identity providers have outages, certificates expire and somebody eventually misconfigures a claim. Before you move a team to admin SSO, keep a tested break-glass Magento administrator outside federated administration. It should have a strong unique password and stored recovery details, and it should be used by as few people as possible. Admin SSO in IdPlug is an option next to the native login, not a replacement for it, so this account keeps working whatever happens at the provider.

The point of SSO is that everybody else signs in through the provider and has no Magento password to forget to revoke.

A rollout that doesn’t surprise anybody

Install the modules. Admin SSO builds on the free IdPlug Customer SSO module, which Composer installs as a dependency. If you already use it for customer sign-in, you reuse the same provider record.
Prepare the identity provider. Create the app registration or SAML application and send group claims. Our Microsoft Entra ID setup guide walks through it step by step, and the SAML vs OpenID Connect comparison helps you pick a protocol.
Map the roles. Start with one or two groups and the roles they need. Leave the Administrators role out of the mapping so break-glass access stays untouched.
Turn it on. Set the provider’s Applies to to include Administrator, then set Administrator SSO Mode under Stores > Configuration > Services > IdPlug > Administrator to Optional. It is Disabled by default.
Test with one person, then move the team over and remove the Magento passwords people no longer need.

The same subscription covers more than the admin

IdPlug Admin SSO is also the module for stores that need several identity providers, private storefronts for B2B customers or employees, and headless or PWA storefronts that sign customers in over REST or GraphQL. If you also want customer accounts created and deactivated automatically, add SCIM provisioning.

Pricing, screenshots and the full feature list are on the IdPlug Admin SSO page. If you would rather have someone set it up and test it with your identity team, we do that as part of our Magento development services.