Identity and access management (IAM) establishes and manages the identity foundation, while runtime access control evaluates whether a sensitive request should be authorized under the policy and context that apply when it is attempted. They are complementary: IAM helps establish who or what is acting and what access relationships exist; runtime access control determines whether the requested sensitive action should be allowed.
Key takeaways
- IAM establishes and manages identities, authentication and access relationships.
- Runtime access control determines whether a sensitive request should be authorized under current policy and context.
- Available permissions or privileges can inform the decision without automatically determining it.
- Runtime access control complements IAM rather than replacing it.
Runtime access control vs IAM at a glance
| Dimension | Runtime access control | IAM |
|---|---|---|
| Primary question | Should this identity perform this action on this resource under current conditions? | How should identities, authentication and access relationships be established and managed? |
| Typical scope | Authorization decisions for current sensitive requests and their enforcement | Identity lifecycle, authentication, federation, accounts, groups, roles and access administration, depending on the system |
| Decision timing | When sensitive access or an action is attempted | Varies across authentication, provisioning, administration and policy workflows |
| Key input | Current request plus identity, policy and relevant context | Identity attributes, authenticators, accounts, groups, roles and administrative policy |
| Relationship | Uses the identity foundation and adds point-of-action authorization | Provides identity and access context that can inform authorization |
What IAM provides
IAM is a broad discipline for establishing and managing digital identities and their access relationships. Depending on the architecture, IAM can include identity lifecycle management, authentication, federation, account administration, groups, roles and access policy.
Those functions are foundational. A runtime authorization system needs reliable information about who or what is acting. Runtime access control therefore complements the identity foundation rather than redefining authentication or identity lifecycle management.
The distinction between identity verification and action authorization also appears in established access-control guidance. NIST SP 800-63B-4 addresses authentication and authenticator management, while NIST SP 800-162 describes authorization decisions based on the subject, requested operation, object, policy and relevant attributes.
What runtime access control adds
Runtime access control makes the current sensitive request part of the authorization decision. IAM can establish that an employee belongs to the engineering organization, authenticate that employee and associate the employee with a role. Those facts are important authorization inputs, but they do not by themselves determine whether the engineer should modify a particular production resource during the current task.
Runtime access control evaluates the requested action, target resource, policy and relevant context when the action is attempted. Runtime authorization supplies the decision mechanism, and enforcement separately applies the resulting decision at an appropriate control point.
The distinction is not “identity versus security.” It is the difference between managing the identity and access foundation and deciding whether a particular sensitive request should be allowed.
How IAM and runtime access control work together
- IAM supplies identity and authentication context. An identity provider or other identity system authenticates the user, workload or other actor and supplies relevant identity information.
- Access relationships describe available access. Roles, groups and entitlements can establish which permissions or privileges may be available to the identity.
- A sensitive request occurs. The identity attempts an action on a protected resource.
- Runtime authorization evaluates the request. Policy considers the identity, requested action, target resource and relevant current context.
- The result is enforced. The authorization decision is applied at the control point responsible for the requested action or authorization state.
The identity-provider-specific relationship is covered in how identity providers and runtime access control work together.
Example: an IAM role is an input, not the final answer
An engineer may belong to an IAM group that establishes eligibility for production work. That group membership can inform authorization, but it does not have to authorize every production action automatically. When the engineer requests a sensitive change, runtime access control can evaluate the specific resource, action, task and policy before the requested action proceeds.
Does runtime access control replace IAM?
No. Runtime access control depends on a trustworthy identity foundation and is not a replacement for authentication, federation or identity lifecycle management. It addresses a different layer of the access-control problem: whether a current sensitive request should be authorized and how that decision is enforced.
Organizations can therefore retain their existing identity systems while adding runtime authorization for sensitive actions that require current-context decisions.
Where identity governance fits
Identity governance addresses lifecycle and governance questions such as who should have access, how access is provisioned or reviewed and whether entitlements remain appropriate over time. Runtime authorization addresses whether a current action should be allowed.
For the broader three-way distinction, see authentication vs authorization vs access governance.
Frequently asked questions
Is runtime access control the same as IAM?
No. IAM provides the identity and access foundation. Runtime authorization evaluates current sensitive requests, and enforcement points apply the resulting decisions. The controls can work together and address different layers of the same access path.
Does IAM perform authorization?
IAM systems can include authorization-related roles, groups, policies and access controls. The category is broad. The useful architectural question is whether a particular workflow evaluates the current action and where the resulting decision is enforced.
Does runtime access control replace an identity provider?
No. An identity provider establishes authentication and supplies identity context. Runtime access control can use that context when deciding whether a sensitive action should be permitted. For more detail, see how identity providers and runtime access control work together.
Why isn't an IAM role enough for every sensitive action?
A role can establish available permissions or eligibility, but the current action may require narrower scope or additional context. Runtime authorization can determine whether the specific request should be allowed.
Summary
IAM establishes and manages the identity foundation, including authentication and access relationships. Runtime access control complements that foundation by evaluating whether a current sensitive action should be authorized under current policy and context and by applying the resulting decision at an appropriate enforcement point. Available permissions or privileges can inform the decision without automatically determining it.
Sources
- NIST, SP 800-63B-4: Digital Identity Guidelines: Authentication and Authenticator Management.
- NIST, SP 800-162: Guide to Attribute Based Access Control Definition and Considerations.