Your auditor flags one user who can create vendors and release payments. That finding exposes a gap in SAP ERP security. Most teams fix roles and stop there. They leave Remote Function Call (RFC) connections, table access, and audit logs untouched. This article follows a single vendor payment through SAP S/4HANA.
It shows where authentication, authorization, data protection, and monitoring act on that payment. Basis teams, security architects, and finance system owners will see which controls matter most. Each section ties a control to a real failure. You will also learn what changes after a migration from SAP ERP Central Component (ECC) or a move toward clean core.
SAP ERP security is based on multiple layers of security of financial and operational information. Authentication proves identity. Authorization restricts the user’s ability to post, read, or release. The data stored and transferred are secured by encryption and secure interfaces. Audit Logging and Patching Identify and Seal Gaps. If any layer is weak, the entire transaction is vulnerable.
What Is SAP ERP Security?
SAP ERP security consists of a collection of access, data protection, and monitoring controls that safeguard transactions and master data in SAP systems. It includes users, roles, interfaces, databases, and logs. There are a number of layers, with each corresponding to a different failure mode.
The risk is in financial data. The Universal Journal in SAP S/4HANA (ACDOA) is used to feed the general ledger, controlling as well as asset accounting. Purchase orders, production orders, and similar operational records are given similar weight.
The table below maps each layer to the failure it prevents. Use it as a review checklist before you study individual roles.
| Security layer | Main control | What it protects | Typical failure |
| Identity | Single sign-on, multi-factor login, user types | Who enters the system | Shared dialogue or service users |
| Authorization | Profile Generator (PFCG) roles, authorization objects, Core Data Services (CDS) access controls | What each user can do and see | Wildcard values, SAP_ALL assigned |
| Interfaces | S_RFC, Unified Connectivity (UCON), gateway lists, service start rights | Machine-to-machine access | Open RFC paths that skip role design |
| Data protection | Encryption in transit and at rest, field masking | Data on the wire and on disk | Plain connections, unmasked bank data |
| Monitoring | Security Audit Log, change documents, patching | Detection and evidence | Logging disabled or never reviewed |
How Does One Vendor Payment Cross the Security Layers?
A vendor payment touches every security layer in sequence. Identity checks happen at login, authorization checks run in Fiori and the backend, and interface controls apply when the bank file leaves. Logging records each step for later review.
Trace a payment from invoice to bank to see where each control acts. The sequence below assumes an SAP S/4HANA system with SAP Fiori and a bank interface.
- The accounts payable accountant signs in through single sign-on and opens an SAP Fiori app.
- The SAP Fiori launchpad checks the business catalog and the Open Data Protocol (OData) service start authorization.
- The backend checks authorization objects such as F_BKPF_BUK for the company code.
- The posting writes to ACDOCA, and change documents record who made it.
- The payment run creates a payment file for the bank.
- An interface sends the file over a secured channel, and the audit log captures the job.
Each step depends on a different control. A role review covers only steps two and three. It says nothing about identity, the file transfer, or the log.
Partial failure deserves attention here. The payment run can post clearing documents before the file reaches the bank. If the transfer fails, the team needs job logs and alerts so that nobody rekeys the payment outside the controlled process.
How Does Authentication Work in SAP ERP Security?
Authentication confirms who a user is before any authorization check runs. SAP S/4HANA supports single sign-on through Security Assertion Markup Language (SAML) 2.0, and SAP Cloud Identity Services can act as the identity provider. Technical users authenticate differently and need separate controls.
Authentication comes first, and every later control depends on it. If the identity is weak, role design cannot repair the damage.
Single Sign-On and Multi-Factor Login
Central identity removes password handling from individual SAP systems. SAP Cloud Identity Services includes Identity Authentication, which handles login and multi-factor authentication. Its Identity Provisioning component creates and removes users in target systems.
A leaver process then disables access in one place. This matters because stale accounts remain a common audit finding.
Which User Types Carry the Highest Risk?
Shared service users and over-privileged system users carry the highest risk. A system user cannot log in interactively, but it can run background jobs and RFC calls with broad rights. Service users allow anonymous, multi-person access, so teams should restrict them tightly.
Review dialog, system, communication, and service users separately. Start with the S_RFC and S_TCODE rights of every system and communication user. Move to certificate-based authentication where the interface supports it, and never assign the SAP_ALL profile to a technical user.
Principal Propagation Through SAP Cloud Connector
Hybrid scenarios add a second identity question. An SAP Business Technology Platform application calls SAP S/4HANA through SAP Cloud Connector. The call can carry the end user identity through principal propagation, which uses short-lived certificates.
The backend then checks that user’s real authorizations instead of a shared technical user. Teams that skip propagation often grant one technical user broad rights, which hides individual accountability. Keep the trust configuration current, because an expired certificate stops the integration. [INTERNAL LINK: SAP BTP security and hybrid connectivity → SAP Business Technology Platform article]
How Does the SAP Authorization Concept Protect Financial Data?
SAP authorization limits what each user can execute, post, and display through roles built in transaction PFCG. Each role holds authorization objects with field values, such as company code and activity. The system checks those values at runtime and denies the request when they do not match.
Finance roles rely on objects such as F_BKPF_BUK, which checks the company code for accounting documents. F_BKPF_KOA checks the account type, and F_BKPF_BLA checks the document type. Purchasing roles add M_BEST_EKO to control access by purchasing organization.
Transaction SU24 stores the default authorization checks for each transaction and app. PFCG reads those defaults and proposes values when you build a role. Teams then restrict the values to real organizational units instead of accepting wildcards.
Fiori Catalogs Open the Door, Backend Objects Decide
SAP Fiori adds a second layer on top of the backend. Business catalogs and spaces decide which apps a user sees on the launchpad. Catalogs alone grant no data access.
The backend decides the real outcome. The OData service start authorization (S_SERVICE) and the backend authorization objects must both pass. A role that adds catalogs without reviewing backend objects grants the wrong access in one direction or the other.
Align catalogs, spaces, pages, and roles at the start of the project. Rebuilding that mapping after go-live costs far more.
CDS Access Controls Protect Analytical Reads
Analytical Fiori apps read ABAP Core Data Services (CDS) views directly. Those views carry access controls, written in Data Control Language, that check authorization objects before returning rows. A user can pass the app start check and still see no data if the CDS access control denies it.
Treat CDS access controls as part of the role design, not as a developer detail. Custom CDS views need an explicit access control. Without one, the view may return rows with no row-level check.
How Do You Enforce Segregation of Duties in SAP ERP?
Segregation of duties (SoD) means no single user can complete a risky business process alone. Teams define conflicting duty pairs, such as vendor maintenance and payment release, and test role assignments against them. SAP Access Control automates that analysis and manages exceptions.
Start with a ruleset before you build roles. Without defined SoD requirements, new roles repeat the old risks. A ruleset that maps business functions to authorization objects lets the tool flag conflicts at role design time and again at user assignment time.
The table below shows four conflicts that auditors test most often in finance and procurement.
| Conflicting duties | Risk | Authorization focus | Preventive control |
| Maintain vendor bank data and run payments | Payment to a fictitious account | Business partner maintenance versus payment run rights | Separate roles; approval for bank changes |
| Post an invoice and release it | Self-approved invoice | F_BKPF_* posting versus release rights | Release workflow with a second user |
| Create a purchase order and post the goods receipt | Fake receipt to match an order | M_BEST_* versus M_MSEG_BWA | Split by purchasing organization and plant |
| Develop code and import transports to production | Unreviewed code in production | S_DEVELOP, S_TRANSPRT | Approval gate in the transport process |
Emergency access needs its own control. SAP Access Control includes emergency access management, which grants time-limited elevated access with logging and review. Without it, teams hand out SAP_ALL during incidents and forget to remove it.
Which Interfaces Bypass Your Role Design?
Remote Function Call (RFC) connections, OData services, and Intermediate Document (IDoc) partner profiles can bypass role reviews when teams configure them loosely. A technical user with broad S_RFC rights can call function modules that no dialogue user may execute. Interface security needs its own review.
Three controls matter most for RFC. S_RFC limits which functions a caller can run. The Unified Connectivity (UCON) framework lets administrators allow-list the function modules that remote systems may call. Gateway access control lists, such as reginfo and secinfo, restrict which hosts and programs can register or start servers.
Table access deserves the same scrutiny. S_TABU_DIS and S_TABU_NAM control generic table display and change. A role that grants S_TABU_DIS with a wide authorization group exposes sensitive tables through transactions such as SE16.
Prefer dedicated reports or Fiori apps with scoped authorizations over generic table browsers. For IDoc inbound processing, give the processing user only the posting rights for that message type. [INTERNAL LINK: securing integrations → SAP Integration Suite article]
How Does SAP Protect Data in Transit and at Rest?
Teams protect data in transit with Transport Layer Security (TLS) for HTTPS and Secure Network Communications (SNC) for SAP GUI and RFC. SAP HANA supports encryption of the data volume, log volume, and backups. Field-level masking limits what users see on screen.
Encryption alone does not stop a user with valid access from reading sensitive fields. SAP offers UI data protection tools that mask values such as bank account numbers and log who viewed them. Combine masking with narrow roles for the best result.
Plan certificate renewal as an operational task. An expired TLS or SNC certificate stops interfaces such as the bank file transfer. That outage creates business risk as well as a security gap.
What Should SAP Audit Logging Capture?
SAP audit logging should capture logons, changes to users and roles, critical transaction use, and configuration changes. The Security Audit Log records security events at the system level, while change documents record business object changes. Together, they give auditors evidence and give security teams detection signals.
Configure the Security Audit Log with filters for critical events, because unfiltered logging floods storage. Transactions SM19 and SM20 handle configuration and reading in older releases. Newer releases add an enhanced configuration under RSAU_CONFIG.
Forward the logs to a Security Information and Event Management (SIEM) tool or SAP Enterprise Threat Detection. Analysts can then correlate SAP events with network events. That correlation reveals patterns such as a login from a new country followed by a bank detail change.
Patch discipline closes known holes. SAP releases Security Notes on the second Tuesday of each month, known as Security Patch Day. Review them in SAP for Me and the SAP Security Notes page, then rank them by severity and exposure of the affected component.
A log without review gives no protection. Define who reads alerts, how fast they respond, and what evidence they keep.
What Changes in SAP ERP Security After the Move to SAP S/4HANA?
Security design changes in four areas after the move. Fiori replaces many SAP GUI transactions, CDS views add row-level checks, and business partner replaces separate customer and vendor records. Custom code should also follow clean-core rules.
Greenfield projects can design roles around Fiori catalogues from the start. Brownfield conversions inherit old roles, so teams must decide whether to revise or redesign them. Heavy Fiori usage usually favours a redesign.
Business partner authorizations use objects such as B_BUPA_RLT. After conversion, retest who can maintain vendor bank data. Custom ABAP code also needs explicit AUTHORITY-CHECK statements, because code that reads tables directly can bypass role design.
Clean core moves extensions toward released APIs and ABAP Cloud. That keeps extensions on supported interfaces instead of direct table reads. In SAP Cloud ERP (public edition), SAP operates the infrastructure, database, and patching. The customer still owns identities, role content, and data governance.
Conclusion
SAP ERP security is effective when each layer fills a gap left by the others. Identity proves who the user is, authorization limits what they can do, interface controls close hidden paths, encryption protects data, and evidence supports audit and investigation. A weakness in any one layer exposes financial and operational data, because a vendor payment spans all five. The transition to SAP S/4HANA and clean core raises the stakes: Fiori, CDS access controls, and business partner roles change the way access works.
Use one process. Follow a high-dollar transaction (e.g., a vendor payment) through your processes and record the controls. Identify each gap you discover, and address interface and table access issues before you work on refining roles.
Frequently Asked Questions
How does ERP security work for SAP?
SAP ERP secures financial data with access control for posting, viewing, and releasing transactions. Role-based authorization checks company code, account type, and document type. Segregation of duties prevents a single user from completing a risky process. All postings are then documented in audit logs and change documents, aiding investigation and external audit.
What is the difference between authentication and authorization in SAP?
Authentication verifies the identity of the user, and authorization determines what the user is allowed to do. A user can log in successfully with single sign-on and still see an error within an app. This means SAP’s authorization concept denied a required authorization object. The failed check is displayed in transaction SU53.
What is segregation of duties in SAP ERP?
Segregation of duties in SAP means that one user cannot start and complete a sensitive process without the cooperation of another user. Common conflicts occur between vendor maintenance and payment release. Teams establish rules, test the rules against role assignments, and document any exceptions they have agreed to. SAP Access Control provides this analysis and emergency access logging.
Which SAP authorization objects secure financial postings?
Financial posting is protected by objects such as F_BKPF_BUK, F_BKPF_KOA, and F_BKPF_BLA. They verify company code, account type, and document type. For purchasing roles, add M_BEST_EKO. Maintain these checks using transactions SU24 and PFCG, and conduct tests using real posting scenarios.
How do you secure RFC connections in SAP?
Restrict access using S_RFC authorizations, allow-list callable function modules using Unified Connectivity (UCON), and tighten gateway access control lists. Trust RFC connections only between systems of equal security. Use one least-privilege user per connection instead of shared technical users, and review each regularly.
How frequently should SAP be patched for security?
SAP publishes Security Notes on the second Tuesday of the month, known as Security Patch Day. Administrators can find them in SAP for Me under Security Notes. Teams should prioritize these notes according to severity and exposure, and then schedule corrections for Basis, Application, and Kernel components. Record the notes in a patch cycle.
Does SAP S/4HANA protect data at rest?
Yes. SAP HANA supports encryption of data volumes, log volumes, and backups, but administrators need to enable and manage it. With database encryption, data on disk is protected when SAP HANA is used as the platform for SAP S/4HANA. It does not prevent authorized users from accessing data, so it should be used in combination with role design and masking.
Who is accountable for security in SAP Cloud ERP public edition?
In SAP Cloud ERP (public edition), both parties share responsibility. SAP supports the infrastructure, platform, and database operations. User identities, role design, segregation of duties, and data governance are the responsibilities of the customer. Review the shared responsibility model and name the owner of each control.
