What is the difference between IAM and an identity provider?

How IAM and an identity provider differ in scope

IAM is the broader operating model for governing who can access what, when, and under which policies. An identity provider is one component inside that model: it proves who a user is, issues identity assertions, and often anchors SSO. So the difference is scope, IAM is the full control plane, while the IdP is one of its core building blocks.

That distinction matters because a business can have an IdP without having mature IAM. You may authenticate users successfully and still lack lifecycle governance, privilege control, access reviews, or strong segregation between roles. Conversely, an IAM programme can include directory services, provisioning, MFA, conditional access, PAM, and federation, with the IdP supplying the primary authentication layer those controls depend on. See also IAM and Identity Provider Buyer's Guide.

In practical terms, IAM answers the governance question, “How do we manage identity and access across the organisation?” The IdP answers the authentication question, “Which system establishes the user’s identity and issues the tokens or assertions other systems trust?” For many environments, the IdP is the front door, but IAM is the whole building, including the doors, locks, badges, reviews, and emergency exits.

What the identity provider actually does inside IAM

An IdP typically authenticates users, maintains the source record for core digital identities, and feeds downstream applications through SAML, OIDC, or similar trust relationships. It may also support MFA, passwordless login, group claims, and federation. That makes it central to login flow, but not sufficient on its own for governing access, entitlement sprawl, or privileged activity.

Because the IdP sits upstream of many applications, failures there can have outsized consequences. A weak recovery process, a compromised admin, or a misissued token can open access across multiple systems at once. That is why hardened IdP administration, phishing-resistant MFA, and careful federation monitoring are not optional extras. They are part of the security foundation that the rest of IAM relies on. Identity Provider and SSO Security Guide is useful here because it focuses on the controls that keep the IdP trustworthy.

IAM extends beyond that foundation. It also covers joiner-mover-leaver processes, directory hygiene, access recertification, least privilege, session governance, and privileged access boundaries. In other words, the IdP establishes identity trust, but IAM determines how that trust is operationalised across the organisation.

That is why organisations sometimes replace or upgrade an IdP while leaving broader IAM problems unresolved. Modern authentication can improve the login experience, but it does not automatically fix orphaned accounts, excessive permissions, or weak delegation. Those are IAM issues, not just IdP issues.

Why the distinction matters for security decisions

Confusing IAM with an IdP leads to the wrong buying, architecture, and incident-response decisions. If you treat the IdP as the whole IAM stack, you may over-invest in authentication features while under-investing in governance, privilege reduction, and lifecycle controls. If you treat IAM as just a directory or login portal, you may miss the control points that actually reduce exposure.

The distinction also matters during compromise. An attacker who gains IdP admin access, steals signing material, or abuses federation trust can often pivot into many connected services. But if the issue is excessive permissions or stale accounts, the primary failure sits in IAM governance, not in the authentication layer alone. That means the response path changes, you may need token revocation, credential rotation, and federation review for an IdP incident, but access cleanup and entitlement remediation for an IAM governance failure.

For teams planning change, Identity Platform Migration is the clearest example of how the two layers intersect. Migration work has to preserve authentication continuity while also protecting provisioning, recertification, and decommissioning logic, otherwise the organisation may modernise the front door but leave the old access paths alive.

Practitioner Guidance

What to verify: Check whether your IdP is acting only as an authentication service or also as a policy source for federation, MFA, and claim release. Then verify that lifecycle, access review, and privileged access controls are owned separately and measured separately, because those functions are where IAM usually fails first.

Decision rule: If the problem is “who is this user and can they sign in?”, start with the IdP. If the problem is “should they still have access, and how much?”, treat it as an IAM governance issue. If both are in play, fix the IdP trust path first, then clean up entitlement and privilege exposure.

What good looks like: The IdP is hardened, monitored, and recoverable, while IAM policies govern provisioning, deprovisioning, review, and privilege boundaries across every connected application. The organisation can prove both authentication trust and access governance without relying on the same control to do both jobs.

Practitioner takeaway: The IdP is the trust anchor for authentication, but IAM is the discipline that decides whether that trust is used safely across the rest of the environment.

Related resources from NHI Mgmt Group

• Provider
• Should organisations buy an IAM provider or build identity features in-house for SaaS?
• What should IAM leaders do when an identity provider must remain in place during migration?
• Which IAM control matters most when organisations need to keep access available during identity provider outages?