What counts as a privileged account?

NIST defines a privileged account as a system account with the authorisations of a privileged user, meaning someone trusted to perform security-relevant functions that ordinary users may not. In practice that covers root and local administrator accounts, domain admins, database owners, cloud administrator roles, and the service accounts and API keys that hold similar rights.

Is PAM the same as identity and access management (IAM)?

No. IAM manages every identity's sign-in and entitlements across the organisation. PAM is a narrower layer for the accounts and sessions that can change or destroy systems: it brokers those sessions, keeps their credentials in a vault, limits how long access lasts and records what was done. Most organisations need both.

Does PAM only apply to people?

No. Scripts, pipelines, applications and cloud workloads also hold privileged credentials, often more of them than people do. A PAM programme should vault and rotate those secrets, replace long-lived keys with short-lived credentials where the platform supports it, and record what automated accounts do with their rights.

Glossary

Privileged access management (PAM)

Also called PAM, privileged account management, privileged access security

Privileged access management (PAM) is the set of controls and tools that decide who may use administrative access to critical systems, for how long and under what conditions, while keeping the credentials protected and every privileged session on record.

Rudratic glossary

Privileged access management controls the small number of accounts that can reconfigure servers, read whole databases or change cloud permissions. Instead of handing administrators a password they keep for years, a PAM system brokers each privileged session: it checks policy, supplies the credential without revealing it, limits the time window and records the activity. The aim is to make powerful access rare, short and accountable.

What makes access “privileged”

NIST describes a privileged user as one who is authorised, and therefore trusted, to perform security-relevant functions that ordinary users may not, and a privileged account as a system account with those authorisations. Typical examples are root, Windows local and domain administrators, database SYSDBA or superuser roles, cloud administrator roles, and the service accounts that run backups or deployments. See non-human identity for the machine side.

How it works

Most PAM platforms combine four functions:

Function	What it does	Related term
Credential vault	Stores and rotates passwords, keys and tokens so users do not hold them	Credential vaulting
Access requests	Grants elevated rights on request, with approval and an expiry	Just-in-time access
Session brokering	Routes sessions through a proxy that injects credentials and enforces policy	Least privilege
Monitoring and audit	Records sessions and keeps an evidence trail	Session recording

Why it matters

NIST SP 800-53 Rev. 5 sets out several controls PAM helps implement: AC-6(5) restricts privileged accounts to defined personnel, AC-6(7) requires periodic review of privileges, AC-6(9) requires logging the use of privileged functions, and AU-14 covers session audit. CISA’s Zero Trust Maturity Model describes a path for access management that runs from permanent access with periodic review to automated just-in-time and just-enough access tailored to individual actions. Cloud vendors follow the same idea: Microsoft’s Privileged Identity Management offers time-bound, approval-based role activation to reduce excessive or misused access.

PAM vs IAM

Identity and access management covers every user’s sign-in and entitlements. PAM sits on top of it for the accounts that can do the most damage, adding vaulting, brokered sessions, time limits and recording. The two share an identity provider: PAM reads groups from it and decides what privileged access each group may request. Identity security is the broader discipline that joins them.

Examples

A DBA asks for read-only access to a billing database for two hours to investigate an incident; the grant ends on its own.
A contractor reaches a Windows server through a browser session, never sees the administrator password, and the session is recorded.
A cloud engineer assumes an administrator role through an approval flow and receives short-lived credentials.

How SWOT supports it

SWOT PAM is a self-hosted PAM platform that brokers SSH, RDP and database sessions through a proxy, so users never receive the target credential. Access is requested for a set time, approved by approvers notified in Slack, Microsoft Teams or email, and ends on its own; PAMGuard can block a command, freeze input or end a session, and the audit trail is hash-chained. SWOT Cloud PAM applies the same model to AWS, Azure and GCP. See also zero standing privileges.

Questions

What counts as a privileged account?: NIST defines a privileged account as a system account with the authorisations of a privileged user, meaning someone trusted to perform security-relevant functions that ordinary users may not. In practice that covers root and local administrator accounts, domain admins, database owners, cloud administrator roles, and the service accounts and API keys that hold similar rights.
Is PAM the same as identity and access management (IAM)?: No. IAM manages every identity's sign-in and entitlements across the organisation. PAM is a narrower layer for the accounts and sessions that can change or destroy systems: it brokers those sessions, keeps their credentials in a vault, limits how long access lasts and records what was done. Most organisations need both.
Does PAM only apply to people?: No. Scripts, pipelines, applications and cloud workloads also hold privileged credentials, often more of them than people do. A PAM programme should vault and rotate those secrets, replace long-lived keys with short-lived credentials where the platform supports it, and record what automated accounts do with their rights.