What Is Identity and Access Management (IAM)?

Identity and access management (IAM) is the discipline of verifying who users are and controlling what they can do across the systems an organization runs. The category covers authentication (proving you’re who you say you are), authorization (determining what you’re allowed to access), provisioning and deprovisioning (creating and removing accounts as people join, change roles, and leave), audit (recording who accessed what and when), and the operational tooling that makes all of this manageable at scale. IAM has become one of the most strategically important security domains because almost every modern security incident touches identity somewhere in the chain. Strong IAM doesn’t prevent every incident, but weak IAM makes nearly every incident worse than it needed to be.

This post walks through what IAM actually covers, the core concepts every operator needs to understand, the major IAM products and patterns, where IAM fits in the broader security architecture (especially zero trust), and a practical framework for organizations evaluating their IAM posture.

What IAM actually covers

IAM is broader than the single phrase suggests. A complete IAM program addresses several distinct concerns:

• Authentication: verifying who a user is. Passwords, multi-factor authentication, biometrics, hardware tokens, passkeys. The “are you who you say you are” question.
• Authorization: determining what an authenticated user is allowed to do. Role-based access controls, attribute-based access controls, policies, group memberships. The “what are you allowed to access” question.
• User lifecycle management: creating accounts when people join, updating access as they change roles, removing access when they leave. Onboarding, offboarding, and the changes in between.
• Single sign-on (SSO): letting users authenticate once and access multiple applications without re-authenticating to each one.
• Privileged access management (PAM): specialized controls for highly-privileged accounts (admins, service accounts, root access). Higher security, more audit, often time-boxed access.
• Identity governance: periodic reviews of who has access to what, certification that the access is still appropriate, removal of accumulated stale permissions.
• Audit and logging: recording authentication events, authorization decisions, and access activity so they can be reviewed for compliance and incident response.
• Directory services: the underlying database of users, groups, roles, and metadata that IAM systems operate against.

A mature IAM program addresses all of these in a coordinated way. Many organizations have strong capabilities in some areas (authentication is the most common strength) and substantial gaps in others (lifecycle management and identity governance are common weak points).

Authentication: more than just passwords

Authentication is the most-visible IAM concept and the area where most organizations have made the most progress over the past decade.

The classic three factors of authentication:

• Something you know: a password, a PIN, an answer to a security question.
• Something you have: a phone with an authenticator app, a hardware security key, a smart card.
• Something you are: a fingerprint, a face scan, a voice match.

Modern authentication combines at least two factors (multi-factor authentication, or MFA) because any single factor can be compromised. Our MFA piece covers this in depth.

The newer direction is passwordless authentication, particularly passkeys (built on the FIDO2 / WebAuthn standard). Passkeys combine a device-bound cryptographic credential with a local biometric unlock, accomplishing what MFA does but without the user ever entering a password. Adoption is growing across major platforms, and the long-term trajectory is toward passwords playing a much smaller role than they do today.

For enterprise IAM specifically, the modern best-practice posture is:

• MFA required for every user account.
• Phishing-resistant MFA (hardware keys, passkeys, certificate-based auth) for privileged accounts and high-value access.
• Passwordless wherever the supporting infrastructure can sustain it.
• Conditional access policies that adjust authentication requirements based on risk signals (device health, network location, time of day, anomalous behavior).

Authorization: who can do what

Authentication answers "who are you." Authorization answers "what are you allowed to do." Modern authorization runs on a few common models.

Role-based access control (RBAC) assigns permissions to roles, and roles to users. A user gets the permissions of the roles they’re assigned. RBAC is the most-common pattern; it’s simple to reason about and matches how most organizations actually think about access ("the marketing team needs access to the marketing tools").

Attribute-based access control (ABAC) assigns permissions based on attributes of the user, the resource, the action, and the context. A user might be allowed to access a document if their department matches the document’s department classification, the action is "read," and it’s during business hours. ABAC is more flexible than RBAC but more complex to design and govern. It’s used in environments where access decisions depend on contextual factors RBAC can’t easily express.

Policy-based access control generalizes ABAC further: access decisions are evaluated against centralized policies written in a policy language (Open Policy Agent’s Rego, Cedar, XACML). The policy language separates the "what" of access decisions from the "where" they’re enforced, which is useful for organizations managing complex access requirements across many systems.

Just-in-time (JIT) access grants access on demand for specific tasks, rather than maintaining persistent access. A developer needs production database access to debug an issue; they request it through a tool, get it for a defined time window, and the access expires automatically. JIT reduces standing privilege, which reduces the blast radius of any single account compromise.

The trend across enterprise IAM is toward least-privilege models (each user has the minimum access they need to do their job, no more) with periodic governance reviews to remove accumulated stale permissions.

SSO and federation

Single sign-on (SSO) lets users authenticate once and access multiple applications without re-authenticating. Behind the scenes, SSO works through identity federation: an identity provider (IdP) handles authentication, and applications (service providers, or SPs) trust the IdP’s authentication assertions instead of running their own login systems.

The major protocols:

