Press enter or click to view image in full size
IAM goes together like peanut butter and jelly. But maybe “Identity” and “Access Management” need to be broken apart. They are two different layers with different data models, protocols, and runtime responsibilities
The Identity layer establishes and verifies an entity. The entity may be a human, workload, agent, or organization. This layer manages identifiers, credentials, authentication, attestation, key material, and trust relationships. Its systems include passkeys, FIDO passkeys, identity orchestration, OAuth, SPIFFE, WIMSE, PKI, registries, and organizational identifiers. Its output is verified identity context: who or what is making the request, how it authenticated, which authority vouched for it, and what security properties were established.
The Access Management layer consumes that context to control actions on resources. It includes policy authoring, authorization engines, PDPs, PEPs, IGA, PAM, federation management, schemas, and shared security signals.
Its output is a decision: whether a capability should be allowed under the current conditions.
These layers have different lifecycles. Identity changes when credentials, bindings, or trust relationships change. Access changes when policies, entitlements, risk, resources, or business requirements change.
Collapsing both layers into one product creates tight coupling between authentication and policy enforcement. It also makes authorization harder to distribute across APIs, workloads, gateways, databases, and endpoints.
Identity supplies verified principals.
Access Management rations capabilities.
Perhaps it’s time for “IAM architecture” to stop treating them as one system.