# Managing privileged accounts

Privileged accounts can change a service's settings and anyone's access. Give admin rights to individuals where you can, and record who uses the shared ones.

Updated: October 16, 2026

Running privileged accounts comes down to three decisions: who holds admin rights, how people use the admin logins that stay shared, and how you record each use.

## What a privileged account is

NIST's glossary defines a privileged account as "a system account with the authorizations of a privileged user." A privileged user is someone trusted to perform security-relevant functions that ordinary users can't, such as creating accounts or changing who may access what. That reaches well beyond servers. The admin account for your cloud provider and the admin of a SaaS tool (software you use through the browser) both fit. This guide also counts the logins for your domain registrar and payment dashboards, because they can change a domain or where money goes. [What is a privileged account?](/guides/privileged-access/what-is-a-privileged-account) gives examples from AWS, Google Workspace and Microsoft 365.

## Why admin logins end up shared

There are two causes: how the service is built and how the team works.

Some services give you one admin account and no way to add another. AWS is one example: every AWS account has a single root user ([Managing the AWS root user and admin access for a team](/guides/privileged-access/aws-root-and-admin-accounts)). When several people need that account, they share it. The same happens with admin consoles that can't connect to your identity provider. An identity provider is a service such as Okta or Microsoft Entra ID that holds employees' accounts. It signs them in to many apps through single sign-on (SSO), one login that opens many apps. If a console can't accept that sign-in, people use the console's own username and password, and the team passes them around. Microsoft's Entra ID documentation names this case: a single local account with high privileges, used for setup, administration and recovery.

Work patterns add more. If on-call duty rotates, whoever is on shift signs in with the same admin login. The general problems with shared logins, such as changing the password when someone leaves, are covered in [Managing shared accounts](/guides/shared-accounts). They apply to admin logins as well, and they cost more there, because an admin login can change everyone else's access.

## What security frameworks ask for

These frameworks ask for two things: fewer people with admin rights, and a record of each use.

NIST SP 800-53 Rev. 5 is NIST's catalog of security controls. It is mandatory for federal information systems, and NIST encourages private organizations to consider it. Its least privilege control, AC-6, has enhancements aimed at admin accounts. AC-6(5) asks you to restrict privileged accounts to personnel or roles you define, which keeps day-to-day users away from privileged functions. AC-6(9) asks you to log the execution of privileged functions. Its discussion gives the reason: misuse by authorized users, or by attackers who took over an account, can do serious harm, and logging is one way to catch it. AC-6(7) adds a review, at a frequency you set, of who holds which privileges.

The CIS Controls, published by the Center for Internet Security, focus on how admin accounts are set up. Safeguard 5.4 restricts admin privileges to dedicated admin accounts. Everyday work such as email and browsing happens from the person's main, non-privileged account. Safeguard 6.5 requires multi-factor authentication (a second check beyond the password) for all admin access accounts, where supported.

Public companies run into this in their Sarbanes-Oxley Section 404 work on internal control over financial reporting. The SEC's 2007 guidance for management (Release 33-8810) lists access to programs and data among the IT general control areas management might consider. It doesn't use the term privileged account; admin access to financial systems is part of access to programs and data. [What a SOX audit asks about admin accounts](/guides/privileged-access/sox-itgc-privileged-access) covers which records to keep.

## Ways to run the admin logins that stay shared

There are four ways to let several people use an admin login that can't be split.

| Method | What it does | What it leaves | Fits when |
| --- | --- | --- | --- |
| A list plus a sign-out log | Records who borrowed the password and when | Whoever borrowed it still knows the password afterward | A few people use the account |
| The identity provider fills in the login (Okta Secure Web Authentication, Entra ID password-based SSO) | Signs people in without showing the password | Covers only people who have an account in the identity provider | Everyone who uses the account is in your identity provider |
| A privileged access management (PAM) tool | Puts a request, an approval, a time limit and a log in front of admin access | Coverage varies by product; check whether it includes admin consoles you open in a browser | You want an approval before each use |
| An access management tool | Enters the password for the person and records each use under the name of the person who signed in to the tool | Supported apps and devices vary by product | Some users have no account in your identity provider |

