The 4 Pillars of IAM Explained

The four pillars of IAM define the complete scope of what an identity and access management system has to do, and getting any one of them wrong creates compounding security and operational risk across the others. Search this phrase and you'll find two competing frameworks talked about as if they're the same thing. They aren't, but neither is wrong.

Auditing an existing IAM stack? The four pillars give you a structured way to find gaps. Building a new one from the ground up? They give you a checklist that's hard to miss anything from. Either way, each pillar here is treated as both a concept and a concrete engineering decision.

Key Takeaways

The four pillars of IAM are Authentication (verifying who users are), Authorization (controlling what they can do), Identity Administration (managing identity throughout its lifecycle), and Federation and SSO (extending identity across systems and organizations).
The pillars are interdependent: you cannot authorize a user without first authenticating them, and you cannot authenticate a user without first creating their identity through administration.
Different sources name the pillars differently. The foundational model (Authentication, Authorization, Administration, Auditing) and the enterprise-vendor model (IGA, AM, PAM, ADMgmt) describe the same discipline from different vantage points.
CIAM (Customer Identity and Access Management) applies the same four pillars to external users and customers, not just workforce identities.
Each pillar can be implemented with open source tooling: organizations do not need a monolithic vendor platform to cover all four.

What Is IAM and Why Do the Pillars Matter?

Identity and Access Management (IAM) is the set of policies, processes, and technologies that ensure only the right identities have the right access to the right resources, at the right time, for the right reasons. That's a lot of "rights" in one sentence, but each one is a real engineering decision that has to be made and re-made as the system evolves.

The four-pillar framework exists because IAM is too broad to think about as one system. Engineers and architects need a structured way to audit what they have, identify gaps, and make build-versus-buy decisions for each layer independently. Without the framework, "we need to fix our IAM" turns into a project that never ends. With it, the conversation becomes "we need to fix our authorization pillar before Q3," and that's a project that can actually be scoped.

Why There Are Different "Four Pillars" Models

Walk through the SERP and you'll see two frameworks. Enterprise-vendor sources (One Identity, miniOrange) use IGA, AM, PAM, and AD Mgmt because they're mapping the market categories their products serve. Foundational sources (IBM, Snowflake) use Authentication, Authorization, Administration, and Auditing because they're describing what IAM does conceptually. Neither is wrong. They're describing the same discipline from different angles. This article uses the foundational model with a small adaptation (Federation/SSO replacing Auditing as the fourth pillar) because it maps directly to the technical layers engineers actually build and manage in production.

IAM vs CIAM

IAM traditionally refers to workforce identity: employees, contractors, partners. CIAM (Customer IAM) applies the same four pillars to external users and customers. The distinction matters for product-led companies building consumer-facing products, where the authentication pillar has to optimize for conversion as much as for security and the federation pillar has to include social login. The pillars are the same. The constraints are different. For the full picture on this, see Ory's customer identity and access management hub.

Pillar 1: Authentication

Authentication is the process of verifying that a user, device, or service is who or what it claims to be, typically by validating a credential such as a password, MFA code, passkey, or certificate.

Authentication Methods: From Passwords to Passkeys

The methods sit on a spectrum from "what most teams still use" to "what most teams are moving toward."

Passwords remain the most widely deployed credential and the most attacked. MFA (TOTP, push notifications, hardware tokens) adds a second factor and dramatically reduces credential-compromise risk. Passkeys and WebAuthn use public-key cryptography bound to a device or biometric and are phishing-resistant by design. SSO lets a user authenticate once and access many apps (covered in Pillar 4). Biometrics can stand alone or pair with another factor depending on the platform.

The industry shift toward passwordless isn't marketing. Credential theft has been the dominant attack vector for years, and passkeys remove the shared secret entirely. For CIAM specifically, passwordless is also a conversion lever, not just a security one.

Session Management and Token Issuance

Once authentication succeeds, the system has to issue a session or token that downstream systems can trust. The session is the artifact that proves authentication happened. Everything in the authorization pillar consumes it. This is also where Pillar 1 hands off to Pillar 4, because the session or token is what gets federated across system boundaries.

Authentication for CIAM vs Workforce IAM

