SAP Identity and Access Security: Roles and Firefighter IDs

SAP systems hold the general ledger, payroll, supplier master data and payment runs, so one over-privileged account in SAP can move money, hide fraud or halt operations. SAP access is also hard to reason about: thousands of transaction codes, authorisation objects with field-level values, roles that inherit organisational levels, and a long tail of RFC, batch and integration users nobody logs on as. This guide explains the SAP authorisation model, how to remove dangerous defaults, how to run firefighter access properly, how to secure RFC and service accounts, and what changes with S/4HANA, Fiori, SAP HANA and SAP's cloud identity services. It is for SAP security and Basis teams, IAM and IGA owners, and auditors. For conflicting duties across all applications see the Segregation of Duties Guide.

Key takeaways

Authorisation objects, not transaction codes, decide what a user can do. A tcode is only the entry point; objects such as S_TABU_DIS, S_DEVELOP and S_RFC carry the real power, so reviews must look at object values.
SAP_ALL and SAP_NEW have no place on standing production users. SAP lists them as profiles with critical authorisations that must be protected; grant that level only through logged, time-bound firefighter sessions.
Firefighter access is a process, not an account. Each session needs an owner, a controller, a reason code, an activity log and a completed review.
RFC, batch and integration users are the quiet majority. They are non-human identities with stored passwords; give them System or Communication user types, narrow S_RFC values and named owners.
Logging and patching are part of access control. The Security Audit Log is often not fully enabled, and SAP's monthly security notes include flaws that bypass authorisation entirely.

How SAP authorisation works

In SAP NetWeaver AS ABAP, the platform under ECC and S/4HANA, programs run an authority check against an authorisation object (SAP spells it "authorization object"). Each object has up to ten fields, usually an activity field (ACTVT: 01 create, 02 change, 03 display) plus data fields such as company code or table group. A user passes only if one of their authorisations matches. Authorisations are bundled into profiles, generated from roles maintained in transaction PFCG.

Transaction codes: starting a tcode such as FK01 (create vendor) is checked through S_TCODE, then the application checks further objects. The same objects can often be reached through other tcodes, reports or function modules, which is why tcode-only analysis misleads.
SU24 proposals: SU24 stores the objects and default values each tcode or service needs, and PFCG uses them when building roles. Clean SU24 data is the foundation of maintainable roles.
Single, composite and derived roles: derived roles inherit a master role's menu and authorisations and differ only in organisational levels, the usual way to give one job function to several legal entities.
Troubleshoot without over-granting: SU53 shows the last failed check and STAUTHTRACE traces a session, so missing access is granted from evidence rather than wildcards. SUIM and report RSUSR002 answer questions such as "who can change vendor bank details in company code 1000".

Every user master record (SU01) carries a user type, the first identity control for non-human accounts.

User type	SAP description	Interactive logon	Use it for
Dialog (A)	Individual, interactive system access	Yes	Named people only
System (B)	Background processing and communication within a system	No	Batch steps, internal RFC, connector users
Communication (C)	Dialog-free communication for external RFC calls	No	External systems calling SAP
Service (S)	Dialog user available to a larger, anonymous group of users	Yes	Rare anonymous scenarios with minimal authorisations; also the type used for ID-based firefighter IDs
Reference (L)	No logon is possible	No	Extra authorisations assigned to other users; review what they carry

Critical authorisations and standard users

SAP documentation lists SAP_ALL and SAP_NEW as profiles "that contain critical authorizations that you must protect". SAP_ALL contains every authorisation; SAP_NEW grants authorisations for checks added by releases, so it quietly widens access after every upgrade. Most SAP compromise and fraud paths run through the following.

Authorisation	Why it is critical	Control
SAP_ALL, SAP_NEW	Unrestricted or upgrade-widening access	Firefighter only; alert on any assignment
S_USER_GRP, S_USER_AGR, S_USER_PRO (change)	User administrators can grant any role, including to themselves	Restrict; protect the SUPER group; SoD against business roles
S_DEVELOP, object type DEBUG, change	Debug-and-replace alters values at runtime and skips checks	Never for production dialog users
S_TABU_DIS / S_TABU_NAM (change)	Direct table maintenance bypasses application logic	Display by default; named tables only
S_RFC wildcards, S_RFCACL	Remote execution of any function module; trusted RFC logon as other users	Allowlist function groups; named systems and users
S_BTCH_ADM, S_BTCH_NAM	Jobs that run under another user's authority	Batch administrators only
S_TRANSPRT, SCC4 and SE06 changeability	Open production clients or imported transports change code and configuration	Closed client; changes only via the transport path

