Why SAP security needs its own RASP moment (Real-Time-Application-Self-Protection)

How SAP User Access Reviews become more effective through risk-based prioritization, automation, and least privilege.

Is the Access We Granted Still Appropriate Today?

Consider a common SAP scenario.

An employee receives additional access for a project. The project ends, but the roles remain. Another employee changes departments and receives new roles without removing all previous access. An administrator receives powerful privileges to resolve a production issue, but the elevated access remains after the incident is closed.

These situations illustrate a persistent SAP security challenge: access can accumulate faster than it disappears.

This is why User Access Review (UAR) is an important part of SAP security and access governance.

There is, however, a difference between completing an access review and performing an effective one.

Exporting thousands of users and roles into spreadsheets, asking managers to approve them, and retaining the results may complete a governance process. However, it does not necessarily answer the question that matters:

For complex SAP environments, answering this requires more than periodic certification. It requires meaningful security context, risk-based prioritization, and appropriate automation.

Key Takeaways

What Is an SAP User Access Review?

An SAP User Access Review is a structured process for validating whether users should retain their existing access to SAP systems, applications, roles, and business functions.

At its simplest, UAR asks:

Does this person still need this access?

A meaningful review should go further:

• Is the account still required?
• Does access match the user’s current responsibilities?
• Are assigned roles and authorizations appropriate?
• Does the user possess critical or privileged access?
• Are there Segregation of Duties (SoD) conflicts?
• Is some assigned access no longer being used?
• Are technical and service accounts still necessary and properly owned?

Reviewing an account, reviewing assigned roles, analyzing effective authorizations, and evaluating SoD risks are related activities, but they are not interchangeable.

An effective UAR considers these perspectives together.

Why SAP Access Reviews Are Challenging

SAP authorization models are designed to support complex business processes. As a result, determining what a user can actually do may require looking beyond the role assignment itself.

Consider these two statements:

User A has role Z_FINANCE_MANAGER.

Compared with:

User A can perform sensitive financial activities for specific organizational areas and possesses access that conflicts with another business capability.

The first tells a reviewer what role is assigned; the second explains what that access means.

This is a fundamental challenge in SAP UAR: role names alone rarely communicate effective access or business risk.

The challenge grows across environments containing S/4HANA or ECC, Fiori applications, technical identities, interfaces, privileged administrators, and connected applications.

A useful access review therefore needs to translate technical SAP authorization information into context that business owners and security teams can act upon.

A Practical SAP User Access Review Process

An effective review does not need to be unnecessarily complicated; it can be structured around five steps.

1. Define the Scope
Determine which systems, users, accounts, and permissions need review.

Depending on the organization’s risk profile, the scope might include all users or place additional emphasis on privileged users, technical accounts, critical roles, sensitive business processes, and users with SoD conflicts.

2. Collect Relevant Context
Traditional reviews frequently present:

User → Role

A more meaningful review provides:

User → Access → Risk → Usage → Business Need

Relevant information might include assigned roles, critical authorizations, organizational restrictions, account type, privileged access, SoD findings, and usage information.

This context allows reviewers to understand not only what is assigned, but also why it matters.

3. Prioritize High-Risk Access
Not every authorization represents the same level of risk.

Particular attention is usually warranted for:

• Critical authorizations
• Privileged access
• SoD conflicts
• Broad organizational permissions
• Dormant or obsolete access
• Sensitive business functions
• Recent significant access changes

The objective is not to produce another large report. It is to help reviewers understand where attention is most needed.

4. Review and Decide
The appropriate manager, business owner, role owner, or security specialist should determine whether access should be approved, modified, revoked, or investigated.

Business owners understand whether access is necessary, while SAP security specialists understand its technical implications; strong access governance requires both perspectives.

5. Remediate and Verify
A review should not end when somebody selects Revoke.

Organizations should verify that unnecessary access was actually removed and retain appropriate evidence of both the decision and remediation.

Why Manual User Access Reviews Become Difficult

Many SAP access reviews still rely heavily on spreadsheets, email, tickets, and manually collected evidence.

This can work at a smaller scale, but the limitations become apparent as environments grow.

Imagine asking a manager to review hundreds of technical SAP role assignments. Which ones deserve attention? Which provide sensitive access? Which contain critical authorizations? Which are no longer used?

When every row looks equally important, genuinely risky access can disappear within the volume.

Manual processes can also create challenges around ownership, reminders, version control, evidence collection, remediation tracking, and identifying what changed since the previous review.

