Privileged Access Management: Locking Down Your Most Powerful Accounts

Privileged access management (PAM) is the set of controls that protect the accounts able to change your systems: directory and cloud administrators, root, database administrators, service accounts and emergency accounts. The core practices are well established. Vault privileged credentials and rotate them, broker and record admin sessions, tier admin accounts so credentials can't cross between layers, give admins separate accounts and dedicated workstations, bring service accounts under control, keep break-glass accounts ready and monitor privileged activity closely. You can put most of this in place in stages, starting with the accounts that could do the most damage.

What is privileged access management?

A privileged account is any account that can change configuration, access data broadly or control other accounts. In a typical mid-sized organization that includes:

• Directory and domain administrators
• Cloud tenant, subscription and project owners or administrators
• Local administrator accounts on servers and workstations
• Root on Linux and Unix systems, and admin accounts on network devices
• Database administrators
• Administrators of SaaS platforms such as email, finance and HR systems
• Service accounts used by applications, scripts and scheduled jobs
• Emergency (break-glass) accounts
• Vendor and managed service provider accounts with admin rights

These accounts matter because they turn a small problem into a large one. An intruder who arrives with an ordinary stolen credential will look for privileged credentials to expand their reach. Insiders with standing admin rights can misuse them. And an honest mistake made with domain-wide rights can take down every system at once.

Where should you start with PAM?

Start with an inventory. You can't protect privileged accounts you don't know about, and many organizations find more than they expected.

Check directory group memberships, local administrator groups on servers and workstations, cloud role assignments, SaaS admin roles, sudo rules on Linux hosts and database roles. Search scripts, configuration files and scheduled tasks for embedded credentials. CIS Controls v8 covers this under Safeguard 5.1 (an inventory of accounts) and Safeguard 5.5 (an inventory of service accounts).

For each account, record the owner, what it can do, whether MFA is enforced and when it was last used. Remove what's unused, then move on to the controls below.

How does credential vaulting work?

A credential vault stores privileged passwords, keys and secrets centrally, encrypted, with access controlled and logged. Administrators check a credential out when they need it and the vault rotates it afterwards, so nobody holds a long-lived password to a critical system.

Good vaulting practice includes:

• Unique credentials per system. Every server's local administrator account should have its own randomized password so one recovered password can't be reused across the estate.
• Rotation. Rotate after each checkout for the most sensitive accounts, and on a regular schedule for the rest.
• Shared accounts through the vault only. Accounts such as root or a built-in administrator can't easily be removed, but every use can be tied to a named person through checkout records.
• SSH key management. Inventory keys, remove orphaned ones and rotate the rest. Short-lived SSH certificates reduce the problem further.
• Secrets out of code. Move credentials in scripts and configuration files into the vault or a secrets manager that applications query at runtime.

Treat the vault itself as one of your most sensitive systems. Anyone who controls it controls everything stored in it.

What is privileged session management?

Session management puts a control point between administrators and the systems they manage. The admin authenticates to a broker, such as a hardened jump host or session proxy, with MFA. The broker opens the session to the target, often injecting the credential so the admin never sees it.

Brokering gives you three things:

1. A single enforcement point. Firewall rules can allow administrative protocols like RDP and SSH only from the broker, closing direct paths to servers.
2. Session recording. Video, keystroke or command logs of admin sessions help with investigations and troubleshooting, and give you oversight of vendor activity.
3. Attribution. Every session is tied to a named person, even when the target account is shared.

Record sessions on your most critical systems first, such as domain controllers, identity infrastructure and databases holding sensitive data. Tell administrators that sessions are recorded, and check any legal or works council requirements before you start.

Vendor access deserves special attention. Grant it through the broker only, limit it to agreed time windows and record it.

What is admin tiering?

Admin tiering separates privileged accounts into layers based on what they control, and stops credentials from a higher tier being exposed on lower-tier systems. The classic model comes from Active Directory environments, but the idea applies anywhere.

The key rule is that higher-tier credentials never sign in to lower-tier systems. When an administrator logs on to a machine, credential material such as password hashes or authentication tickets can be left in memory. If that machine is later compromised, the credential can be harvested and reused through techniques like pass-the-hash. A domain admin who signs in to a user's laptop to fix a printer has just exposed Tier 0 to that laptop.

Enforce tiering with logon restrictions in group policy or its equivalent, and with separate admin accounts per tier. Cloud administrators who can manage identity belong in Tier 0.

