Published:
Estimated reading time:
7-9 minutes
Traditional access control asks a relatively simple question: Does this identity have permission to perform this action?
That question is still important, but modern cloud environments give us much more information that can help determine whether access should be granted. A developer may normally be allowed to administer a production environment, for example, but should that access be available at 2:00 AM when the developer is not on call, using an unmanaged device with known vulnerabilities?
Context-Based Access Control (CBAC) adds those real-time circumstances to the access decision.
Instead of deciding access only from a user's role or attributes, CBAC can consider signals from across the organization, such as identity, device security, on-call status, cloud environment, workload identity, vulnerability data, incident state, location, time, and the specific action being requested.
The result is an access model that can answer a more useful question:
Given everything we know right now, should this identity receive this access to this environment for this purpose?
What Is Context-Based Access Control?
Context-Based Access Control is an access-control model in which authorization decisions incorporate information about the current circumstances surrounding an access request.
Those circumstances are the context.
Imagine two requests for exactly the same production access from exactly the same engineer.
The first request occurs during a production incident. The engineer is currently on call, authenticated with MFA, using a company-managed device that meets security requirements, and requesting access to the production environment their team owns.
The second request occurs several weeks later. There is no active incident, the engineer is not on call, the device is unmanaged, and the request targets an environment owned by another business unit.
The identity may be the same. The requested role may even be the same. But the context is completely different.
CBAC allows an organization to treat those requests differently.
Why Traditional Access Control Is Not Always Enough
Most organizations already use some combination of roles, groups, policies, and identity attributes to determine access.
Those mechanisms remain useful. The problem is that they often describe relatively static facts.
An engineer belongs to the Platform Engineering group. An administrator has the Production Administrator role. An application belongs to the payments team. A workload is labeled as production.
Real-world risk is much more dynamic.
An employee can go on call. A device can become vulnerable. An incident can begin. An application can move into a critical operational state. A workload can execute from an unexpected environment. A privileged operation can be requested against a particularly sensitive cloud account.
Access decisions that ignore those circumstances lose valuable information.
CBAC introduces that information into the decision.
What Counts as Context?
Context can come from almost anywhere an organization has reliable information relevant to the access decision.
Identity Context
Identity systems can provide information such as who the requester is, which groups they belong to, how they authenticated, whether MFA was used, and whether the identity is currently active.
For machine identities, the relevant information might include workload identity, application ownership, runtime environment, deployment pipeline, or the process that initiated the request.
Device Context
Mobile device management and endpoint security systems can provide signals about the device making the request.
An organization might consider whether the device is company managed, encrypted, compliant with security policy, running endpoint protection, or affected by known vulnerabilities.
A privileged request from a healthy corporate laptop may therefore be treated differently from the same request originating from an unmanaged endpoint.
Operational Context
Operational systems provide another valuable source of information.
An on-call platform such as PagerDuty can indicate whether an engineer is currently responsible for responding to incidents. An ITSM system can identify an active incident or approved change. A ticketing system might provide the business justification associated with a request.
This creates the possibility of connecting access to what is actually happening operationally.
Security Context
Vulnerability-management and endpoint-security platforms can contribute signals about current security posture.
A device that was compliant yesterday might have a critical vulnerability today. A workload might suddenly be associated with a security finding. An endpoint-detection system might indicate suspicious behavior.
CBAC allows access decisions to respond to those changing conditions.
Cloud Context
The target itself also matters.
Access to a development account should not necessarily be evaluated the same way as privileged access to a production cybersecurity environment.
Relevant context might include the cloud provider, account or subscription, environment, business function, owner, criticality, or organizational grouping associated with the target.
Request Context
Finally, the requested operation matters.
Reading configuration data is different from modifying IAM policies. Restarting a development workload is different from deleting a production database.
The scope, privilege level, target, requested duration, and intended operation can all become part of the decision.
CBAC vs. RBAC
Role-Based Access Control, or RBAC, grants permissions according to roles.
A developer might receive a Developer role. A database administrator might receive a Database Administrator role. Members of those roles inherit the permissions assigned to them.
RBAC is valuable because it is understandable and relatively straightforward to administer. It also maps naturally to organizational responsibilities.
But roles alone usually cannot answer questions such as:
Is the engineer currently on call?
Is the device compliant?
Is there an active production incident?
Is the request occurring from an expected environment?
Is the target a development or production system?
Does the requested operation match the current situation?
CBAC does not necessarily replace RBAC. It can make RBAC more intelligent by adding context to when and how a role may be used.
An organization might determine that an engineer is eligible for a Production Administrator role based on RBAC, while CBAC determines whether that role should actually be granted right now.
CBAC vs. ABAC
Attribute-Based Access Control, or ABAC, evaluates attributes associated with subjects, resources, actions, and environments.
For example, a policy might allow access when:
user.department = resource.department
or when:
user.environment = resource.environment
ABAC is powerful because it allows access policies to become much more expressive than simple role membership.
CBAC is closely related, but the emphasis is different. Context-based access focuses particularly on incorporating current, situational signals into an access decision.
Those signals may themselves be represented as attributes. The conceptual distinction is that CBAC asks organizations to consider not just who the identity is or what properties a resource has, but what is happening right now around the request.
In practice, modern access systems can combine RBAC, ABAC, and contextual decision-making rather than forcing organizations to choose only one.
CBAC and Just-in-Time Access
Context becomes particularly powerful when combined with Just-in-Time (JIT) access.
JIT answers:
When should access exist?
CBAC helps answer:
Given the current circumstances, should we grant it?
Consider an engineer requesting production administrator access.
The organization might require that the engineer be eligible for the role, currently on call, authenticated with MFA, using a compliant corporate device, associated with the team that owns the environment, and responding to an active incident.
If those conditions are satisfied, JIT access can be created.
When the approved period ends, the access disappears.
This creates a fundamentally different model from assigning the engineer permanent production administrator privileges simply because they might eventually need them.
CBAC and Ephemeral Access
Context-based decisions become even more valuable when the resulting access is ephemeral.
Suppose an engineer meets all the contextual requirements for production access at 10:15 AM.
That does not mean those conditions will still be true tomorrow.
The incident may end. The engineer's on-call shift may finish. The device's security posture may change. The operational need may disappear.
If the authorization remains permanently assigned, the original contextual evaluation gradually becomes irrelevant.
Ephemeral access solves that problem by allowing access to disappear after its purpose has been fulfilled.
A future request can then be evaluated against future context rather than relying on a decision made days or months earlier.
Context Is Not Just for Humans
Context-based access is equally important for machines.
Applications, workloads, CI/CD pipelines, automation systems, and AI agents increasingly need access to cloud infrastructure. Their context looks different from human context, but the underlying question is the same.
For a workload, an organization might consider the workload's identity, runtime environment, application owner, deployment pipeline, security posture, target cloud environment, requested operation, and the process that initiated the request.
A deployment pipeline modifying infrastructure during an approved release window may represent a very different risk than an unexpected process requesting the same permissions from an unknown runtime environment.
Machine access therefore benefits from contextual evaluation just as human access does.
CBAC and AI Agents
AI agents make contextual access even more important.
An AI agent may be capable of investigating infrastructure, generating code, analyzing security findings, or proposing operational changes. Giving such an agent broad permanent cloud permissions simply because it may need them eventually recreates the same standing-privilege problem organizations are trying to eliminate for humans.
Instead, the agent's identity and current task can become part of the access decision.
The system can consider what initiated the task, what the agent is attempting to accomplish, which environment it needs, what tools it requires, what permissions are necessary, and how long those permissions should exist.
This creates an important principle for AI-driven cloud operations:
AI capability should not automatically imply AI authority.
An agent may be technically capable of performing many operations while being authorized to perform only the specific operations appropriate to its current task and context.
Context Can Come From Outside the Cloud
One of the most important ideas behind CBAC is that cloud providers do not have all the information necessary to understand organizational context.
AWS may know which account contains a resource. Azure may know which subscription contains it. Google Cloud may know which project contains it.
But the broader enterprise may know much more.
An on-call system knows who is responding to an incident. An MDM platform knows whether a laptop is compliant. A vulnerability-management platform knows whether a critical vulnerability exists. An identity provider knows how the user authenticated. An ITSM system knows whether an approved change is underway.
Individually, each system sees one part of the situation.
Context-based access can bring those signals together to make a more informed decision.
Context Changes the Meaning of Least Privilege
Least privilege is usually described as giving an identity only the permissions it needs.
That is necessary, but incomplete.
Modern least privilege should consider several dimensions:
What permissions are required?
Where are they required?
Who or what is requesting them?
Why are they required?
When should they exist?
Under what conditions should they be granted?
How long should they remain available?
CBAC adds the conditions surrounding the request to the least-privilege model.
Combined with JIT and ephemeral access, organizations can move from static permission assignment toward dynamic authorization.
A Practical CBAC Example
Imagine a production engineer receives an alert about a critical service.
The engineer requests elevated access to the production environment.
A contextual access system could evaluate several signals:
The engineer is currently on call.
The identity authenticated using MFA.
The request comes from a managed corporate device.
Endpoint security reports the device as healthy.
An active incident exists in the ITSM system.
The requested cloud environment belongs to the engineer's team.
The environment is classified as production.
The requested role is appropriate for incident response.
The requested duration is 60 minutes.
The organization can then grant temporary access because the request satisfies its policies.
Now imagine the same engineer makes the same request two weeks later from an unmanaged personal computer with no active incident and while not on call.
RBAC may still say the engineer is eligible to administer the system.
Context says the access should not be granted.
That difference is the value of CBAC.
The Challenge of Context-Based Access
More information does not automatically create better security.
Contextual policies can become difficult to understand if organizations collect too many signals or create complicated rules without clear reasons.
A successful CBAC strategy should therefore focus on signals that materially change risk.
Organizations should know where each signal originates, how trustworthy it is, how current it is, what happens when the source system is unavailable, and why that signal affects the decision.
Context should make access decisions more intelligent, not simply more complicated.
Context and Multi-Cloud Environments
CBAC becomes especially valuable in multi-cloud environments because organizational context exists above the individual cloud provider.
AWS accounts, Azure subscriptions, and Google Cloud projects use different identity systems, permission models, and resource hierarchies.
The organization, however, may think in terms of the same teams, applications, environments, owners, incidents, devices, and business functions across all three providers.
A contextual access layer can use those organization-level signals when evaluating access regardless of which cloud contains the target.
This allows organizations to begin defining access around their operating model, rather than allowing each cloud provider's hierarchy to define it for them.
How Strato Cloud Approaches Context-Based Access
Strato Cloud combines contextual information with dynamic cloud access across AWS, Azure, and Google Cloud.
Cloud accounts, subscriptions, projects, namespaces, and synced cloud identities can carry cloud-agnostic organizational context such as ownership, environment, business function, and criticality. Access decisions can also incorporate external enterprise signals from systems responsible for identity, device posture, vulnerability management, on-call schedules, incidents, and other operational context.
This context can then inform whether access should be granted, what access is appropriate, where it should apply, and how long it should exist.
Combined with Just-in-Time access, ephemeral authorization, and temporary credentials, the goal is not simply to answer whether an identity can access something.
It is to answer the more meaningful question:
Should this identity have this access, to this environment, for this purpose, right now?
Frequently Asked Questions
What does CBAC stand for?
CBAC stands for Context-Based Access Control. It describes an access-control approach that incorporates current circumstances and contextual signals into authorization decisions.
Is CBAC the same as RBAC?
No. RBAC primarily determines access based on roles. CBAC considers the circumstances surrounding an access request. The two approaches can work together, with RBAC establishing eligibility and context determining whether eligible access should be granted at a particular moment.
Is CBAC the same as ABAC?
They are closely related. ABAC evaluates attributes associated with identities, resources, actions, and environments. CBAC emphasizes current and situational information surrounding the request. Many practical systems use attributes to represent contextual information, so the approaches can complement each other.
What are examples of context in access control?
Examples include device compliance, MFA status, on-call status, active incidents, vulnerability information, location, time, environment criticality, resource ownership, workload identity, application ownership, and the requested operation.
Can CBAC be used for machine identities?
Yes. Workloads, applications, pipelines, automation, and AI agents all have contextual information that can influence access decisions. Runtime environment, workload identity, application ownership, security posture, and requested operation are examples.
Does CBAC replace least privilege?
No. CBAC extends least privilege by adding situational conditions to decisions about what access an identity needs, where it needs it, and when that access should exist.
How does CBAC work with JIT access?
CBAC can evaluate whether current conditions justify granting access, while JIT ensures that approved access exists only when needed. Combined with ephemeral authorization, the access can disappear automatically after the approved period.
Related Reading
RBAC vs. ABAC vs. CBAC: What's the Difference?
How Context-Based Access Control Works in Multi-Cloud Environments
