Shared admin logins that remain when you use Okta or Microsoft Entra ID

Having Okta or Microsoft Entra ID doesn’t make every shared admin login go away. Start by sorting out which ones your identity provider already handles, then decide who takes care of the rest.

What the identity provider covers

An identity provider holds one account for each employee. People sign in to it once and then open the apps connected to it. Microsoft’s documentation describes this as signing in with the same organizational account people already use for their desktop or email. Each person sees only the apps they’re assigned. Admins decide who can use which app and can assign apps to whole groups.

Shared admin logins it can handle

Some admin consoles don’t support SAML, the standard that lets an app accept sign-in from an identity provider. For those, both products can store a username and password and fill them in for the user. Okta calls this Secure Web Authentication (SWA). Entra ID calls it password-based single sign-on.

On records, Okta’s Application Access query reads the system log to show when users accessed each app. In Okta, unassigning an app removes it from the person’s My Apps page and removes their access. In Entra ID, a group’s owners can add or remove members without going through an admin.

Entra ID adds two limits. The app needs an HTML sign-in page, the usual page with username and password fields. Each user can have at most 48 of these logins. Entra ID also lets you require MFA for people who use shared accounts, and for some apps it can change the password on a schedule. Within these limits, the identity provider handles shared admin logins on its own.

Where gaps remain

The gaps are the cases that fall outside the table.

1. People without an account in the identity provider. Examples include part-time admins, short-term staff and outside engineers. Okta needs an Okta account for each person, and Entra ID needs a license for each. So it comes down to whether you’ll add an account and a license for everyone who touches the console.
2. What happens after sign-in. The records in the table show who opened which app and when. The Okta and Microsoft pages cited here don’t describe recording what someone did inside the console after that. If an auditor asks for that, you need the console’s own activity log or another tool.
3. The console’s own two-step codes. The same pages don’t say how the fill-in handles a console that asks for an authenticator-app code after the password. What Entra ID documents is MFA at the Entra ID sign-in, which is a separate check.

Both products also depend on a browser extension on every computer people use.

How to split the work

• Employee accounts, and apps that connect through SAML, belong to the identity provider. That’s where you confirm who people are and turn access on and off when they join or leave.
• Shared admin logins where everyone who uses them is in the identity provider, and “who signed in, and when” is enough, belong to its password fill-in. It needs nothing extra and keeps the password hidden.
• Shared admin logins used by people outside the identity provider, or where you need a record of what happened after sign-in, need something else. That can be a sign-out log, a privileged access management (PAM) product or an access tool.

If you can give everyone a personal account, and manage sign-in, joining, leaving and permissions through the identity provider, it’s all you need. For the cases it doesn’t cover, Managing privileged accounts lays out the choices. Ways to manage shared SaaS admin accounts, compared compares them point by point.