Why do administrators need separate accounts?

A daily-use account is exposed to far more than an admin account needs to be: websites, downloaded files and a long list of applications. If that account also holds admin rights, any code that runs under it inherits them, and so does anyone who steals its credentials.

CIS Controls v8 Safeguard 5.4 is clear on this: administrator privileges belong on dedicated administrator accounts, used only for admin work. In practice:

• Each administrator has a standard account for daily work with no elevated rights.
• Admin accounts are named, never shared, and have no mailbox or general web access.
• Where you use tiering, admins get one account per tier they manage.
• MFA is required for all administrative access, as Safeguard 6.5 requires.

This is part of CIS Implementation Group 1, so it's considered baseline hygiene, not an advanced control.

What is a privileged access workstation?

A privileged access workstation (PAW) is a dedicated, hardened device used only for administrative tasks. It doesn't run email, browse the web or install general-purpose software. CIS Safeguard 12.8 describes the same idea as dedicated computing resources for all administrative work, segmented from the main network and without internet access.

For mid-sized organizations, a practical approach is:

• Give Tier 0 administrators a dedicated physical PAW first.
• Allow administrative access to Tier 0 systems only from PAWs.
• Use hardened jump hosts, reached from the PAW, for Tier 1 work.

Running an admin virtual machine on an everyday workstation is weaker than it looks. If the host is compromised, the guest is too. Keep the trust running in one direction: the admin environment should sit on the more trusted device.

How should you manage service accounts?

Service accounts are often the most neglected privileged accounts. They're created during a project, given broad rights to get things working and then left alone for years.

• Assign an owner and purpose to every service account, and review them regularly.
• Grant only the rights needed. A service account almost never needs domain administrator rights.
• Deny interactive logon. Service accounts shouldn't be able to sign in to desktops or through remote desktop.
• Use long, random, vaulted passwords with rotation. Service accounts with weak passwords are a known target for offline cracking techniques such as Kerberoasting.
• Use platform-managed service identities where available, so the platform handles rotation.
• Monitor behavior. Alert when a service account signs in from an unexpected host or interactively.

What are break-glass accounts?

Break-glass accounts give you a way back in when normal administration fails. That could be an identity provider outage, a broken federation trust or an access policy that locks every admin out.

• Keep at least two, so one lost credential doesn't leave you stranded.
• Don't make them depend on the systems they're meant to recover, such as federated sign-in or an on-premises MFA server.
• Use long random passwords and strong MFA, with credentials stored securely and access split between people where possible.
• Exclude them only from the specific policies that could lock them out.
• Alert on every use, test them on a schedule and rotate credentials after each use.
• Document when and how they can be used.

How do you monitor privileged activity?

Privileged accounts should be the most closely watched accounts you have. NIST SP 800-53 includes logging the use of privileged functions as part of its least privilege control, AC-6. Send privileged activity to your central log store and alert on:

• Changes to privileged group membership or new admin role assignments
• Privileged sign-ins from unexpected hosts, such as a Tier 0 account on a workstation
• Admin activity outside normal hours for that person or team
• Unusual vault activity, such as bulk checkouts or checkouts without a ticket
• Any use of a break-glass account
• Interactive sign-ins by service accounts
• Attempts to disable logging or security tooling

Review a sample of recorded sessions and vault checkouts regularly, not only after an incident.

Frequently asked questions

Do we need a dedicated PAM platform?

Not to get started. Separate admin accounts, MFA, randomized local admin passwords, jump hosts and alerting can all be built with features you likely already have. A dedicated platform becomes more useful as the number of systems, admins and vendors grows, particularly for session recording and automated rotation.

How is PAM different from identity and access management?

Identity and access management covers all users and their access. PAM is the subset focused on accounts with elevated rights, which need stronger controls such as vaulting, session brokering and closer monitoring.

How many domain administrators should we have?

As few as possible, usually a handful of named people. Everyday server and workstation administration should use scoped roles, not directory-wide rights.

Next steps

• Build a full inventory of privileged accounts, including service and vendor accounts.
• Give every administrator a separate admin account and require MFA on it.
• Randomize local administrator passwords and vault shared credentials.
• Define your Tier 0 systems and restrict where Tier 0 accounts can sign in.
• Set up two break-glass accounts and alerting on privileged group changes.