Topic starter
16/01/2026 3:39 pm
TL;DR: Context-based requests in SAP Identity Manager use company codes, plants, or sales organizations to differentiate otherwise similar roles and keep access aligned to the right unit, according to One Identity. The underlying lesson is that granular entitlements only stay safe when context is modeled cleanly and provisioned consistently.
Editorial analysis by NHI Mgmt Group, based on content published by One Identity.
Key questions
Q: What breaks when SAP role requests do not carry the right context?
A: When context is missing or inconsistent, similar SAP roles can grant access outside the intended business unit.
Q: Why does context-based access matter for SAP identity governance?
A: Because context is what separates otherwise similar entitlements by company code, plant, or sales organisation.
Q: How can IAM teams tell whether SAP role provisioning is staying in scope?
A: Check whether the assigned role matches the requested organisational context after provisioning, not just whether the workflow completed.
Practitioner guidance
- Map SAP roles to explicit organisational context values Document company codes, plants, and sales organisations as mandatory scope attributes for each role family so identical job titles do not collapse into shared access.
- Standardise every request path to the same required references Verify that Role-first, Context Type-first, and Context-first request flows all capture the same minimum data before any provisioning step runs.
- Test provisioning against the intended business unit Sample created roles and confirm that the final assignment matches the target organisational boundary, not just the base SAP role template.
Bottom line: Context is what prevents similar SAP roles from collapsing into a single, overbroad access pattern.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
08/10/2026 5:19 pm
Context is a governance control, not a convenience field. The article makes clear that SAP role requests only stay precise when company codes, plants, or sales organisations are treated as first-class access boundaries. That is an identity governance problem, not just an SAP configuration detail, because the request model determines whether similar users remain separated by unit. Practitioners should treat context integrity as part of entitlement design.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- 49% of IT professionals would prioritise improving privileged access management if the decision were theirs alone, according to Netwrix's 2023 Hybrid Security Trends Report.
A question worth separating out:
Q: What should organisations validate before using derived SAP roles at scale?
A: They should validate that every derived role still carries a clear, enforceable context and that all request paths resolve to the same reference data. If those checks are loose, reuse can expand access beyond the unit that the role was designed for.
👉 Read our full editorial: Context-based SAP role requests show where identity governance breaks