The four pillars of IAM and where identity stacks break

At a glance

What this is: This is an IAM framework explainer showing how authentication, authorization, administration, and federation fit together and why gaps in any one layer create compounding risk.

Why it matters: IAM practitioners need this because the same pillar logic now applies across workforce identity, CIAM, service accounts, and API-driven access patterns, not just human login flows.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Ory's full explanation of the four pillars of IAM

Context

Identity and access management is the discipline that governs who or what can access which resources, under what conditions, and for how long. In practice, that means the stack has to handle authentication, authorization, identity administration, and federation as linked controls, not isolated features.

The four-pillar model is useful because IAM failures rarely stay local. Weak identity administration creates orphaned accounts, weak authorization creates over-privilege, and weak federation can extend bad trust decisions across systems. That is increasingly true for NHI estates as well, where service accounts and API tokens need the same lifecycle discipline as human users.

Key questions

Q: How should security teams audit IAM activity across multiple applications?

A: Security teams should centralise identity telemetry, normalise event fields, and correlate authentication, privilege, and access activity across SaaS, cloud, and on-prem systems. The goal is to reconstruct the identity journey quickly enough to support containment, forensics, and compliance. If logs cannot be joined, the organisation has monitoring, not auditing.

Q: Why do NHI and service account programmes need the same IAM structure as human identity?

A: Because non-human identities still require proof of identity, scoped access, lifecycle management, and trust extension across systems. The mechanics differ, but the governance questions are the same. If you do not manage machine identities through the same control logic, secret sprawl and privilege drift become structural rather than exceptional.

Q: What breaks when identity administration is weak in a federated IAM stack?

A: Federation will happily propagate whatever upstream state it receives, including stale accounts, over-privileged roles, and incomplete offboarding. That means bad lifecycle hygiene becomes a trust problem across every connected application. If the source identity is wrong, the federated assertion is only distributing the error faster.

Q: How should teams choose between RBAC and ABAC for application authorization?

A: Use RBAC when access maps cleanly to business roles and the number of exceptions is low. Use ABAC when decisions depend on context such as device, location, resource sensitivity, or time. Most teams need both: RBAC for baseline access and ABAC for exceptions that would otherwise create role sprawl.

Technical breakdown

Authentication as the trust anchor for identity systems

Authentication proves an identity is who or what it claims to be by validating a credential, such as a password, passkey, certificate, or client secret. In modern stacks, the session or token issued after authentication becomes the artefact downstream systems trust. That makes authentication more than login UX. It is the start of every subsequent access decision, and if the assurance level is weak, every later control inherits that weakness. For CIAM, the challenge is balancing friction and assurance. For NHI and workload identity, the challenge is moving away from reusable shared secrets toward stronger machine authentication patterns.

Practical implication: Treat authentication assurance as the foundation for every later access decision, and do not let weaker credential types persist where stronger machine identity mechanisms are available.

Authorization, RBAC, ABAC, and the least-privilege problem

Authorization decides what an authenticated identity may do with a specific resource or action. RBAC is simple and auditable because permissions are assigned through roles. ABAC adds context, such as device state, environment, or resource sensitivity, which is useful when access has to change dynamically. The important point is that authorization is where least privilege becomes real. If the policy model is too coarse, or if roles accumulate permissions over time, the result is access creep and broken access control. In zero trust environments, authorization cannot be assumed once at login; it has to remain valid at request time.

Practical implication: Review whether your access model can enforce task-scoped privilege at request time instead of relying on broad roles that age into over-privilege.

Identity administration and federation as lifecycle controls

Identity administration creates, updates, and removes identities across their lifecycle, while federation extends a trusted identity across systems without re-authentication. Administration is where provisioning, maintenance, and deprovisioning either stay coherent or fragment into silos. Federation depends on that coherence because a federated session is only as trustworthy as the source identity and its lifecycle state. In workforce IAM, this controls joiners, movers, and leavers. In NHI programmes, the same logic applies to service accounts, API keys, certificates, and delegated access paths. If the lifecycle is not clean, federation becomes a propagation layer for stale access.

Practical implication: Align provisioning, change, and offboarding events across directories, applications, and federated trust paths so stale identities do not survive beyond their business purpose.

Threat narrative

Attacker objective: The objective is to turn a single identity failure into broad access across applications, data, and trust boundaries.

1. Entry begins when an attacker or malicious actor gains a valid identity artefact, such as a password, token, API secret, or federated session.
2. Escalation occurs when the compromised identity carries broader permissions than the task required, allowing movement from initial access into higher-value systems.
3. Impact follows when weak authorization or stale lifecycle state lets the actor read, modify, or delete data across multiple connected services.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication, authorization, administration, and federation are not separate categories of IAM work. They are one dependency chain, and the weakest link defines the operational ceiling of the whole stack. Ory is right to present the pillars as a system rather than a menu of features. If identity administration is fragmented, authentication assurance weak, or authorization too coarse, federation simply spreads those errors further. Practitioners should audit the chain as a single control surface, not as four independent projects.

