The monitoring gap inside SAP
Most enterprises have invested heavily in security monitoring — SIEM platforms, EDR tools, network detection systems generating millions of alerts per week. SAP sits in the middle of all this infrastructure, processing financial transactions, payroll, vendor payments, and sensitive master data — and is almost entirely invisible to those monitoring tools.
SAP generates its own rich security event stream. SM20 (the Security Audit Log) records every login attempt, every sensitive transaction execution, every authorization failure, every debug session. USH02 records every user master change — who created, modified, or unlocked which user, and when. CDHDR captures customizing and configuration changes. STAD records detailed transaction-level workload data for every user session.
The data exists. The problem is that almost no one analyzes it in real time. SM20 is reviewed manually when an incident is already known. USH02 is pulled for specific audit questions. The result is a monitoring gap where threats can persist inside SAP for weeks or months before anyone notices.
SAP's primary security event sources
| Source | What it records | Key threat patterns | Scan frequency |
|---|---|---|---|
| SM20 / Security Audit Log | Login events, failed logins, sensitive transactions, authorization failures, debug sessions, RFC calls | Brute force, privilege escalation, debug in production, terminated user login | Every 5 minutes |
| USH02 / User Change Log | All user master record changes: creation, modification, lock/unlock, profile assignment, role changes | Unauthorized user creation, account reactivation, SAP_ALL assignment, self-modification | Every 5 minutes |
| CDHDR / Change Documents | Customizing table changes, configuration modifications, business object changes | Security parameter tampering, audit log disabling, unauthorized config changes | Every 30 minutes |
| STAD / Workload Statistics | Transaction-level user activity: which users ran which transactions, when, from which terminal | Behavioral drift, unusual transaction patterns, off-hours activity, mass data export | Daily collection |
| USR02 / User Master | Current user status: lock state, last login, validity dates, user type | Terminated users active, dormant account activation, expired accounts still valid | Every 60 minutes |
| AGR_USERS / Role Assignments | Role-to-user assignments with validity dates | Privilege escalation via role assignment, mass role grants, unauthorized role additions | Every 5 minutes |
The 50+ detection patterns — by category
SyntaAI's threat detection engine runs 50+ detection patterns across these data sources continuously. Patterns are organized by threat category, each with a defined severity, confidence score, and recommended action. Here are the key patterns across six categories:
Authentication attacks
Privilege escalation
Data access threats
Configuration attacks
Change management threats
Correlation patterns (multi-event)
Single-event patterns catch obvious threats. Correlation patterns catch sophisticated ones by linking events that individually look benign but together indicate a threat:
- User created + immediately granted SAP_ALL — rogue admin account creation sequence
- Account unlocked + login within 5 minutes — pre-planned unauthorized access
- Failed logins then success + sensitive transaction — brute force leading to privilege abuse
- Role assignment + same-day mass data export — privilege escalation for data theft
How the threat detection engine works technically
SyntaAI's threat detection is not a rules-only engine. It operates in three layers:
Layer 1 — Real-time pattern matching: The threat scan runs every 5 minutes. It reads new SM20 log entries, USH02 change records, and role assignment changes. Each event is evaluated against the pattern library. Matches above the confidence threshold create threat records immediately.
Layer 2 — Multi-source correlation: Every 5 minutes, the correlation sweep processes recent alerts and event data together, looking for sequences and combinations that match multi-event patterns. This is where the sophisticated threats are caught.
Layer 3 — AI-powered investigation: Critical and High threats trigger the AI security agent, which runs every 15 minutes. The agent takes an unreviewed threat, gathers context (user profile, role assignments, recent activity, similar past events), and generates a complete investigation summary with recommended action. This is what replaces the human analyst having to do that research manually for every alert.
User: VENDOR_CLERK | System: PRD | Client: 100 Action: Started debug session in production
// AI Agent investigation (auto-triggered): User VENDOR_CLERK is a vendor payment processor (Z_FI_VENDOR_PAY role). No debug authorization should exist in their profile. Last role change: 3 days ago — Z_DEBUGGER_TMP added by ADMIN_USER. This role was not in the original user request. No change ticket found. VERDICT: Unauthorized debug authorization — likely privilege escalation. IMMEDIATE ACTION: Remove Z_DEBUGGER_TMP from VENDOR_CLERK. Investigate ADMIN_USER's role assignment activity this week. Check what VENDOR_CLERK did during debug session via SM20.
What about SIEM integration?
Many security teams ask whether SAP events can simply be forwarded to their existing SIEM (Splunk, Microsoft Sentinel, IBM QRadar). The answer is yes — but with an important caveat. Raw SAP event data is not SIEM-friendly. SM20 log entries use SAP-specific message IDs (AU1, AU2, AUF, AUG) and SAP data formats that require normalization before a SIEM can process them meaningfully. And SIEM correlation rules for SAP events require SAP domain knowledge to write effectively — which most SIEM teams don't have.
SyntaAI operates as a purpose-built SAP threat detection layer that understands SAP's data natively. For organizations with SIEM requirements, the processed, normalized threat output from SyntaAI can feed the SIEM as enriched alerts rather than raw SAP events — giving the SIEM high-quality signals instead of noise.
Start Monitoring SAP Threats in Real Time
50+ detection patterns, AI-powered investigation, continuous scanning every 5 minutes. No SIEM required. No agent installation. Connects via RFC.
Apply for 90-Day PilotFrequently asked questions
Does SAP generate its own security event data?
Yes — a rich stream most organizations never analyze. The Security Audit Log (SM20) records every login attempt, sensitive transaction, authorization failure, and debug session. USH02 records every user master change. Additional signal lives in tables like CDHDR, AGR_USERS, STAD, and USR02. The data exists; the gap is that almost no one reviews it in real time.
What is SM20 in SAP?
SM20 is the transaction for viewing the SAP Security Audit Log — the record of security-relevant events such as logins, transaction starts, and authorization failures. It is typically reviewed manually only after an incident is already suspected, which is why threats can persist undetected for weeks or months.
Can I forward SAP events to my existing SIEM such as Splunk, Sentinel, or QRadar?
Yes, but with a caveat. Raw SAP events use SAP-specific message IDs (AU1, AU2, AUF, AUG) and formats that need normalization before a SIEM can use them, and effective correlation rules require SAP domain knowledge most SIEM teams lack. A purpose-built SAP layer can feed the SIEM enriched, normalized alerts instead of raw noise.
How does real-time SAP threat detection actually work?
SyntaAI runs over 50 detection patterns across SAP's event and table data continuously, scanning roughly every 5 minutes. It operates in layers: real-time pattern matching on new events, multi-source correlation that links events which look benign individually but reveal a threat together (for example, a user created and then immediately granted SAP_ALL), and AI-assisted investigation that assembles the full picture.
Do I need the SAP Security Audit Log (SM20) switched on?
It helps, but it is not strictly required. SyntaAI can detect many threat patterns from SAP table data alone — USR02, USH02, AGR_USERS, CDHDR, E070 — so meaningful detection is possible even where SM20 is not fully enabled.
What kinds of threats can be detected in SAP?
Brute-force and password-spray login patterns, rogue admin account creation, privilege escalation, direct ABAP changes in production, mass role changes, transports outside approved windows, and multi-step sequences such as failed logins followed by a successful login and a sensitive transaction. Each pattern carries a severity, a confidence score, and a recommended action.
SyntaAI's threat detection engine runs 50+ patterns across SM20, USH02, CDHDR, AGR_USERS, STAD, and USR02. Built by Bhargavi Maddipati — Co-Founder & CEO (18 years SAP Security/GRC) and Jani K — Co-Founder & CTO (15+ years SAP). Available for pilot at syntaai.com.