• SAML (Security Assertion Markup Language): the older enterprise federation standard. Still widely used in legacy applications. XML-based, somewhat verbose.
• OAuth 2.0: an authorization protocol used both for delegated authorization (let App A access data in App B on behalf of the user) and as the foundation for authentication via OpenID Connect.
• OpenID Connect (OIDC): an authentication layer built on top of OAuth 2.0. The modern standard for new applications.

Enterprise SSO products (Microsoft Entra ID, Okta, Ping Identity, JumpCloud, Google Cloud Identity, OneLogin, others) implement these protocols and provide the operational tooling to manage federation at scale.

The business value of SSO compounds across multiple dimensions: users have one less password to manage, IT has one place to enforce authentication policies, security teams have one chokepoint to monitor, offboarding is much simpler (deactivate the IdP account and access to every federated app stops working).

Lifecycle management: the under-invested IAM area

Most organizations are strong on authentication, weaker on authorization, and weak on lifecycle management. The result: accumulating stale permissions, accounts that should have been deactivated still active months after employees left, contractors whose access never got revoked.

Strong lifecycle management addresses:

• Onboarding: new users get the right access for their role from day one. Ideally provisioned automatically from HR system data through identity orchestration tools.
• Role changes: when a user moves between departments or roles, their access updates to match the new role. Old access from the previous role is removed.
• Offboarding: when a user leaves, all their access is revoked promptly. The “promptly” part is where most organizations have the biggest gap.
• Periodic access reviews: managers periodically certify that their team members still need the access they have. Stale access surfaces during these reviews and gets removed.
• Audit trails: every provisioning, modification, and deprovisioning action is logged for compliance and incident response.

The pattern that consistently produces good lifecycle management is automation: HR system feeds identity provider, identity provider feeds applications, role changes propagate automatically, departures trigger automated deactivation across every connected system. The pattern that produces poor lifecycle management is manual processes that depend on ticket-based requests, spreadsheet tracking, and human discipline.

IAM and zero trust

Identity and access management is the operational foundation of zero trust architecture. Zero trust’s central principle (don’t assume trust based on network location; verify every access request) requires strong identity to work. Without reliable authentication and granular authorization, the zero trust model has nothing to base decisions on.

The relationship in practical terms:

• Zero trust says “every access request gets evaluated against current context.”
• IAM provides the identity context (who is requesting), the authentication strength (how confident we are it’s actually them), and the authorization rules (what they’re allowed to access).
• Conditional access policies (in Microsoft Entra ID and equivalent capabilities in other identity providers) operationalize zero trust principles by evaluating risk signals at the IAM layer before granting access.

Our zero trust piece covers the broader architecture; IAM is the layer underneath that makes zero trust enforcement possible.

The major IAM products

The enterprise IAM market is dominated by a handful of vendors:

• Microsoft Entra ID (formerly Azure Active Directory): the IAM product for Microsoft-stack organizations. Comes integrated with Microsoft 365 and Azure. Strongest in environments already standardized on Microsoft.
• Okta: the largest pure-play enterprise IAM vendor. Strong in heterogeneous environments where the organization wants neutral identity infrastructure independent of any one application stack.
• Ping Identity: enterprise IAM with a stronger PAM and CIAM focus. Common in regulated industries.
• Google Cloud Identity / Workspace Identity: Google’s IAM product, integrated with Google Workspace. Strong in Google-Workspace-standardized organizations.
• JumpCloud: a directory-as-a-service that targets smaller and mid-market organizations looking for cloud-native identity without enterprise complexity.
• OneLogin: another major SSO and IAM vendor, often in the mix in mid-market evaluations.
• Auth0 (Okta-owned since 2021): developer-focused identity, often used as the IAM layer inside custom-built applications.

For most organizations, the IAM choice follows from the broader productivity-stack choice: Microsoft shop → Entra ID; Google shop → Cloud Identity; heterogeneous → Okta or Ping. Going against this default is reasonable but requires specific reasons.

A practical IAM framework for small and mid-sized organizations

For organizations without a dedicated IAM team, the realistic posture:

• One identity provider as the source of truth for who works at the organization. Microsoft Entra ID or Google Cloud Identity for most small-to-mid businesses (because they ship with the productivity suite). Avoid fragmenting identity across multiple uncoordinated systems.
• SSO to every business application that supports it. Most modern SaaS supports SAML or OIDC. The friction of setting up SSO is upfront; the operational benefit (especially offboarding) compounds over years.
• MFA required everywhere, with phishing-resistant methods for admin and financial accounts.
• Conditional access policies at the identity provider that adjust authentication based on risk signals. Standard policies for blocking risky logins, requiring MFA on sensitive applications, and restricting access from unmanaged devices.
• Automated provisioning where possible. Connect the HR system (or whatever’s the source of truth for “who works here”) to the identity provider so new-hire and departure events trigger automatic account creation and removal.
• Quarterly access reviews at minimum. Managers confirm their team members’ access is still appropriate; stale access gets removed.
• Documented offboarding process: when someone leaves, what gets deactivated, in what order, by whom, with what verification. The most common IAM failure is the offboarding gap.

The investment is moderate (a few hundred to a few thousand dollars per user per year for an identity provider plus the relevant licensing). The return is meaningful: reduced incident risk, faster onboarding, defensible compliance posture.

Frequently Asked Questions