For delivered standard users, SAP's guidance is to change the default passwords of SAP*, DDIC, EARLYWATCH, SAPCPIC and TMSADM, put SAP*, DDIC and EARLYWATCH in the SUPER group and lock them, and check every client with report RSUSR003. Set profile parameter login/no_automatic_user_sapstar to 1 so the kernel never allows a built-in SAP* logon when the user record is missing, run the transport job RDDIMPDP under a dedicated System user rather than DDIC, and know every client, including client 066 where it still exists.

Role design, Fiori roles and S/4HANA role migration

SAP role design follows business tasks, separates display from change, and puts organisational restrictions in derived roles. The general method is in the Role Mining and Role Design Guide; the SAP specifics are these.

Build from SU24 and usage: start from tcode and service proposals and twelve months of transaction usage statistics, and justify every manual value. Manually inserted full wildcards on data fields are the usual source of excess access.
Fiori uses PFCG roles: with an embedded front-end server one back-end role is enough; a stand-alone front-end server needs front-end and back-end roles. Business catalogs group apps and SAP aligns them to segregation of duties. Adding a catalog pulls in its OData services and start authorisation (S_SERVICE), but users still need business authorisations for the data each app shows.
Spaces and pages replace groups: launchpad groups are deprecated from S/4HANA 2021, so move navigation while you remediate roles.
Treat migration as remediation: an S/4HANA conversion changes tcodes, adds Fiori apps and simplifies data models, so ECC roles do not carry over cleanly. Map old tcodes to replacements, rebuild catalogs, re-run SoD analysis, and drop unused access instead of migrating it.

Firefighter IDs and emergency access management

Production SAP needs a way to fix urgent problems with broad rights without leaving them on standing accounts. SAP Access Control provides Emergency Access Management (EAM), commonly called firefighter access. General principles are in the Break-Glass Account Guide; SAP implements them two ways, and only one can be configured at a time.

Aspect	ID-based firefighting	Role-based firefighting
How access is granted	Log on to a firefighter ID (a Service user with elevated roles) in a new session	Firefighter roles used under the person's own user ID
Name in the logs	The firefighter ID; EAM links the session to the person	The person's own user
Concurrency	One firefighter per firefighter ID at a time	No shared ID
Launch	Centralised (GRAC_EAM) or decentralised launchpad on the target system (/GRCPI/GRIA_EAM) when Access Control is unavailable	A transaction contained in the firefighter role
Main risk	Direct logon to the firefighter ID outside EAM	Firefighter roles left assigned

Owner and controller: the owner approves who may use an ID or role; the controller reviews the log. SAP does not allow one user to be controller and firefighter for the same firefighter ID.
Block direct logon: implement the target-system user exit that stops logons to firefighter IDs outside EAM (SAP Note 1545511).
Reason codes and requests: require a reason code at session start and a Superuser Access request approved by the owner, so every session maps to a ticket.
Reviews with evidence: controllers receive logs by email, workflow or log display, but only workflow controllers approve session review requests, so use workflow if you need audit evidence. Web-based firefighting lacks detailed logging; avoid it on high-risk systems.
Short validity: assign firefighter access for days, and treat daily firefighting as a role design failure.

RFC connections, service accounts and integration users

SAP landscapes usually have more technical users than people: interface RFC users, batch users, connector users for identity and monitoring platforms, middleware users and the users behind SAP Business Technology Platform (BTP) destinations. They fail the classic non-human identity ways: passwords stored in RFC destinations, dialog user types, SAP_ALL "to make the interface work", and no owner. The lifecycle model is in the Service Account Security Guide; the SAP controls are:

User type: System or Communication for every technical user, so the credential cannot open an SAP GUI session.
Narrow S_RFC: grant only the function groups an interface calls, based on a trace or Security Audit Log RFC events (AU5, AU6, AUK, AUL) captured for a short period.
Allowlist callable function modules: Unified Connectivity (UCON), from SAP NetWeaver 7.40 SP5, restricts which RFC function modules can be called externally, moving through logging, evaluation and active phases in the phase tool (UCONPHTL).
Destinations and trust: inventory SM59 destinations that store credentials, especially from lower environments into production; never store dialog or highly privileged users. Treat trusted RFC relationships (SMT1, S_RFCACL) as privilege paths into your system.
Gateway and encryption: maintain gateway ACLs (secinfo, reginfo) so only known programs register or start, and use Secure Network Communications (SNC) for SAP GUI and RFC traffic.
Ownership and rotation: each technical user needs an owner, a documented interface and a rotation that updates the destination at the same time.

