Notifications
Clear all
Topic starter
11/07/2026 2:03 pm
TL;DR: IAM, IGA and PAM are often discussed together, but they solve different governance problems: authentication and access control, lifecycle certification, and privileged oversight, according to Soffid. The practical issue is not naming the acronyms correctly, but avoiding a programme design that treats access, governance, and elevation as the same control surface.
NHIMG editorial — based on content published by Soffid: IAM, IGA and PAM explained
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should organisations separate IAM, IGA, and PAM in practice?
A: Organisations should treat IAM as the access enforcement layer, IGA as the lifecycle and certification layer, and PAM as the elevated-access control layer.
Q: Why do privileged access controls fail when identity governance is weak?
A: Privileged access controls fail when elevated accounts are created without lifecycle discipline, reviewed too late, or left with standing access.
Q: What breaks when service accounts are handled like human users?
A: Service accounts do not behave like employees, so human-style onboarding, annual review, and offboarding processes miss their real lifecycle.
Practitioner guidance
- Separate IAM, IGA, and PAM ownership Define which team owns authentication enforcement, which owns lifecycle certification, and which owns privileged session control.
- Inventory non-human identities explicitly Build a register for service accounts, API keys, tokens, and application identities so they are reviewed outside human access recertification cycles.
- Test least privilege at elevation points Verify that temporary access cannot become standing access through cached roles, broad admin groups, or forgotten exceptions.
What's in the full article
Soffid's full article covers the operational distinctions this post intentionally leaves at framework level:
- Role-based access and recertification features described in the vendor's IAM model for enterprise deployment
- Workflow automation and real-time monitoring functions used to support access review and privileged oversight
- How the platform is positioned to integrate IAM, IGA, and PAM for mixed legacy and cloud estates
- Sector-specific adaptation examples that are not fully unpacked in this commentary
👉 Read Soffid's explanation of IAM, IGA and PAM in one operating model →
IAM, IGA and PAM: what identity teams need to separate now?
Explore further
11/07/2026 2:12 pm
IAM, IGA, and PAM are not stacked labels for the same control. They are different governance answers to different identity risks. IAM answers whether access is authenticated and enforced, IGA answers whether access still belongs there, and PAM answers whether elevated access is tightly bounded. When teams collapse those functions into one programme view, they lose the ability to prove control at the point auditors and attackers both care about. The implication is that identity architecture has to be segmented by control purpose, not by tooling convenience.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when privileged access outlives the business need?
A: Accountability should sit with the system owner, the identity governance function, and the privileged access owner, depending on where the failure occurred. If no one owns entitlement review, revocation, and session oversight, privileged access tends to persist by default. That is a governance failure, not just a tooling gap.
👉 Read our full editorial: IAM, IGA and PAM: where identity governance meets privileged access
