PAM covers the small number of accounts that can change everything: root, domain admin, the production database, the cloud console, the CI/CD deploy key. Ordinary access controls are not built for them.
The short answer
PAM stands for privileged access management. It is the tighter regime applied to accounts that can alter systems, read every record, or erase the audit trail. Where normal access is granted and left in place, privileged access is vaulted, requested, time-limited, recorded, and withdrawn automatically when the task ends.
The reason it exists is arithmetic. A standard account compromise is contained by its own permissions. A privileged account compromise is not contained by anything, which is why attackers spend most of their effort trying to reach one.
On this page
What counts as privileged
Broader than most teams assume. The human accounts are obvious and usually covered. The machine identities are the ones that get missed, and they outnumber the humans in almost every environment.
| Identity | Why it qualifies |
|---|---|
| Root and local administrator | Full control of the host, including the ability to disable logging |
| Cloud console and IAM roles | Can create infrastructure, alter permissions, and open network paths |
| Production database accounts | Direct read and write access to every customer record |
| CI/CD and deploy credentials | Can push code straight to production, bypassing review |
| Service accounts and API keys | Standing credentials with no human owner and often no rotation schedule |
| SaaS super-admin roles | Can export company data or change authentication settings for everyone |
| Break-glass accounts | Emergency access held for outages, frequently unmonitored between uses |
The five PAM controls
| Control | What it does |
|---|---|
| Vaulting | Credentials stored centrally and never held by an individual, so nothing lives in a password manager or a config file |
| Just-in-time elevation | Privilege granted for a defined window and withdrawn automatically, replacing permanent admin rights |
| Approval workflow | A second person authorises the elevation, creating both a control and a record of why |
| Session recording | What was done during the elevated window, attributable to a named person rather than a shared login |
| Automatic rotation | Credentials change after use or on a schedule, so an exposed secret has a short useful life |
Standing privilege is the finding
Auditors are less interested in whether a vault exists than in how many accounts hold permanent administrative rights. A team with three named admins who elevate on request scores better than one with a vault and twelve people carrying standing production access. Time-bound is the control. The vault is the plumbing.
How a PAM request works
PAM and IAM are not the same
| IAM | PAM | |
|---|---|---|
| Population | Everyone with an account | The few accounts that can change or expose everything |
| Access model | Granted on joining, reviewed periodically | Requested per task, expires automatically |
| Default state | Access is held | Access is not held until elevated |
| Monitoring | Sign-in and entitlement logs | Full session record of actions taken |
| Failure mode | Entitlements accumulate quietly | One compromise reaches the whole estate |
PAM sits inside IAM rather than beside it. A programme that recertifies standard users every quarter but leaves six permanent root logins untouched has an IAM process and no PAM at all.
Where frameworks require PAM
| Framework | What it expects |
|---|---|
| SOC 2 | Restricted privileged access with approval and review evidenced across the observation window |
| ISO 27001 | An Annex A control dedicated specifically to privileged access rights |
| RBI IT Governance Directions | Segregation of duties, controlled administrative access, and periodic recertification for regulated entities |
| SEBI CSCRF | Least privilege, privileged access controls and access logging for market intermediaries |
| PCI DSS | Unique credentials per person, no shared accounts, and multi-factor authentication for all administrative access |
| DPDP Act | Reasonable safeguards restricting who can reach personal data at scale |
Shared root logins breach nearly all of them at once, because attribution becomes impossible the moment two people use the same credential. That single change is usually the highest-value fix available to a small team.
How Osto handles PAM
Privileged access is enforced at the access gate rather than inside each individual system. Sensitive infrastructure sits behind ZTNA on a private domain, unreachable unless the Osto agent is present and MFA has passed, which means an exposed administrative credential on its own does not open a path.
Elevation events, approvals and privilege changes land in the same SIEM as endpoint and cloud activity, so an elevation followed by a new access key and an unusual data pull reads as one chain rather than three separate log lines. The resulting records map to SOC 2, ISO 27001 and Indian sectoral frameworks from one control set, feeding the wider GRC evidence base without a separate collection exercise.
Platform walkthrough
Nobody should hold standing root
Osto gates privileged infrastructure behind device checks and MFA, then correlates every elevation with what happened next. One owner, one dashboard.
Book a demoAccess gated at the network · Evidence mapped automatically · One platform, everything
Frequently asked questions
What is PAM?
Privileged access management: the controls applied to accounts capable of changing systems, reading all data, or removing audit trails. It covers vaulting credentials, granting elevation only for a fixed window, requiring approval, recording sessions and rotating secrets afterwards.
What is the difference between PAM and IAM?
IAM governs every account in the organisation and typically leaves access in place between reviews. PAM governs the small group of accounts that can affect everything, and assumes access is not held at all until it is requested, approved and time-limited.
Do service accounts need PAM?
Yes, and they are usually the weakest area. API keys, CI/CD credentials and machine identities carry standing privilege with no human attached. Each needs a named owner, a rotation schedule and the same review cycle as human administrators. Auditors increasingly sample them by name.
Is a password vault enough?
No. A vault solves storage, not standing privilege. If ten people can retrieve the root credential whenever they like, the access is still permanent and shared. The controls that change the risk are time-bound elevation, approval and attribution.
Does a small team need PAM?
The substance, yes. The apparatus, not necessarily. Removing shared root logins, enforcing MFA on every administrative path, and keeping a record of who elevated and why will satisfy most auditors at a small company. Dedicated tooling becomes worthwhile as the number of administrators grows.