Quick answer: Privileged access management (PAM) is the set of tools and practices that control, monitor and limit the accounts with elevated power, such as administrators, root users, service accounts and cloud roles. Because those accounts can change or reach almost anything, PAM aims to give them out only when needed, record what they do, rotate their credentials and remove them when the job is done.
What is a privileged account?
A privileged account is any account that can do more than an ordinary user: install software, change security settings, create other accounts, read sensitive data or alter systems at scale. Privileged access is wider than most organisations realise:
- Human administrators: domain admins, cloud global admins, database administrators and network engineers.
- Service accounts: non-human identities used by applications, scripts and scheduled jobs, often with passwords that never change.
- Application and API credentials: keys and tokens in code, configuration files and pipelines.
- Cloud roles and break-glass accounts: emergency accounts that bypass normal controls.
- Third-party and vendor accounts: contractors and managed service providers with remote access.
- Business privileged users: executives or finance staff who can approve payments or access sensitive data.
Why PAM matters
Most serious breaches involve an attacker obtaining powerful credentials. A standard user account gets a foothold; a privileged account gets the keys. With admin rights an attacker can disable security tools, copy databases, create new accounts for persistence and delete backups before deploying ransomware. Privilege escalation is a standard step in almost every intrusion.
PAM reduces that risk in three ways: it shrinks the number of privileged accounts, it limits how long and how widely privileges can be used, and it creates a record of everything that happens.
Core PAM controls
1. Discovery and inventory
You cannot protect accounts you do not know exist. Discovery scans directories, servers, cloud platforms and applications to find privileged accounts, group memberships, service accounts and embedded credentials.
2. Least privilege
Each user and service gets only the permissions needed for the task. Replace broad roles such as “Domain Admin” or “Owner” with narrower roles scoped to a system or project.
3. Credential vaulting and rotation
Privileged passwords and keys are stored in a secure vault, checked out when needed and rotated automatically after use. This eliminates shared spreadsheets and passwords that haven’t changed in years.
4. Just-in-time (JIT) access
Instead of standing admin rights, users request elevation for a defined time window, with approval and a recorded reason. When the time expires, the rights disappear.
5. Session monitoring and recording
Privileged sessions are brokered through a gateway that logs commands and, where appropriate, records the session. This supports investigations, accountability and compliance evidence.
6. Multi-factor authentication
Every privileged login should require a second factor, preferably phishing-resistant methods such as hardware security keys or passkeys.
7. Approval workflows and break-glass procedures
High-risk actions require a second person’s approval. Emergency accounts are sealed, monitored and tested, and every use is reviewed.
8. Analytics and alerting
Alerts on unusual privileged behaviour, such as access at odd hours, new admin grants, or use of a service account from a new location.
PAM vs IAM vs PIM
- IAM (identity and access management) manages identities and access for everyone: who they are and what they can reach. See What Is IAM?
- PAM is a specialised layer that applies stricter controls to the highest-risk accounts.
- PIM (privileged identity management) usually refers to managing and time-limiting privileged roles, often in cloud directories. It is one component of a PAM strategy.
Benefits of PAM
- Lower breach impact: a stolen credential can do less damage.
- Better visibility: a single record of who did what, when and why.
- Faster audits: evidence for SOC 2, ISO 27001, HIPAA, PCI DSS and cyber insurance questionnaires.
- Safer third-party access: vendors get scoped, time-limited access rather than permanent VPN credentials.
- Reduced insider risk: accountability for privileged actions.
- Ransomware resilience: limiting lateral movement and the ability to delete backups.
Typical use cases
- Cleaning up standing admin rights across cloud and on-premises environments
- Securing service accounts, CI/CD pipelines and secrets
- Giving contractors and managed service providers controlled access
- Protecting domain controllers, hypervisors and backup consoles
- Meeting compliance requirements for restricted and logged administrative access
- Controlling access to production databases
How to start without a big project
- Inventory. List every admin, service and shared account, with an owner for each.
- Remove. Delete or disable accounts and rights nobody needs.
- Separate. Give administrators distinct admin accounts that are not used for email or browsing.
- Protect. Enforce MFA on every privileged login.
- Vault. Store shared and service credentials in a vault and begin rotating them.
- Time-box. Introduce just-in-time elevation for your most sensitive systems first.
- Log and review. Turn on logging for administrative actions and review privileged access quarterly.
For a practical walk-through, see Too Many Admin Accounts in Our Cloud: Where to Start.
Common PAM mistakes
- Buying a PAM tool before cleaning up the accounts it will manage
- Leaving “temporary” standing admin rights in place permanently
- Ignoring non-human identities and embedded credentials
- Making the process so slow that engineers work around it
- Forgetting to monitor and review the vault and break-glass accounts themselves
PAM in the cloud: AWS, Azure and Google Cloud
Cloud platforms change what “privileged” means. There is no domain controller to protect, but there are control-plane roles that can create or delete entire environments with a few API calls. Each major platform offers native building blocks:
- Microsoft Entra ID (Azure AD): Privileged Identity Management provides just-in-time activation, approval workflows, access reviews and alerts for roles such as Global Administrator.
- AWS: IAM Identity Center with permission sets, short-lived role sessions through STS, service control policies and CloudTrail for auditing. Avoid long-lived IAM user keys for people.
- Google Cloud: IAM roles with conditions, Privileged Access Manager for time-bound grants, and organisation policies to restrict risky actions.
Whichever platform you use, the principles are the same: no permanent owners or global admins beyond a tiny, monitored emergency set; role assignments scoped to the smallest resource boundary; and every elevation recorded.
Non-human identities and secrets
In many environments, service accounts, API keys and tokens now outnumber people. They are often over-privileged, undocumented and never rotated, which makes them an attractive target. A sound PAM programme treats them the same as human administrators:
- Find them. Scan code repositories, CI/CD systems, configuration files and cloud accounts for embedded secrets.
- Assign owners. Every service account needs a named person or team responsible for it.
- Move secrets to a vault and fetch them at run time instead of storing them in code.
- Prefer short-lived credentials such as workload identity and managed identities over static keys.
- Rotate and expire. Set rotation schedules and remove accounts when the workload they served is retired.
What PAM looks like day to day: before and after
Before PAM
A database administrator keeps a permanent domain admin account, which is also used to browse the web and read email. The root password for a critical server is in a shared spreadsheet that six people can open. A contractor has a VPN account that was created two years ago and never reviewed. When something goes wrong, nobody can say who ran which command.
After PAM
The administrator uses a standard account for daily work and requests elevated access through an approval workflow when a task requires it. The request is approved, a session is opened through a gateway that records commands, and the privileges expire after two hours. The server password is vaulted and rotated automatically after each use. The contractor’s access is tied to a project, expires in 30 days and is reviewed by a manager. When an auditor asks who changed a configuration last Tuesday, the answer takes minutes, not weeks.
How PAM maps to compliance requirements
| Framework | Relevant expectation | How PAM helps |
|---|---|---|
| SOC 2 | Logical access restrictions, access reviews, privileged activity monitoring | Role-based elevation, review evidence and session logs |
| ISO 27001 | Management of privileged access rights and secret authentication information | Vaulting, approval records and periodic recertification |
| HIPAA | Access control, audit controls and unique user identification | Named accounts, activity logging and least privilege for ePHI systems |
| PCI DSS | Restrict access by need to know, MFA for administrative access, log all access | JIT access, enforced MFA and complete audit trails |
Measuring success: PAM metrics worth tracking
- Number of standing privileged accounts, trending down
- Percentage of privileged logins protected by MFA, aiming for 100%
- Percentage of privileged credentials vaulted and rotated
- Average privileged session length for just-in-time elevations
- Time to revoke access when a person leaves or changes role
- Number of unreviewed privileged accounts at each quarterly review
- Break-glass account uses and the percentage reviewed within 24 hours
Frequently Asked Questions
What does PAM stand for?
PAM stands for privileged access management: the controls and tools used to secure, manage and monitor accounts with elevated permissions.
What is the difference between PAM and IAM?
IAM manages identities and access for all users. PAM is a focused subset that applies stricter controls, such as vaulting, approvals and session recording, to the most powerful accounts.
Do small businesses need PAM?
Yes, though it can be lightweight. A clean admin list, MFA on every admin account, a password vault and logging deliver most of the benefit without an enterprise platform.
Is a password manager the same as PAM?
No. A password manager stores credentials. PAM adds access approval, time limits, automated rotation, session monitoring and policy enforcement.
What is just-in-time access?
Just-in-time access grants elevated permissions only for a limited time, when needed and approved, and then removes them automatically, so there is no standing admin access to steal.
How long does a PAM project take?
Quick wins such as MFA and account clean-up can happen in weeks. A full platform rollout across a mid-sized organisation typically takes several months, delivered in phases by system criticality.
Ready to lock down your admin accounts?
We help teams find, reduce and control privileged access without slowing down engineering. Explore our PAM services →