Identity management

IAM, IGA and PAM: what is the difference, and which solution do you need?

Edgar Kramer
Placeholder for Edgar kramerEdgar kramer

Edgar Kramer , Business Development Manager , Nomios Netherlands

5 min. read
Placeholder for IAM PAM IGAIAM PAM IGA

Share

When you start looking for access management solutions, you’ll soon come across the same three acronyms: IAM, IGA and PAM. They sound similar, are often mentioned in the same sentence, and yet they address different problems. For organisations with a growing or complex access landscape, that distinction is no mere detail. It determines which problem you tackle first, what you can show an auditor, and where your budget will deliver the greatest return.

This article explains exactly what IAM, IGA and PAM do, how they relate to one another, and how to decide where to start.

IAM: the foundation of identity and access

Identity & Access Management (IAM) controls who has access to which systems and applications. It involves an entire set of processes and technologies used to identify, authenticate and authorise users.

IAM affects almost every part of your organisation: onboarding and offboarding, single sign-on, multi-factor authentication, federation between systems and cloud access. When it works properly, nobody even notices it. A new employee gains access to the correct applications on day one, whilst a departing employee loses that access just as quickly. When it works poorly, you only notice it when things go wrong: orphaned accounts, slow onboarding, or access that persists after someone has changed roles.

IAM is therefore the foundation upon which identity-driven security rests. Without a solid IAM foundation, you have no reliable starting point for governance (IGA) or for securing your most sensitive accounts (PAM).

IGA: control over what IAM has built up

IAM ensures that people are granted access. Identity Governance & Administration (IGA) ensures that this access is correct, remains correct and can be verified.

In practice, access rights tend to accumulate. People change roles, projects come to an end, and contractors leave, but their access rights often remain untouched. After a few years, you end up with a landscape of accounts with access rights that nobody can account for anymore. This is not only a security risk, but also a compliance issue. Auditors want to know who has access to what, why, and whether that access is still justified.

IGA brings structure to this with a number of specific mechanisms:

  • Access certification: periodic reviews in which managers confirm that access is still required
  • Role management & RBAC: roles that precisely define which access rights correspond to which job function
  • Segregation of duties: preventing combinations of permissions that could enable risks or fraud
  • Audit trails: a complete, verifiable record of every access decision

Whilst IAM is primarily operational (granting and revoking access), IGA is strategic and supervisory. It answers the question that IAM alone cannot answer: is this access still justified?

For organisations in regulated sectors, or subject to legislation such as NIS2 or DORA, IGA is often not optional. It is the way in which you demonstrate that you have access under control, not just that you manage it.

When things went wrong: the Klue breach

In 2026, market research firm Klue was compromised via a set of credentials that the company had issued in 2022 for a temporary pilot. That access was never revoked. Four years later, the extortion group Icarus used that forgotten account to gain access to nearly 200 of Klue’s clients, including Jamf, HackerOne and LastPass.

No zero-day, no sophisticated exploit. Just a test account that was never cleared, and a lack of regular access reviews. This is precisely the scenario that access certification and joiner-mover-leaver governance are designed to prevent: any access right that is not actively reviewed will remain in place until someone exploits it.

PAM: protecting your most valuable accounts

Privileged Access Management (PAM) focuses on a specific, smaller group of accounts: those with elevated privileges. These include domain administrators, database administrators, cloud root accounts or service accounts that have access to critical systems. These are the accounts that, if they fall into the wrong hands, can cause the most damage.

Traditional PAM mainly revolved around storing passwords in a vault and recording sessions. Whilst this remains relevant, the current threat landscape demands more. Cloud environments, DevOps pipelines and machine identities have created a new category of privileged access that legacy PAM tools do not always handle effectively.

Modern PAM therefore operates on the principle of zero standing privileges: no one has permanent elevated access. Instead, a user is granted access the moment it is needed, for exactly as long as necessary (just-in-time access), with full monitoring throughout the session. As soon as the task is complete, access is automatically revoked.

Key components of modern PAM:

  • Just-in-time access: access on demand, with automatic revocation
  • Session monitoring & recording: every privileged session can be traced
  • Cloud entitlement management (CIEM): visibility of excessive privileges in cloud environments, something traditional PAM tools are often blind to

PAM and IAM overlap in their purpose: both deal with access. However, they differ in scope. IAM manages access for everyone. PAM provides strict control over the small group of accounts posing the greatest risk.

IAM, IGA and PAM side by side: what’s the difference?

Question it answersFor whom
IAMWho has access to what?All users
IGAIs that access still justified and verifiable?All access rights, over time
PAMWho currently has extended access, and for how long?Accounts with the highest risks

One way to distinguish between them: IAM grants access, IGA verifies that access is correct, and PAM restricts and monitors the access that could cause the most damage if things go wrong.

They are not alternatives to one another. Strong IAM without IGA means you’ll never know whether your access landscape is still correct. IGA without PAM leaves your most critical accounts unprotected. And PAM without a proper IAM foundation is like trying to solve a problem without a stable foundation.

Placeholder for Identity AccessIdentity Access

Where do you start?

The order depends on where your organisation currently stands.

If you do not yet have a structured IAM environment (fragmented systems, manual onboarding, no central control over access), then that is the starting point. Without that foundation, governance or privileged access management will have little impact.

If your IAM is reasonably well organised but you lack visibility over who has which rights and why, then IGA is the next step. This is particularly true if you are under compliance pressure or have an audit coming up.

If you’re dealing with critical systems, cloud infrastructure or a large number of administrator accounts, PAM is often more urgent than it seems. Privileged accounts are the first target in an attack, and many organisations underestimate just how many of these accounts they actually have.

In practice, the three work best when they are aligned: IAM provisioning that ties in with IGA governance, and PAM controls that feed telemetry into detection. Dealing with them separately only solves part of the problem. Together, they form a programme that reflects how access actually works in a growing organisation.

Would you like to know where your organisation stands in terms of identity and access management? Get in touch with one of our specialists, or read more about IAM, IGA en PAM at Nomios.

Sign up for our newsletter

Get the latest security news, insights and market trends delivered to your inbox.

Updates

More updates