IAM vs PAM: Scope, Ownership and Privileged NHIs

Most organisations have an IAM team and a PAM team, and the most dangerous identities in the estate belong to neither of them. Identity and access management (IAM) runs the identity provider, single sign-on, MFA and the joiner, mover and leaver lifecycle for the workforce. Privileged access management (PAM) controls how high-risk accounts and credentials are reached, used, recorded and rotated. The boundary between the two is usually drawn around human administrators, which leaves privileged service accounts, IdP API tokens, provisioning connectors and OAuth applications sitting in the gap. This page sets out the two-way scope boundary, who should own what, the privileged non-human identities (NHIs) that fall between both teams, and how to integrate and sequence the two programmes. It is for IAM and PAM leads, identity architects and CISOs. The wider three-way split with identity governance is covered in PAM vs IGA vs NHI Management.

Key takeaways

IAM decides who exists and how they sign in; PAM controls powerful access at the moment of use. IAM is the broad discipline for every identity, PAM is a specialised control layer over the privileged subset.
The boundary runs both ways. PAM depends on the IdP to authenticate its users, and the IdP is itself a top-tier asset whose administrators and integrations PAM must protect.
Privileged NHIs fall through the gap. IAM onboards people from HR and PAM onboards accounts it has been told about, so a service principal with directory-wide rights or an API token inheriting a super administrator's role often has no owner in either.
Ownership needs a rule, not a meeting. Assign every privileged identity by trigger and capability: the team that creates it owns its lifecycle, PAM owns its credential and session controls when it can change systems or other identities.
Sequence IAM foundations first, then PAM, then close the NHI gap. Strong authentication and a clean directory make PAM effective; PAM without them protects a vault that anyone with a phished admin session can reach.

The short answer

You need both. IAM without PAM leaves standing administrator rights, shared privileged passwords and unrecorded sessions, because IAM platforms manage entitlements and authentication, not the use of a domain administrator password on a server at 2am. PAM without IAM has no reliable answer to who the person requesting access is, whether they still work for you, or whether their MFA is strong enough to trust. The real question is not which one to buy, but where the line between them sits for each identity type, and who owns the privileged machine identities that both teams assume the other is handling.

What each discipline covers

IAM: the directory and identity provider, authentication (passwords, MFA, passkeys, conditional access), federation and SSO, provisioning to applications (often by SCIM), role and group models, and lifecycle driven by HR. Identity governance (access requests, reviews, separation of duties) is normally part of the IAM programme. See IAM and IGA Basics.
PAM: discovery and onboarding of privileged accounts, credential vaulting and rotation, just-in-time elevation, session brokering and recording, endpoint privilege management, and remote or vendor access. The NCSC's secure system administration guidance frames it as controlling who can administer, where, when, why and how, alongside tiering and logging of administration. See the Privileged Access Management Guide.

Definitions explain part of the gap. The NIST glossary entries for "privileged user", drawn from CNSSI 4009-2022, SP 800-53 Rev. 5 and SP 800-171 Rev. 3, all describe an authorised and therefore trusted person or individual. Programmes built from those definitions scope PAM around people, while many of the most powerful credentials in a modern estate belong to software.

Side-by-side comparison

Dimension	IAM	PAM
Core question	Who is this, should they have access, and are they who they claim to be?	How is high-risk access granted, used, recorded and taken away?
Population	Every workforce identity, plus partners and often customers	Administrators, shared and break-glass accounts, privileged service accounts
Main object managed	The identity, its authentication and its entitlements	The privileged credential and the session that uses it
Trigger	HR events, access requests, application onboarding	Elevation request, session start, rotation schedule, discovery finding
Typical platforms	Directory, IdP, SSO, MFA, IGA	Vault, session manager, elevation broker, endpoint privilege manager
Evidence produced	Sign-in logs, provisioning records, approval and review decisions	Check-out and rotation history, session recordings, elevation logs
Failure that hurts most	Weak authentication and orphaned accounts	Standing privilege and unvaulted credentials
Position in Microsoft's enterprise access model	The control plane, built on centralised identity systems	The privileged access pathway into every plane

The two-way boundary

Most scope documents describe the boundary in one direction only: IAM hands PAM a list of administrators. In practice each side depends on the other, and each dependency needs an owner.