A list costs nothing, but the record holds only what people write down. It works best where the service itself logs what each sign-in did. Okta's Secure Web Authentication stores an app's login and fills it in for web apps that don't support standard sign-in protocols. When an admin sets one shared username and password, Okta doesn't let end users reveal it. Entra ID's password-based single sign-on also keeps the password from the people who use it, and admins can see who opened the app and when. Microsoft requires an Enterprise Mobility Suite or Entra ID P1 or P2 plan for each person who uses a shared account this way.

A PAM tool suits companies that want server and database admin accounts under the same approval process as everything else. [What is privileged access management (PAM)?](/guides/privileged-access/what-is-pam) explains what these tools do. You don't have to choose one method for every account; each account can use the one that fits it. Sharing through a password manager is covered in [What is a password manager?](/guides/shared-accounts/what-is-password-manager).

## How this fits with Okta or Entra ID

None of these methods replaces your identity provider. It still handles each employee's own account, sign-in to the apps that connect to it, and creating and removing accounts as people join and leave. What sits outside it is the subject of this guide. That means services that allow only one admin account, consoles that can't connect, and people with no account there, such as short-term staff or outside engineers. If you can give everyone a personal account and every service connects, the identity provider alone is enough. Use the table only for what's left over.

## Where to start

Start with a list of admin accounts. For each one, note the service and the admin username. Then note whether the service allows only one such account, whether it connects to your identity provider, who uses it today, and whether it's kept for emergencies only. [How to take inventory of shared accounts](/guides/shared-accounts/shared-account-inventory) has a fuller set of columns.

Next, give admin rights to individuals wherever the service allows it. Google recommends at least two super admins in Google Workspace, so that if one forgets the password, the other can reset it. Microsoft recommends as few Global Administrators as possible in Microsoft 365, and the least permissive role for each job. It also recommends at least one Privileged Authentication Administrator, who can reset a Global Administrator's password after a lockout. AWS recommends using the root user only for the tasks that require it. Where a service lets you give each person the admin rights they need, nobody has to share.

Last, decide how to run the shared admin logins that remain. Ask whether everyone who uses them is in your identity provider, whether you need a record by person, and whether server admin accounts should go through the same process. Then pick from the table. Keep emergency-only accounts apart from the everyday shared ones, with their own storage and a review after each use. [What is a break-glass account?](/guides/privileged-access/what-is-break-glass-account) covers how.


## Articles in this guide

- [Managing the AWS root user and admin access for a team](/guides/privileged-access/aws-root-and-admin-accounts): AWS says to keep the root user for the few tasks only it can do. Give admins personal sign-ins through IAM Identity Center, and protect and log the root user.
- [Ways to manage shared SaaS admin accounts, compared](/guides/privileged-access/comparison-of-privileged-account-methods): A sign-out log, your identity provider's fill-in, a privileged access management (PAM) product, and an access tool such as Junify, compared on seven points.
- [Managing top-level admin accounts in Google Workspace and Microsoft 365](/guides/privileged-access/google-workspace-microsoft-365-admins): Keep few top-level admins, give everyone else a narrower role, require two-step verification for admins, and keep emergency accounts apart from daily ones.
- [Shared admin logins that remain when you use Okta or Microsoft Entra ID](/guides/privileged-access/idp-and-remaining-shared-admins): Okta and Entra ID can fill in a shared admin login without showing the password. Gaps remain for people outside them, activity after sign-in, and console codes.
- [How to handle admin logins for domain, DNS and payment consoles](/guides/privileged-access/non-saml-admin-consoles): Check each console's help docs for identity provider sign-in, personal logins with roles, and required two-step verification. Split logins wherever you can.
- [What records to keep for privileged account audits](/guides/privileged-access/privileged-access-audit-records): Keep logs that tie each admin action to a person, time and account, plus records of granting, removing and reviewing access. Protect and review the logs.
- [What a SOX audit asks about admin accounts, and which records to keep](/guides/privileged-access/sox-itgc-privileged-access): A SOX audit tests whether internal control over financial reporting works, including who holds admin rights. Keep holder lists, approvals, use logs and reviews.
- [What is a privileged account?](/guides/privileged-access/what-is-a-privileged-account): A privileged account has admin rights, so it can change how a system is set up and who may use it. Cloud and SaaS admin accounts count, not just server ones.
- [What is a break-glass account?](/guides/privileged-access/what-is-break-glass-account): A break-glass account is a spare top-level admin account for when your normal admin accounts can't sign in. Nobody uses it day to day, and each use is reviewed.
- [What is privileged access management (PAM)?](/guides/privileged-access/what-is-pam): Privileged access management (PAM) controls who may use admin rights, for how long and with whose approval, and records what they did.