The purpose of automation should therefore not simply be to replace a spreadsheet with an electronic workflow; it should improve the quality of the review itself.

Moving Toward Risk-Based User Access Review

Consider two users.

One has standard business roles aligned with current responsibilities.

The other has privileged access, a critical authorization, and an SoD conflict.

Should the reviewer spend equal time on both?

A risk-based approach prioritizes users and permissions based on factors such as:

• Critical or privileged access
• SoD conflicts
• Dormant or unused access
• Broad permissions
• Sensitive systems or business processes
• Recent access changes

Instead of presenting a manager with 1,500 apparently equal assignments, the process should help identify which assignments deserve closer attention.

This is where automation provides significant value.

The objective is not to automate accountability. Instead, it is to automate the collection and analysis of information needed for better decisions.

What Should UAR Automation Actually Automate?

There is an important boundary between automating analysis and automating business decisions.

Technology can determine that a user possesses a critical authorization. It cannot know whether that authorization is genuinely required for the person’s job.

Appropriate areas for automation include:

• User and role inventory
• Identification of inactive accounts
• Critical access detection
• Privileged user identification
• SoD analysis
• Usage analysis
• Risk-based prioritization
• Reviewer workflow and reminders
• Evidence collection
• Remediation tracking

The goal should not be:

Technology decides whether every user keeps every role.

A better objective is:

Human accountability remains important, particularly where business justification and risk acceptance are involved.

From Periodic Review to Continuous Visibility

Traditional UAR typically follows a calendar:

Quarterly, semiannual, or annual reviews provide a point-in-time view of access.

Access risk, however, can change between those reviews.

A critical authorization could be assigned shortly after certification. A new SoD conflict might appear. A dormant account could become active. An employee’s responsibilities could change.

This creates an opportunity to complement periodic certification with more continuous visibility:

The distinction is important: continuous monitoring does not necessarily replace periodic UAR, and periodic reviews may remain necessary for governance, policy, or audit purposes. Continuous visibility helps address the time between reviews.

“Can Do” Versus “Did Do”

There is another useful dimension to consider when evaluating SAP access.

Authorization analysis answers:

What can this user do?

Activity information can help answer:

What did this user actually do?

Suppose a user has permission to execute a particularly sensitive business function.

That permission deserves attention based on its potential risk. However, understanding whether and how that capability has actually been exercised provides important additional context.

Neither perspective replaces the other; together, they can help security teams distinguish theoretical access risk from actual activity, enabling better prioritization and investigation.

Privileged Access: Question Permanent Privilege

Privileged access deserves particular attention during UAR.

SAP administrators and support teams may occasionally require powerful permissions for troubleshooting, maintenance, or exceptional activities.

The important question is not only:

Is this privileged access approved?

It is also:

Does it need to be permanently assigned?

Where operationally feasible, organizations can adopt a model such as:

This supports the principle of least privilege by reducing standing access while still enabling administrators to perform necessary tasks.

For access reviews, this changes the discussion from repeatedly certifying powerful permanent access to evaluating whether permanent privilege is necessary at all.

Access Review Should Be a Security Control, Not Just an Audit Exercise

Perhaps the biggest opportunity is to change how organizations think about UAR.

If User Access Review is performed primarily to demonstrate that managers approved access, it risks becoming a compliance exercise.

Its real security objective is broader:

Achieving this requires understanding effective permissions rather than simply role names. It requires distinguishing routine access from critical access, combining business ownership with SAP security expertise, and using automation to provide better context, prioritization, and evidence.

Periodic access reviews remain important, but each one captures only a single moment. Bringing access governance together with continuous security visibility can help organizations understand not only whether access is appropriate, but also how access and associated risks change over time.

This is where SecurityBridge’s SAP-native security approach can provide additional context. By providing visibility into SAP users, roles, authorizations, critical privileges, and security-relevant activity, SecurityBridge can complement existing IAM, IGA, and SAP GRC processes. The objective is not to replace established access governance processes, but to enrich them with SAP-specific security intelligence that can help organizations identify and prioritize access-related risk.

The difference matters:

Access governance asks: “Should this user have this access?”

Continuous security adds: “What happens after that access is granted?”

Bringing these perspectives together can help organizations move from periodic access certification toward more effective, risk-informed SAP access governance.

For CISOs and SAP Security leaders, this leaves a useful question:

To see what risk-based access visibility looks like in an SAP landscape, request a SecurityBridge demo or estimate the impact with the business case calculator for SAP security.