Dependency	Direction	What goes wrong without an owner	Suggested owner
Authentication of PAM users	PAM relies on IAM	PAM console reachable with a password or a weak MFA method that IAM never enforced	IAM sets the policy; PAM confirms it is applied to its console
Joiner, mover, leaver feed	PAM relies on IAM	Leavers keep vault safes and elevation eligibility because PAM groups are maintained by hand	IAM, through group-driven PAM entitlements
IdP and directory administrators	IAM relies on PAM	Global and super administrator roles held permanently by named staff, outside session control	PAM for use; IAM for role design
IdP integrations with admin rights (API tokens, provisioning connectors, sync accounts)	IAM relies on PAM	Credentials stored in scripts or connector settings, never rotated, invisible to PAM discovery	Joint: IAM owns lifecycle, PAM owns the credential
PAM's own service accounts (rotation and discovery accounts)	Both	Accounts with rights to reset every privileged password, governed by nobody outside the PAM team	PAM, with independent review by IAM
Break-glass accounts	Both	Excluded from conditional access by IAM and from vaulting by PAM, so excluded from everything	PAM, with IAM monitoring sign-ins; see the Break-Glass Account Guide

The IdP rows matter most. Microsoft's guidance on privileged roles in Entra ID describes service principals or applications that hold highly privileged roles as control plane assets, and says systems that manage or broker access to privileged roles must be protected at that level and administered from equally trusted control plane systems. That puts the IdP's own integrations inside PAM's scope, even though IAM created them.

Privileged NHIs that fall between both teams

A privileged NHI is a non-human identity that can change systems, security settings or other identities' access. Microsoft's definition of privileged permissions is a useful test: permissions that can delegate management of directory resources, modify credentials, authentication or authorisation policies, or access restricted data. Apply the same test to machine identities, and the list below is what usually fails it.

Privileged NHI	Why IAM misses it	Why PAM misses it	Default owner and control
Service principal or app registration holding a privileged directory role or app-only mail or directory permissions	Created by an engineer in the IdP, not by an HR event; reviews target human role assignments	No password to vault; secret or certificate lives in the application	Application team owns lifecycle; IAM approves privileged consent; credential moved to federation or certificate with rotation
IdP API token (for example an Okta SSWS token)	Looks like part of an admin's account	Not discovered as an account at all	Okta documents that these tokens inherit the creating administrator's privileges, so issue them from a dedicated service account with a scoped role and network restriction, or move to OAuth 2.0 as Okta recommends
SCIM provisioning token in an IdP connector	Treated as connector configuration	Stored inside the IdP, not a vault	IAM owns the connector; record token owner, expiry and the target application's admin scope
Directory sync and hybrid identity accounts	Installed once, then forgotten	Often excluded from rotation because outages are feared	PAM treats as tier-zero; IAM owns configuration
Integration service accounts in SaaS (ticketing, source control, chat bots)	No HR record; created by an admin of the SaaS	SaaS admin roles not onboarded	SaaS owner with named person; credential vaulted and rotated after any upstream compromise
CI/CD deployment roles and pipeline tokens	Outside the workforce directory	Short-lived or embedded, so not a vault object	Platform team; workload federation in place of static keys; see the NHI Ownership Guide
AI agents with delegated administrative tools	Registered as apps, not users	Actions run through APIs, not brokered sessions	Agent owner with IAM; see AI Agent Identity vs Service Account

The OWASP Non-Human Identities Top 10 for 2025 names the risks this gap produces: NHI1 Improper Offboarding, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets and NHI10 Human Use of NHI. The last is the clearest sign of a broken boundary: when an administrator signs in with a service account to avoid PAM, both teams lose attribution. See the OWASP NHI Top 10 NHI10 Human Use of NHI Guide.

Threat model, failure modes and controls for each side

IAM

Threat model: attackers target authentication and recovery: password spraying, MFA fatigue, help desk social engineering and token theft, then use valid accounts (T1078.004 for cloud accounts) to add credentials or roles (T1098.001, T1098.003).
Failure modes: legacy and test tenants outside conditional access; administrators using daily accounts; consent to applications with broad permissions granted without review; leaver processing that removes the user but not tokens and applications they created.
Controls: phishing-resistant MFA for all administrators (NIST SP 800-53 IA-2(1)), separate administrative identities, application consent policies, automated disablement on leave (AC-2(3)), and an inventory of every app registration with an owner.
Worked scenario: an engineer creates an app registration with an app-only directory write permission to automate group changes. IAM's quarterly review covers user role assignments only. The fix is a consent workflow that routes any privileged permission to IAM for approval and records an owner, with the app added to the privileged NHI register that PAM reads.

