SAP security

• Authorization management: least-privilege roles (PFCG), authorization objects.
• Separation of duties (SoD): prevent toxic access combinations (often via GRC).
• Secure configuration: hardened parameters, secured gateway/RFC, TLS.
• Patching and monitoring: SAP Security Notes, the Security Audit Log.

Worth adding a sixth that is often left off the list: data protection. Personal data in HR, customer and supplier records carries legal obligations about who may see it, how long it is kept and whether it can be erased on request. That is a security concern with a legal deadline attached, and it lands on the same roles and the same logging as everything else here.

Security specialists design and review roles for least privilege and SoD, control powerful and emergency (firefighter) access, secure integrations, keep systems patched, and audit access. GRC automates SoD analysis and access requests at scale.

The work also has a rhythm. Role changes and access requests are continuous. User access reviews are periodic. Patch assessment is monthly. Audit support arrives once or twice a year and is far easier when the first three have been happening. Someone new to the discipline usually starts on access requests, which is the right place to learn what the roles actually contain.

Most authorisation questions in an audit reduce to one idea: no single person should be able to complete a transaction that moves money without somebody else being involved.

The classic conflicts are worth knowing by name. Create a vendor and pay a vendor means one person can invent a supplier and send them money. Raise a purchase order and receive the goods means one person can confirm a delivery that never arrived. Post a journal and approve it removes the review entirely. Maintain a user and assign roles means somebody can grant themselves anything.

These are not exotic. They appear naturally in small teams, where the same person genuinely does both jobs because there is nobody else, and that is a business risk rather than a configuration error.

Where the conflict cannot be removed, the answer is a compensating control: a report reviewed by somebody independent, a second approval outside the system, a periodic reconciliation. Auditors accept these when they are documented and actually performed.

Detecting conflicts across hundreds of roles is not manual work. A ruleset defines the conflicting combinations and a tool evaluates every user against it, which is what access control in the governance products exists to do.

Role design gets the attention, and a well-designed role concept on an insecure platform protects nothing.

Default and standard users. Every system ships with known accounts, and every attacker knows them. Changing the delivered passwords and locking what is not needed is the first task on any new system, and it is skipped often enough that it remains a common finding.

Patching. SAP publishes security notes monthly. A note is a fix for something somebody has already found, and an unpatched system is vulnerable to something publicly documented. Applying them on a schedule is unglamorous and it is the single highest-value security activity.

Network exposure. The message server, the gateway and administrative ports should not be reachable from anywhere they do not need to be. Gateway access control lists in particular are a long-standing weak point where the default is permissive.

Encryption. Connections between clients and servers, and between systems, can carry credentials and business data. Secure network communication is available and frequently unconfigured.

Change control. Direct changes in production defeat every other control, which is why the transport path and a locked production client are security measures rather than merely operational ones. See administration security.

A breach or fraud in SAP is severe, it touches finance and operations directly. Strong, audited security (especially SoD) is both protection and a regulatory requirement such as SOX.

There is also a career point. SAP security is a specialisation with consistent demand and relatively few people in it, because it needs both technical depth and an understanding of business process. Someone who can explain why a role conflict matters to a finance director, and then fix it, is unusual. See HANA security for the database layer and Fiori security for the front end.

Security work is largely shaped by what auditors check, so knowing the questions is useful even if you never sit in the meeting.

Who has privileged access. Users with SAP_ALL, with developer access in production, or with the ability to change configuration directly. The expected answer is a short list with names and a reason.

How access is granted and removed. A documented request and approval route, and evidence that leavers were removed. The evidence matters as much as the process.

Segregation of duties conflicts. A report against a ruleset, with either no conflicts or documented compensating controls that somebody actually performs.

Change control. That changes reached production through transports, approved, and that nobody can change configuration in production directly.

Emergency access. Whether elevated access exists, whether it expires, and whether what was done with it was logged and reviewed.

Patching. That security notes are assessed and applied on a schedule.

The pattern across all six is the same: the control must exist, and there must be evidence it operated. A perfect role design with no review record satisfies nobody.

• Who owns it. Security sitting entirely in Basis becomes technical and misses process risk; sitting entirely in audit becomes documentation. It needs somebody who can hold both.
• Build the ruleset or buy one. Segregation of duties rulesets are large and industry-specific, and maintaining your own is real work. Most organisations start from a standard one and adjust.
• How emergency access works. Whether elevated access is pre-approved and logged, or requested each time. The first is faster and depends entirely on the log being reviewed.
• Patch cadence. Monthly assessment with a defined window for critical notes, or patching only during upgrades. The second is common and it is a decision to be made deliberately rather than by default.

• Over-privileged roles / SAP_ALL misuse.
• Unpatched systems.
• Insecure RFC/gateway.

• Treating security as a go-live task. Roles drift as people change jobs, and a concept nobody reviews is out of date within a year.
• Emergency access with no expiry. Firefighter access is legitimate and it must expire and be logged, or it becomes permanent privilege.
• Securing the application and ignoring the database. Direct database access bypasses every authorisation object in the system.

• Reviewing users and not roles. A user with three correct roles can still hold a conflict, because the conflict is across roles rather than inside one.
• Assuming the sandbox does not matter. It often holds a copy of production data with weaker controls, which is the definition of an easy target.
• Treating developer access in production as normal. It bypasses the change path entirely.

Understanding the pillars is the start, and designing a role concept and testing it against a segregation of duties ruleset is the part you do in the course.

If one idea is worth carrying: a control that exists and leaves no evidence it operated will not satisfy an audit, and more importantly will not tell you when it stopped working. Design the evidence at the same time as the control.

If you run the system rather than design the concept, SAP security for administrators covers the day-to-day: roles, segregation of duties and the Security Audit Log.