What is privileged identity management and what should it control?

Privileged identity management is the discipline of controlling accounts that can change systems, security settings or other people's access. It answers four questions: who holds elevated rights, why, for how long, and what they did with them. NIST SP 800-53 calls the foundation least privilege.

Why do privileged accounts need their own rules?

Ordinary accounts can do ordinary damage. A privileged account can create more accounts, turn off logging, read every record or change a firewall. MITRE ATT&CK lists Valid Accounts (T1078) as a technique that serves initial access, persistence, privilege escalation and defense evasion at once, because stolen credentials need no malware and look like normal logins.

So the account that matters most is the one that does the most when stolen.

What does NIST actually say?

Control AC-6 in SP 800-53 Rev 5 sets the principle: allow only the accesses necessary to accomplish assigned tasks, for users and for processes acting for them. Several enhancements turn that into practice:

• AC-6(1) authorizes access to security functions, such as creating accounts, setting permissions, configuring audit events and defining intrusion detection parameters, for named people or roles only.
• AC-6(2) requires people with privileged roles to use a non-privileged account for non-security work. Read email as yourself, not as root.
• AC-6(5) restricts privileged accounts to specific personnel or roles.
• AC-6(7) requires periodic review of assigned privileges, with removal or reassignment when the need has gone.
• AC-6(9) requires logging the execution of privileged functions, which is how misuse by insiders or by an intruder holding a stolen account gets noticed.

NIST CSF 2.0 says the same thing in outcome form, in PR.AA-05: permissions and entitlements are defined in policy, managed, enforced and reviewed, and reflect least privilege and separation of duties.

What does the MITRE mitigation add?

ATT&CK's Privileged Account Management mitigation (M1026) turns policy into measures: role-based access with least privilege, secure storage and rotation of credentials through a vault, and monitoring and logging of privileged use for accountability. For Kerberoasting, a related technique, it specifically says to limit service accounts to the minimum privileges they need and keep them out of groups such as Domain Admins.

What does this look like in a real team?

Here is a constructed example. A platform team of eight all hold permanent cloud administrator rights "because on-call." Two former contractors still have the role. Nobody can say who changed a storage policy last week.

A better shape: nobody holds standing admin. People request elevation for a stated task, approval is recorded, access expires after a set window, every privileged command is logged to a place the admin cannot edit, and the role list is reviewed each quarter. On-call still works, because elevation is quick and pre-approved for a known set of runbooks. Time-bound elevation is a common way to do this. NIST does not mandate a specific mechanism, only the outcomes.

How to check or apply this

1. List every privileged role in each system: cloud, identity provider, databases, CI/CD, source control, SaaS admin consoles.
2. Count standing holders per role. Aim to shrink the number, then shrink it again.
3. Split accounts: a daily account for email and browsing, a separate one for administration.
4. Put shared and service credentials in a vault with rotation, and give service accounts only what they need.
5. Log privileged actions to a location outside the admin's control and alert on odd hours or odd targets.
6. Review roles on a schedule, and remove access on the day someone changes jobs.
7. Treat non-human identities as privileged too. Build runners and automation hold keys that open production.

Quick check

Sources

• NIST SP 800-53 Rev 5 control catalog, OSCAL (AC-6 and enhancements)
• NIST Cybersecurity Framework 2.0, PR.AA-05
• MITRE ATT&CK: Privileged Account Management, M1026
• MITRE ATT&CK: Valid Accounts, T1078
• MITRE ATT&CK: Kerberoasting, T1558.003

Last reviewed: 18 October 2026.