Context-based SAP role requests show where identity governance breaks

At a glance

What this is: This is an analysis of how SAP context values shape role requests in Identity Manager and why those values matter for access granularity.

Why it matters: It matters because mis-modeled context can turn otherwise controlled SAP access into overbroad entitlement drift across business units.

👉 Read One Identity's explanation of context-based SAP role requests

Context

In SAP role administration, context is the business value that separates one otherwise similar entitlement from another, such as a company code, plant, or sales organization. That matters for IAM because the same job function can require different access boundaries depending on where the work happens, and those boundaries must be represented accurately in governance workflows.

For NHI and IAM practitioners, the issue is not just provisioning efficiency. It is whether the access model can express organizational specificity without creating duplicate roles, inconsistent requests, or hidden privilege spread. In practice, context-based requests are a governance pattern for reducing role sprawl, but only if the underlying role design is disciplined and reviewable.

Key questions

Q: How should teams govern context-based SAP role requests?

A: Teams should treat context as a core part of the entitlement, not as optional request metadata. That means standardizing context values, tying them to approval rules, and checking that the provisioned access matches the approved business unit. The goal is to prevent similar roles from becoming loosely governed duplicates.

Q: Why do context-based requests matter for IAM governance?

A: They matter because they let identity teams express business-specific access differences inside otherwise similar SAP roles. Without that separation, organizations tend to overgrant access or create multiple inconsistent roles for the same duty. Context gives governance a way to preserve least privilege across organizational units.

Q: What is the difference between role-based access and context-based access in SAP?

A: Role-based access assigns permissions through a role construct, while context-based access adds a business attribute that narrows where that role applies. In SAP, that context can be a company code or plant. The difference is whether the entitlement is generic or scoped to a specific organisational boundary.

Q: When does context-based provisioning create more risk than it reduces?

A: It becomes risky when the context vocabulary is inconsistent, duplicated, or poorly reviewed. In that case, automation speeds up the delivery of access that reviewers cannot reliably distinguish. The result is faster provisioning but weaker governance, which is the opposite of what identity controls should achieve.

Technical breakdown

How context values change SAP role structure

In the article’s model, a SAP role is not fully defined until a context value is attached. The context can be a company code, plant, or sales organization, and it distinguishes two access packages that otherwise look identical. This is a common identity governance pattern in ERP systems: the entitlement is technically similar, but the business scope is different. The governance risk appears when context becomes a loose label instead of a controlled attribute, because then role reuse starts to mask access divergence across units.

Practical implication: Model context as part of the entitlement boundary, not as optional metadata.

Why context-based requests improve provisioning precision

A context-based request lets the requester or administrator assemble the role, context type, and context in a structured way. That reduces manual branching in the request flow and helps ensure the resulting access aligns with the correct organizational unit. From an IAM perspective, the value is not automation for its own sake. The value is that the request object carries enough business meaning for downstream approval, provisioning, and audit to remain accurate when access looks similar but is not equivalent.

Practical implication: Build request forms and approval logic around the business context that actually changes access.

Where context can break governance at scale

Context works only when the organization has clean role engineering and stable reference data. If one business unit uses slightly different context values, or if the same access is modeled multiple ways, the result is role duplication and review fatigue. In large SAP estates, that creates a governance illusion: requests still move, but reviewers lose confidence in whether the entitlement really matches the user’s duty. The problem is not SAP complexity alone. It is the failure to maintain a canonical mapping between business structure and access structure.

Practical implication: Maintain canonical context definitions and review them with every role redesign.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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

NHI Mgmt Group analysis

Context-based access is a governance control, not just a request convenience. When SAP roles are differentiated by company code, plant, or sales organization, the real task is preserving least privilege across similar but non-identical business duties. If context is treated as a formality, the access model drifts toward broad reuse and hidden exceptions. Practitioners should treat context as part of the control boundary.

Role sprawl is the predictable failure mode when context is not normalized. The more ways an organization defines the same job family, the more likely it is to create overlapping roles that differ only by naming convention. That makes approvals harder, reviews slower, and exception handling more fragile. The practical conclusion is that governance quality depends on context standardization before request automation.

Context-based requests expose the gap between business semantics and IAM mechanics. Identity tools can move access faster than humans can review it, but they cannot correct a bad access model. When business attributes are ambiguous, the system simply automates ambiguity at scale. The practitioner takeaway is to fix entitlement design first and workflow design second.

Granular SAP access becomes durable only when context is auditable end to end. That means the requested context, the approved context, and the provisioned context all need to match in records that auditors can trace. If any one of those layers is missing, the organization cannot demonstrate that similar users received appropriately different access. Teams should therefore align SAP governance with explicit audit evidence, not just successful provisioning.

Context-based request design should be treated as part of access architecture. The article shows that many paths can lead to the same role outcome, but governance teams need one clearly governed path rather than many equivalent shortcuts. Consistency is what makes approvals meaningful and recertification defensible. Practitioners should standardize request patterns before they scale SAP role creation further.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• The same governance logic that separates agent privilege from human privilege also applies here: define the boundary first, then automate the request path using the NHI Lifecycle Management Guide.

What this signals

Context-aware provisioning is becoming a broader identity governance pattern, not just an SAP-specific workaround. As enterprises expand policy-driven access, they need business attributes that can be audited as cleanly as they are requested. The operational lesson is to treat entitlement context as lifecycle data, then carry it through approval, provisioning, and review.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey, the same over-scoping problem that affects agents also affects enterprise role design. Teams that cannot normalize context will keep automating inconsistency.

The governance signal for practitioners is clear: access models that depend on human memory or tribal knowledge do not scale. If the context is not explicit in the identity record, it will not survive audits, recertification, or cross-team handoffs.

For practitioners

• Normalize context values before expanding role catalogs Create a single approved list for company codes, plants, and sales organizations, then map every SAP role to that list so requests do not drift into parallel definitions.
• Bind context to approval logic Require approvers to confirm the requested context, not just the role name, so the workflow reflects the actual business boundary being granted.
• Reconcile role design with access reviews Compare provisioned SAP roles against the approved context type and context at each recertification cycle to catch duplicate or mis-scoped entitlements.

Key takeaways

• Context is the control that keeps similar SAP roles from becoming overbroad entitlements across business units.
• Role sprawl and approval fatigue emerge when context values are inconsistent or duplicated.
• Strong SAP governance requires the requested, approved, and provisioned context to match end to end.

Key terms

• Context-based Request: 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.
• SAP Role Context: SAP role context is the attribute that distinguishes one role instance from another when the underlying permissions are similar. In practice, it anchors access to a business unit or operational structure so the same job can receive appropriately different entitlements across the enterprise.
• Role Sprawl: Role sprawl is the gradual growth of overlapping or duplicated roles that are hard to review and even harder to retire. In SAP environments, it usually appears when context values are inconsistent, naming is uncontrolled, or teams build new roles instead of refining the governing model.

Deepen your knowledge

Context-based SAP role governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are standardising request and approval flows for enterprise roles, the course is a practical place to start.

This post draws on content published by One Identity: Understanding Context-based requests for SAP in Identity Manager. Read the original.