The scan that started it all
SAP_ALL is the most dangerous profile in any SAP system. It grants unrestricted access to every transaction, every table, every function module. A single user holding SAP_ALL can create vendor accounts, process payments, modify financial records, and export your entire customer database — with zero checks or approvals.
When we connected Syntasec to a live S/4HANA 2023 system and ran our first critical authorization check, the result was immediate: 67 active users held the SAP_ALL profile.
Of those 67, twelve were dialog users — real people logging in through SAP GUI or Fiori. The remaining 55 were system and service accounts, which might sound less concerning until you realize that compromised service accounts are the primary attack vector in SAP breaches.
How the AI-powered audit works
Traditional SAP security reviews involve extracting user data via SE16, running reports in SUIM, and manually cross-referencing findings in spreadsheets. A thorough SAP_ALL review alone typically takes 2-3 days for a consultant.
With Syntasec's AI Connector, the entire process is a conversation. We connected Claude AI to the SAP system via the Model Context Protocol (MCP) — 85 pre-built security tools that let AI query your SAP system directly, in real-time, using plain English.
What took days now takes minutes. And because the AI operates in read-only mode, there's zero risk to your production system.
What we found beyond SAP_ALL
SAP_ALL was just the starting point. The same scan uncovered a cascade of related issues that are typical of SAP systems that have been running for years without a dedicated security review:
Default accounts with unchanged passwords. The standard SAP accounts — SAP*, DDIC, and TMSADM — were all active with default or easily guessable passwords. These accounts exist on every SAP system and are the first thing an attacker will try.
RFC connections storing credentials. Multiple RFC destinations had stored user credentials with excessive authorizations. Each of these is a potential lateral movement path — if an attacker compromises one system, they can hop to connected systems via these stored credentials.
Segregation of Duties violations. Users who could both create and approve purchase orders. Users who could maintain vendor master data and process payments. These are textbook SoD conflicts that would flag in any SOX audit.
Why does this happen?
After 15+ years in SAP pre-sales, I can tell you: this isn't negligence. It's the natural entropy of SAP systems over time. SAP_ALL gets assigned during go-live because "we'll clean it up later." Emergency access during month-end close becomes permanent. Consultants get SAP_ALL for a project and nobody removes it when they leave.
The problem isn't that people don't care about security — it's that manual SAP security reviews are expensive, time-consuming, and typically happen only once a year (if that). In the 364 days between reviews, access creeps back in.
The remediation path
Finding the problems is the first step. Syntasec's AI doesn't just flag issues — it generates prioritized remediation plans with specific steps:
Immediate (Week 1): Lock the 3 dormant dialog users with SAP_ALL. Change default passwords on SAP*, DDIC, TMSADM. These are zero-effort, high-impact actions.
Short-term (Weeks 2-4): Replace SAP_ALL on the remaining 9 active dialog users with role-based access. Use the AI Connector to analyze what transactions each user actually executes, then build minimum-privilege roles.
Ongoing: Configure automated scanning to detect any new SAP_ALL assignments and alert the security team immediately. Review system and service accounts quarterly.
What this means for your SAP system
If you're running SAP ECC or S/4HANA, the odds are high that your system has similar issues. Not because your team isn't doing their job — but because SAP security is complex, manual reviews are expensive, and access drift is inevitable.
The question isn't whether you have SAP_ALL holders. It's whether you know who they are right now.
Find out what's hiding in your SAP system
Get a free security assessment of your SAP landscape. We'll run the same AI-powered scan and show you exactly what needs attention.
Request Free AssessmentFrequently asked questions
What is SAP_ALL and why is it dangerous?
SAP_ALL is the most powerful profile in an SAP system. It grants unrestricted access to every transaction, table, and function module — a single user holding it can create vendors, process payments, modify financial records, and export data with no checks. Because it bypasses the entire authorization model, every SAP_ALL assignment is a standing risk and a standard audit finding.
How many users typically hold SAP_ALL?
Far more than teams expect. In one production S/4HANA 2023 system, a read-only scan found 67 active users with SAP_ALL — 12 real dialog users and 55 system or service accounts. SAP_ALL accumulates over years through go-lives, emergency access, and departed consultants whose access was never removed.
Should system or service accounts have SAP_ALL?
Almost never. Compromised service accounts are a primary attack vector in SAP breaches because they often carry excessive standing privileges like SAP_ALL and are rarely reviewed. Each should be scoped to only the authorizations its integration actually requires.
How do you find every user with SAP_ALL?
The access is granted through profiles and roles, so you check profile assignments including SAP_NEW and expand composite and single roles down to the underlying authorizations. SyntaAI does this over read-only RFC in seconds and flags dialog users, last-login dates, and dormant high-privilege accounts — work that takes a consultant 2 to 3 days manually.
Is it safe to scan a production system for this?
Yes, when the scan is read-only. SyntaAI queries SAP in read-only mode — it can read authorization data but cannot create, change, or delete anything — so there is no risk to the production system. Any remediation is proposed for a human to approve and applied by your SAP team.
How do you remove SAP_ALL safely?
Identify what each user actually does, replace SAP_ALL with a right-sized role, and stage the change through your transport process from DEV to QA to PROD with evidence at each step. Start with dormant dialog users holding SAP_ALL — the highest risk, lowest disruption removals.
Bhargavi Maddipati is Co-Founder & CEO of SyntaAI, with 15+ years of SAP Security and GRC expertise. Jani K, Co-Founder & CTO, brings 15+ years of SAP pre-sales experience. Together they built Syntasec to make enterprise-grade SAP security accessible to mid-market companies.