SAP HANA, BTP and SAP Cloud Identity Services

SAP HANA privilege model

SAP HANA has its own users and privileges, separate from ABAP: system privileges (administration), object privileges (SELECT, ALTER, DROP and so on, on tables, views, procedures and schemas), analytic privileges (row-level restrictions on information models), privileges on users (ATTACH DEBUGGER), and, on premises only, package and application privileges for the deprecated XSC repository. Roles nest. Watch grants WITH ADMIN OPTION or WITH GRANT OPTION, which let the grantee pass privileges on. Deactivate the SYSTEM user once named administrators exist and enable HANA audit policies alongside the ABAP log.

Cloud identity, BTP and RISE

Identity Authentication service: SAP's authentication broker for cloud applications over SAML 2.0 and OpenID Connect, with its own second factors (TOTP, WebAuthn) or forwarding to a corporate identity provider such as Microsoft Entra ID, the usual pattern so MFA and conditional access live in one place. See the Identity Provider and SSO Security Guide.
Identity Provisioning service: moves users and groups between source, target and proxy systems, including S/4HANA and BTP, alongside the Identity Directory (SCIM 2.0) and Authorization Management policies. Its connector credentials are privileged secrets.
SAP Identity Management: SAP has announced end of maintenance for the on-premise product (2027 in SAP's announcement), and Microsoft documents migration paths into SAP ECC and, through Cloud Identity Services, S/4HANA. Plan the replacement as an IGA decision, not a connector swap.
BTP: authorisations are managed per subaccount, with roles aggregated into role collections. Use a custom Identity Authentication tenant instead of the default identity provider, keep global account administrators few, and export the Audit Log service data (90-day default retention) centrally.
RISE with SAP: security tasks follow a shared responsibility agreement; Microsoft's SAP monitoring documentation notes that Security Audit Log enablement on RISE systems falls under it. Confirm in writing who enables logging, applies notes and manages technical users.

Segregation of duties and access governance with SAP GRC

SAP GRC Access Control combines Access Risk Analysis (the SoD and critical access ruleset), Access Request Management, Business Role Management, Emergency Access Management and User Access Review; SAP Cloud Identity Access Governance is the cloud equivalent. Ruleset method and mitigating controls are in the Segregation of Duties Guide and reviews in the Access Reviews Guide. SAP specifics: analyse at authorisation object level, not tcode only; include RFC, batch and firefighter users; run risk analysis preventively at request and role change; and lock SAP accounts on the same HR leaver trigger as everything else (see the Joiner-Mover-Leaver Guide).

Logging, threat detection and vulnerability management

Configure the Security Audit Log in RSAU_CONFIG (SM19 on older releases) and read it in RSAU_READ_LOG (SM20); some installations do not enable it by default. A widely used baseline published by an SAP expert sets rsau/enable, rsau/user_selection and rsau/integrity to 1 and rsau/selection_slots to at least 10, then logs critical events for all users in all clients, everything for SAP* (filter SAP#* so the internal SAPSYS user is not caught), everything for support and firefighter users, and logon and transaction events for DDIC. Protect the audit directory from ordinary users.

Event ID	Meaning	Alert on
AU1 / AU2	Successful / failed logon	SAP*, DDIC or firefighter ID logons outside EAM; failure bursts
AU3 / AU4	Transaction started / failed	SU01, PFCG, SE16N, SM59, SCC4 by unexpected users
AU5, AU6, AUK, AUL	RFC logon and calls	New calling systems or function modules for a technical user
AUE	Audit configuration changed	Always
CUL, CU_M	Debugger field change, jump to debugger	Any occurrence in production
BU4	Dynamic ABAP coding	Generated code in production
EU5	Audit log data deleted	Always

Forward audit log, HANA audit and change document data to your SIEM or to SAP Enterprise Threat Detection and correlate with identity provider data (see the SIEM Guide).

Security Patch Day: SAP publishes security notes on the second Tuesday of every month and recommends implementing corrections "at a priority". Triage kernel, ABAP, Java and HANA components separately.
Flaws that bypass authorisation: CVE-2025-31324 in the SAP NetWeaver Visual Composer Metadata Uploader (CVSS 10, SAP Note 3594142) allowed unauthenticated file upload and is in CISA's Known Exploited Vulnerabilities catalog. CISA warned in April 2021 of activity that "could lead to full control of unsecured SAP applications". Role design does not help here; exposure reduction and patching do. See the Vulnerability Management Guide.
SAP penetration testing: scope assessments to exposed services (dispatcher 32NN, gateway 33NN, message server 36NN, where NN is the instance number), gateway ACLs, standard user passwords, RFC trust and stored credentials, missing notes and critical authorisation holders, with test windows agreed with Basis.

Implementation roadmap

Inventory: every system and client, users by type, holders of SAP_ALL, SAP_NEW and the critical objects above, RFC destinations with stored credentials, and current audit log settings.
Quick wins: lock standard users, set login/no_automatic_user_sapstar, close production clients, enable the audit log baseline and forward it. Little business risk.
Firefighter access: configure EAM, move broad access onto firefighter IDs or roles, then remove it from standing users team by team, with temporary firefighter assignment as the rollback for anything that breaks.
Technical users: fix user types, trace RFC usage, narrow S_RFC, and run UCON in logging mode before activating it, piloting one interface family first.
Roles: rebuild high-risk roles from usage and SU24, run SoD analysis and test in quality with business users, keeping the old role available for a defined rollback period.
Operate: monthly Patch Day triage, quarterly critical access reviews, firefighter reviews within an agreed number of days, annual ruleset review with finance and internal audit.

Small versus large landscapes: one production system with a small team can run firefighter access with reviewed audit log reports and ticket workflow; several production systems, regulated financial reporting or outsourced Basis support justify central EAM, ruleset-based risk analysis and request workflow.

Measuring progress and framework mapping

Standing critical access: production dialog users holding SAP_ALL, SAP_NEW or debug-change (target zero).
Firefighter review rate: sessions reviewed within the agreed window (target 100%).
Technical user hygiene: share of technical users that are System or Communication type, owned and free of S_RFC wildcards.
Open SoD conflicts: unmitigated conflicts by risk level, trended quarterly.
Patch latency: median days from Patch Day to implementation for the highest-priority notes.

Control area	NIST SP 800-53 Rev. 5	CIS Controls v8.1	ISO/IEC 27001:2022
Accounts, user types, standard users	AC-2, IA-5	5 Account Management	A.5.16, A.5.18
Role design, critical objects	AC-3, AC-6	6 Access Control Management	A.5.15, A.8.2
Segregation of duties	AC-5	6 Access Control Management	A.5.3
Firefighter logging	AC-6(9), AU-2, AU-6	8 Audit Log Management	A.8.15
Security notes	SI-2, RA-5	7 Continuous Vulnerability Management	A.8.8

Common failure patterns

SAP_ALL on interface users: granted during a project and never removed, so a password stored in another system controls production.
Firefighter IDs as everyday accounts: support teams firefight daily and reviews pile up unread.
Tcode-only reviews: reviewers approve role names while S_TABU_DIS, S_DEVELOP and S_RFC wildcards sit inside unseen.
Migrating ECC roles unchanged: old excess access is carried into S/4HANA and Fiori apps are added on top.
Assuming SAP components are clean: the SAP SQL Anywhere Monitor hard-coded credentials case shows SAP software can ship credentials that only a security note removes, so Patch Day triage belongs in the access programme.
Partial logging: the audit log covers only failed logons, or not client 000, so the session that matters is missing.

Practitioner checklist

Remove SAP_ALL, SAP_NEW and debug-change from standing production users and alert on new assignments.
Lock SAP*, DDIC and EARLYWATCH, change standard passwords, set login/no_automatic_user_sapstar to 1 and run RSUSR003 in every client.
Run emergency access through EAM with owners, controllers, reason codes, blocked direct logon and completed reviews.
Make every technical user System or Communication type, owned, with S_RFC narrowed to traced function groups.
Remove SM59 destinations with stored credentials from lower environments into production and review trusted RFC.
Enable the audit log baseline in all clients and forward it with HANA audit data centrally.
Analyse SoD at object level, preventively, including technical and firefighter users.
Rebuild roles from usage during S/4HANA migration and move Fiori navigation to spaces and pages.
Triage every Security Patch Day and track internet-facing SAP services.

SAP Identity and Access Guide: Authorisations and Firefighter Access