How should organisations split responsibilities between IGA and PAM?

Why This Matters for Security Teams

Organisations split IGA and PAM because they solve different problems, and confusing them creates gaps that attackers exploit. IGA governs who should have access over time: joiner-mover-leaver processes, role design, certification, and policy. PAM governs what happens when access becomes elevated: vaulting, session control, approval, and just-in-time privilege. That distinction matters even more for NHI because service accounts, API keys, and workload identities often live longer than the systems they protect.

When teams collapse the two functions, they often end up with periodic reviews that do not stop runtime abuse, or with vaulting that does not fix entitlement sprawl. Current guidance from NIST Cybersecurity Framework 2.0 still points to clear ownership, least privilege, and continuous monitoring as separate operational concerns. NHIMG research shows the scale of the issue: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts. The practical lesson is that review processes alone do not protect elevated execution paths, which is why runtime enforcement belongs in PAM and entitlement governance belongs in IGA. In practice, many security teams encounter privilege abuse only after an API key or service account has already been used, rather than through intentional access design.

How It Works in Practice

The cleanest split is to let IGA define the approved identity state and let PAM control the risky moments when that identity is used. IGA should own lifecycle tasks such as provisioning, deprovisioning, role assignment, recertification, ownership mapping, and policy exceptions. PAM should own privileged execution, including vaulting secrets, brokering session access, logging commands, and issuing NIST Cybersecurity Framework 2.0-aligned evidence for high-risk activity.

For NHIs, that usually means the identity record lives in IGA, while the credential material and runtime approval path live in PAM. A service account may be created by IGA, linked to RBAC or a more granular access policy, and then handed to PAM for controlled retrieval only when a job actually needs it. Where possible, use JIT credential issuance, short TTLs, and automatic revocation after task completion. That approach is especially important when secrets are shared across pipelines or workloads, because long-lived credentials create a standing privilege problem that certification cannot fix after the fact.

• Use IGA for ownership, approvals, recertification, and offboarding of NHI records.
• Use PAM for vaulting, checkout controls, session recording, and elevation approvals.
• Prefer JIT access for admins, robots, and agents that need temporary privileged execution.
• Keep secrets out of code and CI/CD where possible, and treat vault policy as an enforcement layer, not a directory.

NHIMG research highlights why this split matters operationally: 79% of organisations have experienced secrets leaks, and 73% of vaults are misconfigured. The BeyondTrust API key breach is a useful reminder that exposed or over-permissioned credentials can turn a single account into broad lateral movement if runtime controls are weak. These controls tend to break down in high-velocity CI/CD environments because identity ownership, secret delivery, and execution windows move faster than manual approval workflows.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations have to balance speed against assurance. That tradeoff becomes visible in engineering teams that deploy often, in platform teams that rotate secrets automatically, and in environments where the same workload identity is reused across many services. Best practice is evolving here: there is no universal standard for how much should sit in IGA versus PAM when identities are highly ephemeral, but current guidance favours clear ownership, short-lived credentials, and separate runtime enforcement.

One common exception is cloud-native automation where the “privileged” action is not a person logging in but an agent or pipeline obtaining a token for a narrow task. In those cases, IGA should still define the approved system identity and business owner, while PAM or an equivalent control plane should manage retrieval, duration, and session evidence. Another edge case is emergency access. If a team uses break-glass accounts, they should still be tied to IGA for ownership and review, then brokered through PAM for time-bound use and post-event analysis. The same logic applies to service accounts that support critical infrastructure or third-party integrations. NHIMG’s BeyondTrust API key breach case shows how quickly a privileged credential can become an enterprise-wide exposure point when the control model is not separated correctly. For organisations pursuing NIST Cybersecurity Framework 2.0 maturity, the practical goal is not choosing IGA or PAM, but ensuring each control owns the risk it can actually reduce.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• How do organisations operationalise NHI ownership at scale?