## Frequently asked questions

**Is it safe for only one person to hold the admin account?**

If that person forgets the password or gets locked out, nobody can get back in. Google recommends at least two super admins, and Microsoft recommends a second admin who can reset a locked-out Global Administrator's password.

**What do security frameworks ask for with privileged accounts?**

NIST SP 800-53 AC-6(5) restricts privileged accounts to people or roles you define, and AC-6(9) asks you to log privileged functions. Be ready to show who used admin rights, when, and what they did.

**Does Okta or Entra ID take care of privileged accounts?**

It does if everyone has a personal account there and every service connects to it. Services that allow only one admin account, and consoles that can't connect, need their own method.

**Do PAM tools work with SaaS admin consoles?**

It depends on the product. Check its documentation for whether it covers admin consoles you open in a browser, not only servers and cloud roles.

## Sources

- [NIST Computer Security Resource Center Glossary: privileged account](https://csrc.nist.gov/glossary/term/privileged_account)
- [NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (AC-6)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf)
- [CIS Controls Assessment Specification: CIS Control 5, Account Management](https://cas.docs.cisecurity.org/en/latest/source/Controls5/)
- [CIS Controls Assessment Specification: CIS Control 6, Access Control Management](https://cas.docs.cisecurity.org/en/latest/source/Controls6/)
- [SEC Release No. 33-8810, Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting (2007)](https://www.sec.gov/rules/interp/2007/33-8810.pdf)
- [Microsoft Learn: Sharing accounts and credentials - Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts)
- [Microsoft Learn: About administrator roles in the Microsoft 365 admin center](https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/about-admin-roles)
- [Google Workspace Admin Help: Pre-built administrator roles](https://knowledge.workspace.google.com/admin/users/prebuilt-administrator-roles)
- [AWS Identity and Access Management User Guide: AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)
- [Okta Help Center: About Secure Web Authentication](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm)
- [Okta Help Center: Reveal the password of an app integration](https://help.okta.com/oie/en-us/content/Topics/apps/apps_revealing_the_password.htm)

## How Junify handles this

**Doing this by hand** You decide who gets admin rights through requests and approvals, log every use of the admin logins that stay shared, and have someone other than the admins review that log on a schedule.

**With Junify** Junify is for the admin logins that stay shared. Your admin adds each console's username and password to Junify and assigns it to the people who may use it. They verify on their own phone and click to sign in, and Junify fills in the login without showing the password. Each sign-in is recorded by person, even on a shared admin login. Okta or Entra ID stays as it is; Junify covers only the admin logins outside it.

Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when.

- [Try the demo](https://www.junify.com/bpo/try?lang=en&scenario=privileged-access&from=guide&cluster=privileged-access)
- [Book a 30-minute demo](https://www.junify.com/bpo/demo)