PAM

Threat model: attackers target standing privilege and stored credentials: vault administrators, rotation service accounts, credentials copied out of the vault into scripts, and sessions that bypass the broker.
Failure modes: onboarding only the accounts someone listed; exempting service accounts from rotation indefinitely; PAM console authenticated locally rather than through the IdP with strong MFA; session recording that covers servers but not cloud consoles or SaaS admin roles.
Controls: discovery-driven onboarding, rotation with dependency mapping, PAM sign-in through the IdP with phishing-resistant MFA, logging of privileged functions (AC-6(9)), and independent review of PAM's own administrators (AC-5).
Worked scenario: PAM rotates domain administrator passwords daily, but the hybrid sync account has directory-wide rights and a password set at installation. It was excluded because nobody in PAM owned the sync configuration. The fix is joint: IAM documents the dependency, PAM onboards the account as tier-zero with a tested rotation window and a rollback plan.

Integration patterns

Pattern	How it works	Benefit	Watch for
IdP in front of PAM	PAM console and broker use SSO with the IdP's strongest MFA and conditional access	One authentication policy, immediate effect of leaver disablement	Break-glass access to PAM if the IdP is unavailable; see Emergency Identity Operations When the Primary IdP Is Unavailable
Group-driven PAM entitlements	IAM groups or roles map to PAM safes and elevation policies; IGA certifies the groups	Movers and leavers flow automatically; reviews happen once	Nested groups that grant PAM rights invisibly
PAM protecting IdP administration	IdP global and privileged roles are eligible only, activated through PAM or PIM with approval, session evidence in one place	Removes permanent tier-zero rights from named staff	Emergency accounts and service principals left permanent; see PAM vs PIM
Shared privileged NHI register	One record per privileged NHI with owner, capability, credential type and controlling team, fed by IdP, cloud and PAM discovery	Ends the "I thought you had it" gap	Two registers that disagree; agree a single system of record
Shared detection	IdP sign-in and audit logs and PAM session events correlated in the SIEM or ITDR tooling	Catches privileged use that bypassed PAM	Logs from SaaS admin roles not collected; see the ITDR Guide

Sequencing a programme

Agree the boundary in writing. Use the two-way table above. For each row, record the owner and the evidence each team must show. Sign it off at the identity steering group (CSF GV.RR-02).
Fix authentication for administrators first. Phishing-resistant MFA and separate admin identities for every IdP, cloud and PAM administrator. Pilot with the identity team, then extend. Rollback is per-user policy exclusion with expiry, never a blanket exception.
Put the IdP in front of PAM. Federate the PAM console; keep one vaulted local emergency path and test it quarterly.
Build the privileged NHI register. Discover service principals with privileged roles or permissions, IdP API tokens, provisioning connectors, sync accounts and SaaS integration accounts. Mark each with an owner or an "unowned" flag. See NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments.
Remove standing human privilege. Move IdP and cloud admin roles to eligible assignments and vault the remaining permanent accounts. Run activation in audit mode for a month before enforcing approval.
Bring privileged NHIs under control in risk order. Directory-wide rights first, then mail and data access, then SaaS admins. For each: replace secrets with federation where possible, otherwise vault and rotate. Disable before delete, keep the old secret valid for a short overlap and keep a tested re-enable path.
Connect the triggers. Leaver events reassign NHIs the person owned; PAM discovery findings create IAM ownership tasks. See the OWASP NHI Top 10 NHI1 Improper Offboarding Guide.

Decision guidance

"Do I need PAM if I have IAM?" If any account holds permanent administrative rights, any privileged password is shared, or any administrator session goes unrecorded, yes. IdP role elevation features cover the IdP's own roles; servers, databases, network devices and SaaS admin consoles still need credential and session control.
Small organisations: one team owns both. Start with IdP-native controls: strong MFA, eligible admin roles, consent policies, and a spreadsheet register of privileged NHIs with owners. Add a vault when shared or service account passwords exist that people must retrieve.
Mid-sized organisations: separate PAM capability, run by the IAM function. Use group-driven entitlements so that one leaver process covers both.
Large and regulated organisations: separate teams. The risk is the gap, so the shared register and joint ownership of IdP integrations matter more than the choice of tools. Treat IdP administration and PAM administration as the same tier.
Service accounts: "PAM vs IAM for service accounts" is the wrong framing. The creating team owns lifecycle; PAM owns the credential when it can change systems or identities; IAM approves privileged permissions in the IdP.

