SAP Security & Authorisation
Weak SAP security is the most common finding in every external audit of an SAP landscape — and the one finding that takes the longest to remediate after it's discovered. Excessive authorisations, undetected segregation of duties conflicts, shared user IDs, unchecked firefighter access and misconfigured Basis parameters are not abstract compliance risks; they are operational exposures that enable fraud, data loss and audit failure. 2iSolutions designs, implements and audits SAP security across S/4HANA, Business One and BTP — covering role design, authorisation concept, SoD analysis, GRC implementation and ongoing access governance.
What SAP security gaps actually look like — and what they enable
Security issues in SAP are rarely dramatic until they're discovered in an audit or after an incident. These are the six most common gaps — and what they enable when left unaddressed.
Multiple users share one SAP login — single generic ID used by entire accounts team
Fraud cannot be attributed to an individual — audit trail is useless; no accountability for posted transactions
The same user can create a vendor master and also process payment to that vendor
Classic vendor fraud — fictitious vendor created and paid without requiring a second approver at any step
Production users carry SAP_ALL or S_A.CUSTOMIZ profile from an old implementation project
Any user with these profiles can change configuration, delete master data, modify transport management — audit finding always raised as critical
ABAP debug with replace authorisation (S_DEVELOP with ACTVT 02) assigned to non-developer users
User can bypass SAP authorisation checks at runtime — any access restriction can be overridden; critical finding in every security audit
Former employee accounts still active 6 months after leaving — never deactivated in SAP
Dormant accounts are primary targets for external attacks; former employees retain system access they should not have
RFC connections between systems using stored dialog user credentials rather than system users
Compromising one system through the RFC connection gives attacker dialog access to connected systems — one breach becomes multiple
SAP security & authorisation services
Authorisation Concept Design
Designing the role architecture from scratch — single roles, composite roles and derived roles mapped to job functions rather than transactions. Organisation-level field values, tolerance groups and structural authorisations defined per business unit. A well-designed concept prevents years of role remediation; a poorly designed one creates accumulating technical debt in every user's profile.
Role Design & PFCG Build
Building roles in the Profile Generator (PFCG) to the documented concept — transaction code assignment, authorisation object field value assignment, organisational level population and derived role hierarchy setup. Menu-based roles for user navigation plus authorisation roles for access control, segregated where required for clean transport management.
SoD Analysis & Remediation
Identifying segregation of duties conflicts across all active user assignments — conflicting access combinations that enable fraud, data manipulation or policy bypass. Conflict matrix defined against your risk appetite, conflicts identified per user, remediation options (role split, mitigating control, access removal) assessed and implemented. GRC Access Control used for automation where volume warrants it.
Security Health Check & Assessment
A structured assessment of the SAP security posture — covering user master records, role assignments, profile parameters (auth/no_check_in_some_cases, login/fails_to_session_end), RFC security, transport system security and Basis-level configuration. Output: a risk-rated findings report with remediation priorities and effort estimates, structured for presentation to IT management and auditors.
SAP Fiori & S/4HANA Authorisation
Fiori authorisation is separate from — and more complex than — classic SAP GUI authorisation. Business catalogue and group assignment, tile-level visibility control, OData service authorisation objects, business role framework (S/4HANA 2020+) and launchpad space management. Fiori implementations frequently go live with over-permissive access because Fiori auth is underestimated in implementation scope.
Audit Support & Remediation
Preparing the SAP security landscape for external audit — responding to auditor information requests, remediation of pre-audit findings before the audit starts, and post-audit finding remediation with auditor-acceptable evidence. Ongoing periodic access review management so the landscape never reaches the state that generates an audit finding in the first place.
How SAP authorisation works — the four-layer model
SAP authorisation is not a simple "allow or deny" — it is a layered object model where access is determined by the combination of transaction codes, authorisation objects, field values and organisational levels. Understanding the model is prerequisite to designing roles that work correctly.
The most common design error: Assigning access at Layer 1 (transaction codes) without restricting Layer 2 (authorisation object field values) and Layer 3 (organisational levels). A user assigned FB50 (journal entry) without Company Code restriction in F_BKPF_BUK can post to every company code in the system — not just their own.
SoD conflicts in SAP — the most common and most costly security gap
Segregation of duties means no single user should control an entire business process end-to-end — particularly where the process involves money, master data or approval. These are the six SoD conflicts most commonly found in SAP landscapes — each representing a real fraud or error risk.
Create Vendor + Post Payment
One user can create a fictitious vendor record and then process payment to it — complete fraud cycle without a second person involved. Most critical SoD in Accounts Payable.
Create Customer + Post Credit Memo
User can create a customer account and issue an unsupported credit memo — reducing a customer's balance without an approved reason or second reviewer.
Create PO + Goods Receipt + Invoice Verify
Same user controls the full procure-to-pay cycle — creating the order, receiving the goods and approving the invoice. No verification at any step.
Maintain Employee Master + Process Payroll
User can change bank account details on an employee record and then run the payroll — redirecting salary payments without a secondary approval on the bank change.
Access to Development + Production Transport
User can write ABAP code and also release the transport to production — bypassing the requirement for a second person to approve production changes.
Maintain Pricing Conditions + Create Sales Order
User can change pricing condition records and then create sales orders at manipulated prices — inflating or deflating revenue without authorisation.
We analyse all active users — not just a sample — against a conflict matrix calibrated to your risk policy. Every user with a conflict receives a remediation recommendation: role split, access removal, or documented mitigating control accepted by management.
Five-phase security engagement — from assessment to sustained governance
Security is not a project with a finish line — it is an ongoing governance function. Our methodology moves through an initial fix phase and into a sustained management model.
Assess
Security health check — user master, role assignments, SoD conflicts, Basis parameters, RFC security
Design
Role architecture, SoD conflict matrix, org-level framework, emergency access process
Remediate
Role rebuild, SoD conflict resolution, over-privileged access removal, Basis parameter hardening
Validate
UAT with business users, SoD re-scan to confirm resolution, regression test on critical processes
Govern
Periodic access review, joiner/mover/leaver process, SoD monitoring, audit evidence generation
What the assessment covers
- Users with SAP_ALL or critical profiles
- Debug authorisation (S_DEVELOP ACTVT 02) in production
- Shared / generic user IDs in use
- Dormant accounts (no login in 90+ days)
- SoD conflicts across all active assignments
- RFC connections using dialog credentials
- Critical Basis parameters (login, auth, rfc)
- Transport system security configuration
Governance deliverables — ongoing
- Quarterly user access review report
- Joiner / mover / leaver process execution
- New role request assessment (SoD pre-check)
- Monthly SoD conflict monitoring report
- Emergency access (firefighter) log review
- SAP security notes applied on schedule
- Audit evidence package prepared on request
- Annual security health check refresh
What we use to assess and manage SAP security
Profile Generator
SAP's native role maintenance tool — transaction code assignment, authorisation object field values, menu build and transport management for role changes.
Auth Object Proposals
Maintains the proposed authorisation objects for each transaction — used to ensure role builds pick up all required auth checks without manual object hunting.
User Information System
Cross-queries on users, roles, profiles and authorisations — "find all users who have access to FB50 in company code 1000" — essential for SoD analysis and audit evidence.
Auth Failure Analysis
Shows the authorisation check that failed for a user's last access denied error — the first tool used to diagnose missing authorisations after role assignment.
Audit Log Analysis
Security audit log (SM20) and workload statistics (STAD) for forensic analysis — tracking which user performed which action at what time on what data.
GRC Access Control
Automated SoD conflict detection, access risk analysis, emergency access management (Firefighter) and access request workflow for enterprises with high user volumes.
Profile Parameters
SAP instance and default profile parameter management — setting login security parameters, password complexity rules, session limits and RFC trusted system configuration.
BW/BI Analysis Auth
SAP BW/BI analysis authorisation administration — cell-level data security for BW queries ensuring users see only the data their organisational level permits.
What makes our SAP security practice effective
Functional + Security Knowledge Together
SAP security requires knowing what each transaction and authorisation object actually does in the business process — not just how to assign it. Our security team is drawn from functional consultants who know Finance, Procurement and Manufacturing, not only from technical Basis consultants. This means SoD conflict assessments reflect real business risk, not generic ruleset matches.
Design Before Build
We design the authorisation concept — role architecture, SoD matrix, org-level framework and user provisioning process — before building a single role in PFCG. Roles built without a concept are the reason most SAP landscapes require full security remediation three years after go-live. The design is the deliverable that prevents the remediation project.
Full SoD Scan — Not Sampling
SoD analysis on a sample of users misses the conflicts that matter. We run the full conflict scan across every active user — not a statistically representative sample — because the fraudulent combination is more likely to be in the user you didn't check. Every conflict is documented, prioritised and remediated or mitigated.
Audit-Evidence Ready
Our security assessments and remediation work are documented to the standard external auditors require — user access evidence, SoD conflict reports, parameter configuration screenshots and role build documentation all packaged for audit presentation. Clients preparing for Big 4 audits or regulatory inspections don't need to create this evidence from scratch.
S/4HANA & Fiori Security Depth
Fiori authorisation — business catalogues, groups, tile visibility, OData service objects and the S/4HANA business role framework — is systematically underscoped in S/4HANA implementations. Our security team covers both the classic ABAP authorisation layer and the Fiori/UI5 layer that governs what users actually see in their S/4HANA interface.
Ongoing Governance Under AMS
Security isn't a project; it's an ongoing function. Joiner/mover/leaver access management, quarterly access reviews, new role request SoD pre-checks and periodic security health check refreshes are all delivered under our AMS practice — so the security posture stays current as the organisation and system evolve.
SAP security and authorisation from a Gold Partner with 21 years of delivery
Our security practice covers implementation-phase authorisation design, post-go-live SoD remediation, pre-audit security hardening and ongoing governance under AMS — across S/4HANA, ECC, Business One and BTP landscapes.
SAP security & authorisation: frequently asked questions
What is an SAP authorisation concept and why does it matter?
An SAP authorisation concept is the design document that defines how access is structured — which role types are used (single, composite, derived), how organisational levels are populated, how SoD conflicts are managed, what the user provisioning process is and how emergency access is controlled. Without a documented concept, roles accumulate inconsistently, SoD conflicts multiply, and the access landscape becomes impossible to audit or maintain. Most SAP security remediation projects trace back to an implementation that didn't produce a concept before building roles.
What are the most critical SAP security findings in an external audit?
The four findings that appear in virtually every SAP security audit: (1) users with SAP_ALL or equivalent super-user profiles in production; (2) unresolved SoD conflicts — specifically the create-vendor-and-pay and create-PO-and-goods-receipt combinations; (3) debug authorisation (S_DEVELOP with ACTVT 02) assigned to non-developers in production; and (4) dormant accounts still active for former employees. Each of these is identifiable with standard SAP tools and remediable before the audit — they should never appear as first-time audit findings.
What is a SoD conflict and how is it identified in SAP?
A segregation of duties conflict exists when one user has access to perform two or more steps in a process that should require different people — creating a vendor and paying that vendor, for example. In SAP, conflicts are identified by checking every active user's role and profile assignments against a conflict matrix that defines which transaction and authorisation object combinations are incompatible. The analysis is done using SUIM (User Information System), custom ABAP reports or GRC Access Control for automated detection and ongoing monitoring.
What is SAP GRC Access Control and when do we need it?
SAP GRC Access Control automates SoD conflict detection, access risk analysis, access request and approval workflow, and emergency access management (Firefighter). It's appropriate for organisations with large user populations (500+ active users), frequent access change requests, regulatory requirements mandating continuous SoD monitoring, or complex role landscapes where manual SoD analysis is impractical. For smaller landscapes, manual SoD analysis using SUIM and custom reports — combined with a periodic access review process — may be sufficient and significantly cheaper.
How is SAP Fiori authorisation different from SAP GUI authorisation?
Classic SAP GUI authorisation controls access through transaction codes (S_TCODE) and authorisation objects checked by ABAP code. Fiori authorisation has an additional layer — the launchpad layer — where business catalogues control which app tiles are visible and accessible. A user may have the ABAP authorisation to run a transaction but not see the Fiori tile because the catalogue isn't assigned, or vice versa — they see the tile but get an authorisation error when opening it. S/4HANA's business role framework (from 2020) adds another layer of configuration. Fiori auth requires managing both layers together.
How long does an SAP security remediation project take?
A focused SAP security health check and critical-finding remediation for a mid-size S/4HANA landscape typically takes 6–10 weeks: 2 weeks for assessment and findings documentation, 2 weeks for remediation design, 4–6 weeks for role changes, user access corrections and parameter hardening. Full role redesign — rebuilding the entire role architecture from scratch — is a larger programme: 3–6 months depending on the number of roles, user population and the complexity of the SoD conflict matrix. Fiori authorisation redesign adds scope proportional to the number of Fiori apps in use.
Security audit coming — or want to know your SAP security posture before one does?
A structured SAP security assessment takes 2 weeks — covering user access, SoD conflicts, critical profile assignments, debug authorisations, dormant accounts, RFC security and Basis parameter configuration. Output is a risk-rated findings report with remediation priorities, ready for management and auditor review.