SAP RISE

What SAP RISE Means for Identity and Access

SAP RISE moves SAP access governance into a cloud operating model, so the central concern is no longer only who can log on, but how roles, approvals, provisioning, and monitoring are preserved across a managed service boundary. That shift changes where control evidence lives and which team must prove that access remains appropriate after migration and during steady-state operations.

For identity teams, the term is best understood as an operating change, not just a hosting change. The same principles still apply, least privilege, segregation of duties, traceability, and timely revocation, but they now need to work across SAP-managed service components, customer-owned controls, and integrated identity services.

Access Governance Across Migration

Migration is where SAP RISE programmes most often expose weak role design, stale entitlements, or undocumented exceptions. Existing authorisation objects, firefighter access, technical users, and interfaces may be re-created rather than re-validated, which makes the migration moment a governance checkpoint rather than a simple lift-and-shift event. A useful reference point is the SAP Identity and Access Security Guide, because it frames the access-model decisions that typically have to be re-established during S/4HANA migration.

Integration also matters because SAP RISE rarely stands alone. Identity provisioning, federation, privileged access, and security logging often cross from enterprise IAM into SAP controls and back again. The practical question is whether access decisions remain consistent when the control plane is split between internal systems and the SAP cloud service boundary.

Operating Model, Monitoring, and Control Assurance

In steady state, SAP RISE requires continuous assurance, not one-time setup. Access reviews, logging, exception handling, and emergency access controls must remain testable after the migration project ends. That is why cloud operating models need clear ownership for role changes, interface accounts, and privileged actions, especially where business users, basis administrators, and application owners all touch the same SAP landscape.

The access model should also be checked against the broader service-provider boundary. One relevant control concern is whether identities and permissions are still governed with enough visibility to support auditability, change control, and incident response across the managed service. The NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here because it maps the operational expectations around identification, authentication, logging, and access enforcement that a cloud-hosted SAP environment still has to satisfy.

Why SAP RISE Changes the Security Boundary

SAP RISE changes the boundary of responsibility, not the need for control. The organisation still owns its access decisions, but the technical enforcement point may sit in a managed cloud stack, with some administrative actions mediated by SAP processes. That makes control assurance more dependent on evidence, integration design, and regular verification than on local infrastructure ownership alone.

It also changes the attack surface. Compromised service accounts, excessive roles, weak emergency access handling, or poorly governed integrations can create broad business impact because SAP environments concentrate critical enterprise processes. The MITRE ATT&CK Enterprise Matrix is useful for thinking about the adversary side of that exposure, especially credential access, privilege escalation, and lateral movement once an attacker reaches an SAP-adjacent identity path.

Governance Questions Practitioners Should Ask

Practitioners should treat SAP RISE as an access-governance programme with an infrastructure component, not the other way around. The main governance question is whether the organisation can still prove who has access, why they have it, and how quickly that access can be removed or constrained when roles, integrations, or responsibilities change.

One practical test is whether the SAP access model still supports recurring review of privileged and high-impact accounts after go-live. If roles, emergency access, and integration accounts are not clearly owned, the cloud operating model can hide entitlement drift until audit or incident response exposes it. A broader guide to SAP access governance can help teams normalise those controls into the new operating model, not just the initial migration plan.

Related resources from NHI Mgmt Group

• How should organisations govern access to SAP workloads in RISE with SAP S/4HANA Cloud without weakening identity controls during migration?
• How does the rise of AI identities impact traditional IAM systems?
• How should teams govern context-based SAP role requests?
• What is the difference between role-based access and context-based access in SAP?