Detection and measurement

Monitor: privileged role and permission grants in the IdP (new app-only permissions, new credentials on existing service principals), API token creation, interactive sign-ins by service accounts, privileged actions with no matching PAM session or elevation, and changes to PAM administrators and rotation accounts.
Correlate: IdP audit logs with PAM session and check-out events, so a privileged change in the IdP without an elevation record raises an alert (CSF DE.CM-03).

Metrics that show the boundary is working:

Percentage of privileged NHIs in the register with a named owner (target: 100%).
Number of permanent assignments to IdP and cloud tier-zero roles held by people, excluding documented break-glass accounts.
Percentage of privileged actions in the IdP and cloud with a matching PAM or elevation record.
Median age of credentials for privileged NHIs that still use secrets.
Time from leaver event to reassignment or disablement of NHIs that person owned.

Common failure patterns

Integration accounts assumed unused: in the Cloudflare Thanksgiving breach, a service token and service accounts, one with administrative access to Jira, were left unrotated after an upstream compromise because they were believed to be unused. No person logs in with such accounts, so neither lifecycle nor vault processes notice them.
Privileged OAuth applications in forgotten tenants: the Microsoft Midnight Blizzard breach began with a legacy test tenant account without MFA and a legacy test OAuth application with elevated access, which was then used to grant mailbox access without a signed-in user. Test tenants and their applications need the same owner and review as production.
PAM authenticated outside the IdP: a local PAM login with its own password policy means IAM's MFA and leaver controls never reach the most sensitive console.
Service accounts exempted from rotation forever: exemptions made for outage fear with no expiry date become the long-lived secrets attackers look for.
Tokens tied to a person's admin account: API tokens that inherit an administrator's role change privilege when that person changes role, and disappear or break when they leave.
Admins using service accounts: the quickest route around PAM, and the quickest way to lose attribution for both teams.

Framework mapping

Framework	Reference	IAM, PAM or shared
NIST SP 800-53 Rev. 5	AC-2 Account Management; AC-2(1) Automated System Account Management; AC-2(3) Disable Accounts	IAM, including non-human accounts
NIST SP 800-53 Rev. 5	AC-2(7) Privileged User Accounts; AC-6(5) Privileged Accounts; AC-6(9) Log Use of Privileged Functions	PAM
NIST SP 800-53 Rev. 5	IA-2(1) Multi-factor Authentication to Privileged Accounts; IA-9 Service Identification and Authentication; IA-5 Authenticator Management	Shared: IAM sets policy, PAM manages privileged credentials
NIST SP 800-53 Rev. 5	AC-5 Separation of Duties	Shared: independent review of PAM and IdP administrators
NIST CSF 2.0	PR.AA-01; PR.AA-05; GV.RR-02; DE.CM-03	Identities managed, access permissions enforced, roles defined, activity monitored
CIS Controls v8.1	Control 5 Account Management (user, administrator and service accounts); Control 6 Access Control Management	IAM with PAM for administrator accounts
ISO/IEC 27001:2022 Annex A	5.15 Access control; 5.16 Identity management; 5.18 Access rights; 8.2 Privileged access rights; 8.5 Secure authentication	8.2 is PAM; the others are IAM
MITRE ATT&CK	T1078.004 Cloud Accounts; T1098.001 Additional Cloud Credentials; T1098.003 Additional Cloud Roles	Detection shared between IdP and PAM telemetry

Practitioner checklist

Write a two-way boundary statement covering PAM authentication, leaver feeds, IdP administration, IdP integrations, PAM service accounts and break-glass accounts.
Require phishing-resistant MFA and separate admin identities for every IdP, cloud and PAM administrator.
Federate the PAM console to the IdP and keep one tested emergency path.
Build one register of privileged NHIs, using a written definition of privileged that covers credentials, policies, other identities and restricted data.
Give every privileged NHI a named owning team and person, with a deadline for unowned entries.
Issue IdP API tokens from dedicated service accounts with scoped roles and network restrictions, or replace them with OAuth clients.
Move tier-zero human roles to eligible assignments and vault the permanent remainder.
Alert on privileged changes without a matching PAM or elevation record.
Rotate every privileged NHI credential after any upstream compromise, whether or not it appears in use.

IAM vs PAM: Scope, ownership and the privileged NHIs between them