Managing privileged accounts

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? 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). 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. 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 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.

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)? 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?.

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 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? covers how.