A context-based request is an access request that includes a business scope value such as company code, plant, or sales organization. It lets the identity system grant similar SAP roles differently depending on the organisational boundary, which improves precision when roles are otherwise nearly identical.
Expanded Definition
A context-based request is a permission decision that changes based on business scope, such as company code, plant, sales organisation, or cost centre. In SAP and adjacent IAM patterns, the same user or service identity may receive different access depending on the organisational boundary attached to the request.
This makes the term more precise than ordinary role assignment. RBAC answers whether a role exists, while a context-based request answers whether the role applies in the current business context. In practice, it often sits alongside ABAC and policy evaluation, although usage in the industry is still evolving and definitions vary across vendors. For broader identity governance context, NHI Management Group’s Ultimate Guide to NHIs explains why boundary-aware access becomes critical when identities, secrets, and automation scale quickly. NIST’s NIST Cybersecurity Framework 2.0 provides the governance lens for controlling access in a way that reflects business risk and operational scope.
The most common misapplication is treating a context-based request as a simple role lookup, which occurs when implementers ignore the organisational field that should narrow or expand the resulting access.
Examples and Use Cases
Implementing context-based requests rigorously often introduces policy complexity, requiring organisations to weigh access precision against heavier maintenance and testing overhead.
- A finance user requests an SAP role that is valid for one company code but not another, so the system grants the permission only within the approved entity boundary.
- A procurement approver can approve invoices for one plant, but the same role is denied for a different plant because the organisational context is not present.
- An HR administrator receives access for one regional sales organisation, while a sister region requires a separate request and approval path.
- An automation account uses a context-based request to limit ERP transactions to a defined business unit, reducing the blast radius if the account is abused. That boundary discipline aligns with guidance in the Ultimate Guide to NHIs and with NIST’s access-control emphasis in the NIST Cybersecurity Framework 2.0.
- A shared service identity is allowed to post journal entries only when the request carries the correct organisational scope, preventing cross-entity posting errors.
These patterns matter because the same functional role can be legitimate in one business unit and inappropriate in another, even when the underlying duties are almost identical.
Why It Matters in NHI Security
Context-based requests are not just an SAP convenience. They are a control point for limiting overbroad access, especially where NHIs or highly privileged automation interact with ERP, finance, or supply-chain data. If scope values are missing, inherited incorrectly, or bypassed during provisioning, a seemingly valid request can become a broad entitlement across multiple legal entities or plants. That undermines least privilege and makes access reviews harder to trust.
This is especially relevant in NHI-heavy environments, where excessive privilege is common. NHI Management Group’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. In governance terms, the business context attached to a request becomes part of the control evidence, not just a workflow detail. NIST’s NIST Cybersecurity Framework 2.0 reinforces this by tying identity decisions to protected business outcomes and access governance.
Organisations typically encounter the consequences only after an access review, audit finding, or cross-entity data incident, at which point context-based request logic becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Context-bound access decisions help prevent overprivileged NHI entitlements across business scopes. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be enforced according to approved business scope and least privilege. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires policy decisions that consider context rather than static role membership alone. |
Check that each request’s scope matches the minimum required access before approval.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and context-based access decisions?
- How should security teams use context-based authentication in high-risk environments?
- What is the difference between context-based authentication and static access control?
- What is the difference between birthright access and request-based access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
