Cleaning Up SAP Authorisations: A Pragmatic Guide

In almost every SAP system that has been in operation for more than five years, you find the same symptoms: roles that nobody can assign any more, users with SAP_ALL “because it had to be quick at the time”, SoD reports with thousands of conflicts that have been ignored for years. Cleaning up feels like a mammoth project – but it doesn’t have to be. This guide shows a pragmatic approach that doesn’t jeopardise ongoing operations.

Why now?

Missing authorisation checks were the most common SAP vulnerability category in 2025 (31% of all patches). Oversized authorisations amplify every technical vulnerability: if an attacker gets into the system through a security gap and finds SAP_ALL rights there, the compromise is complete. Add to this the compliance pressure: auditors and internal audit departments are scrutinising more closely than ever.

Step 1: Create Transparency – What Do We Actually Have?

Before you start rebuilding, you need a stocktake:

• How many roles exist? How many of them are actively assigned?
• Which users have critical profiles (SAP_ALL, S_A.DEVELOP, etc.)?
• What does the SoD matrix look like – and which conflicts are truly risk-relevant?

AI-powered analysis tools can deliver this assessment in hours rather than weeks. The results form the decision basis for everything that follows.

Step 2: Quick Wins – Close the Most Dangerous Gaps First

Not everything needs to be perfect immediately. Start with measures that reduce risk the fastest:

• Remove SAP_ALL and SAP_NEW from all dialog users
• Lock or secure standard users (SAP*, DDIC, EARLYWATCH) in all clients
• Remove debugging authorisations in the production system
• Introduce an emergency user concept (controlled access instead of permanent over-authorisation)

These measures can often be implemented within a few days and drastically reduce the risk profile.

Step 3: Usage-Based Redesign – Roles That Fit Daily Work

The classic mistake: designing new roles on the drawing board without knowing what users actually need. Better: evaluate usage data (transaction traces, SU10 evaluations) and derive roles that match the real daily working routine.

The result is a role concept based on the least-privilege principle: everyone gets exactly what they need – no more, no less.

Step 4: Evaluate SoD Conflicts, Don’t Just Count Them

2,000 SoD conflicts sound dramatic. But not every conflict is equally risky. What matters is the combination of:

• Criticality of the affected functions
• Actual usage (is the combination really being executed?)
• Existing compensating controls

A risk-based prioritisation often reduces the “real” conflicts to a fraction – making the project manageable.

Step 5: Build Governance – So It Doesn’t Happen Again

The best role concept erodes if there’s no process to protect it:

• Request and approval workflow for new authorisations
• Regular recertification (at least annually)
• Automated reporting for critical changes
• Clear responsibilities: Who is the role owner?

This doesn’t have to be elaborate – but it must exist and be practised.

Conclusion

Cleaning up authorisations is not a big-bang project. With the right approach – transparency, quick wins, usage-based redesign and governance – even a historically grown system can be brought to an audit-ready level within a few months. If you’d like to know how your system currently stands, we’re happy to start with a non-binding initial analysis.

Request a free initial analysis →

Related Articles

Need support with this topic?

We help you with implementation – from analysis to go-live.

Get in touch

← All articles