IAM is more than SSO and MFA. Learn how identity and access management works, what its four functions cover, where traditional tools reach their limits, and how modern IGA fills the gap.
When identity and access management first took hold in enterprise IT, the problem it was solving was straightforward: make sure the right people could log in to the right systems. Credentials, directories, authentication. The perimeter model, where the network edge was the boundary and anyone inside it was trusted, made this a workable frame.
That model has been obsolete for years. The average enterprise now runs hundreds of SaaS applications, employs contractors and remote workers across geographies, processes data in cloud environments with no fixed perimeter, and operates with non-human identities (service accounts, API tokens, bots) that outnumber human users in many stacks. The login is one moment in a much longer relationship between an identity and the access it holds.
IAM has evolved to match this reality, but unevenly. Authentication is a solved problem. Lifecycle management, entitlement-level governance, and continuous access control are where the gaps remain. Understanding where IAM ends and where more is required is the most important thing a security or IT leader can know before building or buying into an identity program.
This guide covers what IAM is, how its four functions work, where traditional IAM tools reach their limits, and what the modern identity security stack looks like above those limits.
What Is Identity and Access Management?
Identity and access management is a framework of policies, processes, and technologies that controls which identities can access which resources, under what conditions, and with what level of permission.
An "identity" in this context is any entity that requests access: a full-time employee, a contractor, a partner, a service account, an API token, a bot. A "resource" is anything that can be accessed: a SaaS application, a database, a cloud environment, a file, an internal tool, a network segment.
The IAM framework defines how identities are created, verified, authorized, managed over time, and eventually deprovisioned. It determines who can log in, what they can do once they're in, and whether their access is still appropriate as time passes and circumstances change.
What IAM is not: a single product, a perimeter, or a solved problem. Most organizations have components of IAM in place. What they often lack is a complete program that covers all four functions below, not just the first one.
The Four Functions of IAM
Authentication
Authentication answers one question: is this identity who they say they are? It is the entry gate. Passwords, MFA, biometrics, hardware tokens, certificate-based authentication, and passwordless methods are all authentication mechanisms.
Modern IAM handles authentication well. Adaptive authentication adjusts the verification requirement based on risk signals: a known device on the corporate network might require only a password; an unfamiliar device in an unusual geography might require MFA plus a manager approval. Single sign-on (SSO) centralizes authentication so users verify once and access multiple applications through a federated session.
Authentication is the most mature part of the IAM stack. For most organizations, it is the part that works. The more complex problems are downstream.
Authorization
Authorization answers a different question: given that this identity is authenticated, what are they allowed to do?
At its simplest, authorization is binary: access granted or access denied at the application level. At its most sophisticated, authorization is entitlement-level: not just "user X can access Salesforce" but "user X has admin permissions in Salesforce, a full CRM license, read-write access to the West region account set, and no access to the finance dashboard."
Most traditional IAM tools operate at the application level. Entitlement-level authorization, which is necessary for meaningful least-privilege enforcement and meaningful access reviews, requires a platform that can reach inside applications to understand permission structures, not just confirm that a user has an account.
Role-based access control (RBAC) is the standard model: roles are defined, permissions are attached to roles, and identities are assigned roles. Attribute-based access control (ABAC) and policy-based access control (PBAC) are more granular models that allow authorization decisions to incorporate context beyond role membership.
Lifecycle Management
Lifecycle management is the operational layer of IAM. It covers what happens to an identity's access from the day they join an organization to the day they leave, including every change in between.
Joiner: when a new employee starts, the right access must be provisioned on day one: the right applications, at the right license tier, with the right permission level for their role. Done manually, this takes hours and rarely gets the entitlements exactly right. Done through automated provisioning playbooks triggered by HRMS sync, it happens on the hire date with no IT ticket required.
Mover: when someone changes role, department, or location, access should update accordingly. The access appropriate for a junior analyst is not appropriate for a department head. Old permissions should come off; new permissions should come on. In practice, access accumulates and rarely gets trimmed, producing permission drift: identities that hold far more access than their current role requires because old access was never removed.
Leaver: when someone leaves, access must be revoked across every application they ever accessed. Not just the SSO-connected ones, not just the SCIM-supported ones, but all of them. Orphaned accounts (active credentials belonging to departed employees) are among the most common access risk findings in security audits. Most exist because offboarding ran through a partial checklist rather than a complete access inventory.
Access Governance
Access governance is the continuous oversight layer. It asks, on an ongoing basis: is current access still appropriate? Were the right decisions made? Can we prove it to an auditor?
Governance includes access reviews (periodic or event-triggered certification that access is still appropriate and approved), SoD (segregation of duties) enforcement (identifying and flagging conflicting permission combinations, such as one user holding both payment approval and payment processing access), policy management (translating security principles into enforceable access rules), and audit trails (comprehensive logs of who provisioned what, who approved it, and when it changed).
This is the layer most traditional IAM tools do not fully address. Access reviews in a basic IAM setup are often manual, quarterly, and limited to what the IdP can see. SoD analysis requires cross-application entitlement data that most authentication-focused platforms don't collect. Audit trails may cover login events but not the provisioning decisions that determined what someone could do once logged in.
The line between IAM and IGA (Identity Governance and Administration) runs through this layer. IGA is the dedicated platform for governance functions. For a detailed comparison of where IAM ends and IGA begins, see IAM vs IGA.
Core IAM Concepts
Least privilege: the principle that every identity should hold only the access required to perform their current function. No more. In practice, least privilege is violated continuously by permission drift, overprovisioning on day one, and manual offboarding failures. Enforcing it requires both provisioning discipline and continuous access review.
Zero trust: the architectural model that assumes no identity is inherently trusted, regardless of network location. Every access request is verified against identity, device posture, context, and policy. Zero trust is the security strategy; IAM is the operational infrastructure that makes it executable.
Non-human identities (NHIs): service accounts, API keys, OAuth tokens, bots, and machine-to-machine credentials that access resources without human involvement. NHIs now outnumber human identities in most enterprise SaaS environments and represent a significant and often ungoverned attack surface. A complete IAM program covers NHI discovery, access scope control, rotation policies, and deprovisioning alongside human identity management.
Directory services: the system of record for identity data. Active Directory, LDAP, and cloud directories (Okta Universal Directory, Microsoft Entra ID) store identity attributes, group memberships, and entitlements. The directory is the foundation of the IAM program, but it only knows about identities and resources it has been told to track, which is why discovery methods that go beyond the IdP are essential.
Federation: the protocols (SAML, OAuth, OIDC) that allow identities authenticated in one system to access resources in another without re-authenticating. Federation is the mechanism that makes SSO work across application boundaries and across organizational boundaries for partner and customer access scenarios.
Where Traditional IAM Reaches Its Limits
Most organizations that consider themselves to have a working IAM program have, in practice, built the authentication layer: SSO, MFA, a directory, and basic provisioning for their largest and most SSO-connected applications.
The gaps that remain are predictable:
Non-SCIM application coverage. SCIM-supported applications can be provisioned and deprovisioned through the IdP. Applications that don't support SCIM fall outside the automation perimeter. These are often managed manually, which means they're managed inconsistently, and orphaned accounts accumulate.
Entitlement-level visibility. The IdP sees whether a user has an account in an application. It often can't see what that user can do inside the application at the permission level. This means access reviews certify "user has access" not "user has appropriate access."
Permission drift. RBAC at provisioning time doesn't automatically correct for drift. Roles change, exceptions get approved, and no cleanup follows. Without a continuous governance layer, permission drift grows unchecked.
Non-human identity blind spots. Service accounts created outside the standard provisioning process, OAuth tokens granted by individual employees, and API keys with indefinite lifespans operate in most organizations without meaningful lifecycle management or access review.
Compliance evidence gaps. Auditors require evidence that access was appropriate, that reviews happened on schedule, and that departing employees lost access immediately. Basic IAM logs show authentication events; they rarely produce the provisioning audit trail and access certification records compliance frameworks require.
These are not failures of authentication technology. They are the natural limits of a platform built to solve the login problem applied to a broader governance requirement it was never designed for.
How Zluri Addresses the IAM Governance Gap
Zluri is an identity security platform that operates above the existing IAM stack, governing the access layer that traditional IAM tools leave open.
Zluri's IGA product consists of four connected modules: Access Management (joiner-mover-leaver automation), Access Requests (policy-driven approval workflows), Access Reviews (application-based, group-based, and user-based review cycles), and Segregation of Duties (cross-application conflict detection and remediation).
Visibility comes from IVIP, which discovers human and non-human identities across SaaS, cloud, and on-premises environments through 8 discovery methods, so the identity inventory is not bounded by what the IdP already knows. If an employee was granted access to a SaaS tool directly, outside of SSO, IVIP surfaces it. If a service account holds permissions in a financial application that no one has reviewed in two years, IVIP surfaces that too.
IRIS, Zluri's intelligence layer, continuously analyzes this inventory for risk signals: dormant accounts, external users with sensitive-data access, over-permissioned identities, and SoD violations. Rather than surfacing a quarterly report, IRIS flags risk continuously so remediation happens before the audit, not during it.
Zluri's provisioning engine connects to 300+ applications through direct integrations, executing over 1,500 granular workflow actions. Provisioning and deprovisioning aren't limited to the applications that support SCIM. Every app in the stack falls under the same governance controls.
Organizations deploy Zluri on top of their existing Okta, Microsoft Entra ID, or other IAM infrastructure. The existing IAM handles authentication. Zluri handles everything that authentication doesn't.
Implementation runs 2 to 3 months, not the 6 to 12 that legacy IGA suites typically require.
Book a demo to see the governance layer in action
IAM Compliance Considerations
Access control is a foundational requirement in every major enterprise compliance framework. The specific evidence required varies by framework, but the underlying question is consistent: can you prove that access was appropriate, approved, and timely revoked?
SOX ITGC requires access control evidence covering provisioning, deprovisioning, access reviews, and SoD checks, particularly for systems that touch financial reporting. See the IAM compliance guide for a framework-by-framework breakdown.
SOC 2 Type II requires evidence that access management controls operated effectively over the audit period, including user access reviews and timely deprovisioning.
HIPAA requires that access to systems containing protected health information is limited to authorized users, with audit trails showing access events and access control reviews.
ISO 27001 and PCI DSS both include access control as core control domains, requiring documented provisioning processes, access reviews, and least-privilege enforcement evidence.
An IAM program that covers authentication but not governance cannot produce this evidence consistently. Compliance readiness is as much an IAM architecture question as a policy question.
Frequently Asked Questions
What is the difference between IAM and IGA?
IAM covers authentication, authorization, and basic lifecycle management. IGA (Identity Governance and Administration) adds the continuous oversight layer: access reviews, SoD enforcement, entitlement-level visibility, and compliance evidence production. Most organizations need both; IGA sits on top of IAM rather than replacing it. See IAM vs IGA for a full breakdown.
What are the main components of an IAM system?
The four functions are authentication (verifying identity), authorization (determining access scope), lifecycle management (provisioning, mover updates, and deprovisioning), and access governance (ongoing oversight, reviews, and compliance evidence). A system that covers only the first two is an authentication platform, not a complete IAM program.
Is IAM only for large enterprises?
No, but the complexity scales with organizational size. A 50-person company needs basic authentication and user provisioning. A 2,000-person company with 300 SaaS applications, contractors, and multiple compliance obligations needs a full IAM and IGA stack. The gap between what's needed and what's in place tends to widen fastest in the 200 to 2,000 employee range, where SaaS sprawl outpaces IT governance capacity.
What is the relationship between IAM and zero trust?
Zero trust is a security architecture that assumes no identity is inherently trusted, regardless of network location. IAM is the operational infrastructure that makes zero trust enforceable: identity verification, device posture checks, contextual access policies, and continuous access review are all IAM functions that zero trust requires. You cannot implement zero trust without a functioning IAM program.
How does IAM handle non-human identities?
Traditional IAM tools were designed for human users and often have limited coverage of service accounts, API keys, OAuth tokens, and bots. Modern identity security platforms like Zluri surface and govern non-human identities alongside human ones through a unified identity graph, applying the same provisioning, access review, and deprovisioning logic to machine identities as to human ones.
What is the difference between authentication and authorization?
Authentication verifies that an identity is who they claim to be. Authorization determines what that verified identity is permitted to do. Both are IAM functions, but they operate at different points in the access decision and require different mechanisms. A system can authenticate correctly and still authorize incorrectly, granting too much access, the wrong access, or access that has not been reviewed.
How long does IAM implementation take?
It depends on what's being implemented. Basic SSO and MFA can be deployed in days. Full lifecycle management and governance, covering provisioning automation, access reviews, SoD, and compliance evidence across a complete application stack, typically takes 2 to 3 months with modern cloud-native platforms and 6 to 12 months with legacy enterprise suites. The difference is largely in the configuration overhead and connector availability.
.svg)