The four-pillar model becomes more useful, not less, as IAM expands beyond humans. The same structure applies to CIAM, service accounts, workload identity, and delegated machine access. That matters because NHI estates now exceed human identity counts in many organisations, so a human-only IAM mental model underestimates the scale and blast radius of access decisions. Teams should apply the pillar model consistently across actor types, or governance will remain partial.

Identity administration is the pillar most organisations underinvest in, because its failures are slow and cumulative rather than immediate. Orphaned accounts, stale roles, and incomplete deprovisioning rarely announce themselves until audit or incident time. That makes lifecycle discipline the governance backbone of the full model, especially where federation depends on clean upstream state. The practical conclusion is simple: if lifecycle state is unreliable, every downstream trust decision is suspect.

Federation is often treated as a convenience layer, but it is really a trust amplification layer. SSO and cross-system trust reduce friction, yet they also extend the consequences of bad identity state into more applications and more organisations. That is why federation cannot be evaluated apart from assurance, lifecycle, and authorization quality. The implication for practitioners is to govern federated trust as an identity control, not a productivity feature.

Four-pillar IAM thinking helps separate architecture from procurement, which is still one of the most useful discipline shifts in the market. Organisations do not need one monolithic platform to cover the model, but they do need visible ownership for each pillar and clear control boundaries between them. That framing is especially valuable for IAM, IGA, PAM, and NHI teams that have historically bought tools in silos. The next step is to map which pillar each tool actually governs and where the gaps remain.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 5.7% of organisations have full visibility into their service accounts, which means lifecycle and trust decisions are still being made with incomplete inventory data.
• That is why the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right next resource for teams trying to close the gap.

What this signals

Identity programmes will keep failing if they continue to treat the four pillars as separate workstreams. The practical signal from this article is that audit, engineering, and governance teams need a single control map that traces identity from creation through access to offboarding. Once that map exists, it becomes much easier to see which controls protect people, workloads, and service accounts differently and where the handoffs are currently weak.

For NHI programmes, the next maturity step is not more tooling but clearer lifecycle ownership. When identities outnumber humans by 25x to 50x, the governance burden shifts from one-off access decisions to repeatable trust administration. That is the logic behind the NHI Lifecycle Management Guide, which helps teams move from ad hoc credential handling to governed state changes.

The strongest programmes will align pillar ownership to operating reality, not organisational charts. That means authentication, authorization, lifecycle, and federation must each have measurable controls, and those controls must extend into CIAM, workload identity, and delegated access paths rather than stopping at workforce SSO.

For practitioners

• Map each pillar to a named control owner Assign authentication, authorization, identity administration, and federation to explicit control owners rather than a single generic IAM programme. Use that map to identify where policy, engineering, and operations currently overlap or leave gaps, especially in hybrid estates.
• Audit the weakest pillar first Review your stack for the first point of failure across the chain. If lifecycle is fragmented, fix provisioning and deprovisioning before expanding federation. If authorization is coarse, tighten task-scoped access before adding more login options.
• Extend the same model to NHIs and service accounts Apply the four-pillar lens to workload identities, API credentials, and delegated access paths. Treat service accounts as governed identities with lifecycle, authentication, authorization, and trust-extension requirements, not as implementation details.
• Separate CIAM design goals from workforce IAM goals Do not copy workforce access patterns into customer identity flows. CIAM often needs lower-friction authentication, different federation options, and tighter data-scoping decisions than internal IAM.

Key takeaways

• The four pillars model matters because IAM failures compound across authentication, authorization, administration, and federation rather than staying isolated.
• The article’s core value is architectural: it gives teams a way to audit which pillar is weak before they overbuy or overcomplicate the stack.
• The same pillar logic now applies across human identity, CIAM, and non-human identities, which makes lifecycle and trust boundaries the real governance fault lines.

Key terms

• Authentication: Authentication is the process of proving that an identity is genuine. In practice, it uses credentials, certificates, biometrics, or other factors to establish who or what is requesting access. For NHIs, the key issue is whether the proof is strong enough to resist theft, replay, or misuse.
• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
• Identity Management: The discipline that creates, updates, and retires identity records so the organisation knows who or what each subject is. In practice, it governs attributes such as role, department, manager, and lifecycle state, which later drive access decisions and audit evidence.
• Federation entity: A federation entity is an organisation or technical participant that publishes metadata describing its keys, endpoints, and capabilities. It is the unit of participation inside the federation, and it can be an identity provider, relying party, wallet provider, or AI agent acting on behalf of a system.

What's in the full article

Ory's full article covers the implementation detail this post intentionally leaves at the architecture level:

• How Ory maps authentication, authorization, identity administration, and federation to specific products and implementation patterns
• The article's side-by-side explanation of foundational versus enterprise-vendor pillar models and why the distinction matters in practice
• Detailed examples of passkeys, RBAC, ABAC, OAuth/OIDC, SAML, and SCIM in production IAM design
• Guidance on how CIAM and workforce IAM differ while still using the same four-pillar structure

👉 Ory's full article expands the implementation details behind each IAM pillar and how they fit together in production.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.