The constraints diverge here. Workforce IAM can demand strong security, managed devices, and acceptable login friction (employees aren't going to abandon a sign-in because it takes ten seconds). CIAM has to balance security against conversion. Social login is expected. SSO via the user's existing identity provider is expected. Passkeys aren't a bonus, they're becoming table stakes. The authentication requirements are different for each user population, even though the underlying pillar is the same.

Security doesn't have to be a bottleneck for growth. By implementing Ory’s 'one-tap' social login in less than 48 hours, we saw a 8-10% increase in our visitor-to-signup numbers.

— Raunak Kathuria, VP of Engineering, Deriv

For the authentication pillar, Ory Kratos is an identity management system that handles the full authentication layer (user registration, MFA, passkeys, social login, and session management) without requiring a proprietary vendor platform or building the flows from scratch.

Explore Ory Kratos for authentication and identity administration

Pillar 2: Authorization

Authorization is the process of determining whether an authenticated identity is permitted to perform a specific action or access a specific resource, enforcing the policies that define what each user can do, not just who they are.

Authentication vs Authorization: The Practical Difference

Authentication is "you are who you say you are." Authorization is "here is what you are allowed to do." A developer authenticated into an internal tool may be authorized to read logs but not delete records. The distinction collapses in many systems, and when it does, the result is over-privileged accounts and broken access control vulnerabilities. This is the OWASP A01 failure mode, and it's been the most common web application security flaw for years running.

Access Control Models: RBAC, ABAC, and ReBAC

Three models dominate. RBAC (Role-Based Access Control) assigns permissions to roles and users to roles. Simple, auditable, the right default for most stable hierarchies. ABAC (Attribute-Based Access Control) evaluates attributes of the user, resource, action, and environment to make dynamic decisions. The right choice for regulated industries and context-driven access. ReBAC (Relationship-Based Access Control) defines permissions through relationships between entities ("user is editor of this document"). The model behind Google Drive, GitHub, and Ory Keto. For the full comparison, our guide on access control models like RBAC and ABAC covers when each one is the right fit.

Least Privilege and Zero Trust

Least privilege means granting only the minimum permissions required for each task. Zero trust extends this to require continuous verification rather than assumed trust once a user is inside the perimeter. The authorization pillar is where least privilege gets technically enforced, which is why misconfigurations here matter so much: an over-privileged role is the operational equivalent of leaving a door unlocked at the office.

For the authorization pillar, Ory Keto is an authorization server built on Google's Zanzibar relationship-based access control model, designed to evaluate permissions at the speed and scale that production APIs require.

Explore Ory Keto for authorization

Pillar 3: Identity Administration

Identity administration, also called Identity Lifecycle Management, is the process of creating, maintaining, and securely deprovisioning digital identities throughout a user's relationship with an organization or application.

The Identity Lifecycle: Provisioning, Maintenance, Deprovisioning

The lifecycle has three phases and every one of them is where compliance lives or dies.

Provisioning is creating a digital identity with the appropriate attributes, credentials, and initial access rights during onboarding. Manual provisioning slows things down. Automated provisioning prevents the "new joiner waiting two weeks for access" problem.
Maintenance is updating identity data and access rights as a user's role or relationship changes. This is where access drift happens silently. Someone moves teams. Their old permissions never get revoked. Multiply that across hundreds of moves and you have a real audit problem.
Deprovisioning is revoking credentials and access when a user departs. This is the phase that ends up on the front page of breach reports. Orphaned accounts (still active after the user is gone) are one of the most common entry points for attackers. GDPR and SOX both require timely deprovisioning. Manual deprovisioning is where it fails.

User Stores and Directory Services

A central user store (directory, database, LDAP) is the source of truth for all identity data. What it contains: attributes, credentials, access rights, and the history of each. Centralizing the user store is what makes audit and compliance tractable. Fragmented user stores (auth in one place, profile data in another, group membership in a third) are how organizations end up unable to answer "what does this user have access to?" in a reasonable timeframe.

Automated Lifecycle Management and SCIM

Manual provisioning and deprovisioning create risk. SCIM (System for Cross-domain Identity Management) is the standard for automating lifecycle events across connected systems. When a user is added in your IdP, SCIM pushes that to every connected app. When they're removed, SCIM revokes everywhere. Manual approaches always lag. SCIM doesn't, and for compliance-driven orgs, that lag is the difference between passing and failing an audit. For implementation depth on this, see directory synchronization and SCIM.

Ory Kratos also handles the identity administration layer (user profiles, self-service flows, credential management, and account lifecycle), making it the implementation point for two pillars rather than one.

Explore Ory Kratos for identity administration

Pillar 4: Federation and SSO

Federation and SSO allow a user's authenticated identity to be trusted and accepted across multiple systems and organizational boundaries, so they can log in once and access everything they're authorized to use without re-entering credentials.

What Federation Means in Practice

Federation establishes a trust relationship between an identity provider (IdP) and one or more service providers (SPs). When a user authenticates with the IdP, that authentication is accepted by all federated SPs. This is what makes enterprise SSO work across dozens of third-party applications: one login at Okta, access everywhere Okta is federated.

OAuth/OIDC vs SAML: Which Federation Protocol?

OAuth 2.0 with OIDC is the modern, API-first choice: lightweight, mobile-friendly, developer-native. SAML is the established enterprise standard: XML-based, deeply supported by existing IdPs, required for many legacy and regulated-industry integrations. Most mature stacks run both. For the full comparison, our OAuth/OIDC vs SAML for federation guide breaks down when each one is the right fit.

CIAM Federation: Social Login and Bring-Your-Own-Identity

In customer-facing applications, federation means letting users authenticate with their existing identity from Google, Apple, or a social provider. This is a conversion-critical feature: registration friction drops, security stays intact, and the user doesn't need to remember another password. For Ory's CIAM customers, social login isn't optional. It's expected.

For teams managing the OAuth 2.0 and OIDC federation layer, Ory Hydra is an authorization server that handles token issuance, validation, and the full OAuth 2.0 grant flow without coupling identity management to authorization.

For organizations that need enterprise SAML SSO (federating workforce identity across existing IdPs like Azure AD or Okta), Ory Polis is an enterprise SSO solution that supports SAML-based federation alongside modern OIDC flows.

Explore Ory Hydra for authorization via OAuth 2.0 and OIDC

Explore Ory Polis for SAML SSO

How the 4 Pillars Work Together

The four IAM pillars are interdependent: identity administration creates the digital identity first, authentication verifies it at login, authorization enforces what that identity is permitted to do, and federation extends the verified identity across multiple systems without requiring re-authentication.

A Real-World IAM Sequence

Walk through the lifecycle of a new employee. IT provisions their identity (Pillar 3: administration). They log in with MFA (Pillar 1: authentication). They're granted role-appropriate access to their tools (Pillar 2: authorization). They use SSO to access cloud applications without re-entering credentials (Pillar 4: federation). Each pillar fires in sequence, every working day, for every employee. That sequence is the whole IAM stack in motion.

Where Each Pillar Can Break

Administration failure: orphaned accounts after departure enable unauthorized access.
Authentication failure: weak credentials or missing MFA create breach vectors.
Authorization failure: over-privileged accounts lead to broken access control (OWASP A01).
Federation failure: misconfigured SSO or token validation gaps create impersonation risk.

A failure-mode view per pillar is the most useful audit framework most teams can adopt. If you can answer "where would we break first?" for each pillar, you've already done more than most organizations.

The 4 IAM Pillars in Modern Architecture

In modern cloud-native and zero-trust architectures, the four IAM pillars operate without a trusted perimeter: every authentication has to be verified, every authorization has to be evaluated at request time, identity administration has to include non-human identities, and federation has to extend to APIs and machine-to-machine flows.

Zero Trust and the IAM Pillars

Zero trust removes the implicit trust of "inside the network." Authentication becomes continuous rather than one-time. Authorization has to be evaluated at every request, not assumed from role alone. Identity administration has to handle devices and workloads, not just users. Federation has to cover cross-cloud access without VPN dependency. The pillars don't change. Their operating conditions do. For depth on this, see implementing zero trust API security.

CIAM: The 4 Pillars for Customer Identity

CIAM applies the same four pillars to external users. Authentication prioritizes low-friction flows (social login, passkeys). Authorization controls feature access and data visibility (often tied to subscription tiers). Administration handles self-service registration and profile management. Federation enables sign-in with existing consumer identity providers. The shape of the pillar is the same. The success metric (conversion alongside security) changes. The customer identity and access management hub covers this in depth.

Agentic AI and Non-Human Identity

AI agents, service accounts, and machine identities require IAM treatment across all four pillars. Authentication for agents uses client credentials and certificates rather than passwords. Authorization for agents has to be scoped tightly under least privilege. Administration has to provision and deprovision agent identities as services are deployed or retired. Federation enables agents to call APIs on behalf of users via OAuth delegation. This space is moving quickly, and the pillars are how you keep up without losing the plot.

Implementing the 4 IAM Pillars

Each of the four IAM pillars can be implemented with commercial or open source tooling from Ory. Teams don't need a monolithic vendor platform, but they do need to ensure the tools they choose cover all four pillars and integrate cleanly across them.

IAM Pillar	Ory Product	What It Covers
Authentication	Ory Kratos	Registration, login flows, MFA, passkeys, session management
Authorization	Ory Keto	ReBAC / RBAC policy enforcement, permission checks, access control
Identity Administration	Ory Kratos	User provisioning, profile management, self-service flows, account lifecycle
Federation / SSO (OIDC)	Ory Hydra	OAuth 2.0 and OIDC authorization server, access token issuance and validation
Federation / SSO (SAML)	Ory Polis	Enterprise SAML SSO, IdP federation, workforce single sign-on

Build vs Delegate: The IAM Decision Framework

Three questions determine whether each pillar gets built in-house or delegated to purpose-built tooling. Does your team have the capacity to build and maintain each pillar from scratch? Most teams underestimate the long-tail security maintenance cost of this. Does your compliance posture require auditability that homegrown solutions can't easily provide? Regulated industries usually answer yes. Do your scaling requirements demand infrastructure-grade reliability? If you're heading toward millions of identities, the answer is almost always yes.

Teams that answer no, yes, or yes to any of these questions should delegate to purpose-built open source tooling. The maintenance burden of running each pillar yourself is real, and the security and compliance cost of running them poorly is bigger.

See how Ory's stack covers all four pillars

The four pillars aren't an academic framework. They're the operating layout of every modern identity stack, whether the team building it knows the framework by name or not. Treating each pillar as a real engineering concern (with its own decisions, its own tooling, and its own failure modes) is what separates IAM that scales from IAM that breaks. The good news: each pillar has a clean open source implementation available today, and they're designed to integrate. The harder news: getting all four right is more work than any single product page suggests, which is why audits keep finding gaps.