Enterprise Security Architecture for SAP Landscapes: Complete Technical Guide

Sarah Chen, Lead SAP Architect — SAPExpert.AI Weekly Deep Research Series

Executive Summary (≈150 words)

Enterprise SAP security is no longer “ABAP roles + firewall rules.” Modern SAP estates (S/4HANA, ECC, BW/4HANA, HANA, SAP BTP, APIs, and integrations) behave like a distributed identity-and-API platform—where interfaces are the real perimeter, and identity assurance determines blast radius.

This report proposes a six-plane reference architecture (Identity, Access Control, Connectivity, Data Protection, Monitoring & Response, Assurance) and shows how to implement it with federated SSO (SAML/OIDC), MFA/conditional access, PAM with just-in-time elevation, least-privilege technical users, strong transport/change governance, and SIEM-driven detection engineering. We emphasize advanced, often-missed controls: UCON for RFC/HTTP allow-listing, token audience governance, Cloud Connector blast-radius reduction, high-fidelity privileged activity logging, and drift-resistant baselines.

The outcome is a security posture that remains valid as landscapes evolve toward BTP extensions, API-centric integration, and continuous compliance—without sacrificing operational usability.

Technical Foundation (≈400–500 words)

1) The security problem SAP landscapes actually have

SAP security failures in mature enterprises rarely come from “no roles defined.” They come from inconsistent trust decisions across tiers:

• A browser session is authenticated by an IdP, but the backend authorizes via stale PFCG roles.
• An integration uses a powerful RFC technical user “because it always worked.”
• Fiori catalogs expose apps that look restricted, while the OData service is reachable and poorly constrained.
• Security hardening is performed once, then silently drifts across systems and transports.

To solve this, you need an architecture that treats SAP as a federated identity system + integration mesh, with explicit trust boundaries.

2) Reference architecture: six security planes

Use this as a blueprint for heterogeneous SAP estates:

1. Identity Plane — corporate IdP is primary authenticator; MFA + conditional access; lifecycle via IGA.
   Key SAP touchpoints: SAML2/OIDC trust, SNC/Kerberos for SAP GUI, BTP trust configuration.
   See: SAP Identity Authentication (IAS) – Documentation

2. Access Control Plane — role engineering (ABAP/Fiori/HANA), SoD governance, PAM + emergency access.
   See: ABAP Authorization Concept (SAP Help)

3. Connectivity Plane — segmentation + DMZ; TLS/SNC everywhere; interface allow-listing and inventory.
   See: Secure Network Communications (SNC) – SAP Help

4. Data Protection Plane — encryption in transit/at rest; sensitive-data access monitoring; extraction control.
   See: SAP HANA Security Guide (SAP Help)

5. Monitoring & Response Plane — SAP logs → SIEM, detection use-cases, and runbooks mapped to SAP abuse patterns.
   See: Security Audit Log (AS ABAP) – SAP Help

6. Assurance Plane — hardening baselines, Security Notes governance, drift detection, transport controls, evidence automation.
   See: SAP Security Notes & News (SAP Support)

3) A practical threat model that drives architecture

Focus on high-frequency, high-impact categories:

• Credential theft + session replay (SSO without MFA, long-lived tokens)
• Privilege escalation (wildcards in critical objects, shared accounts, firefighter misuse)
• Interface abuse (trusted RFC, broad Cloud Connector mappings, exposed ICF services)
• Change control bypass (unauthorized transports/customizing, debugging in production)
• Patch/config drift (kernel/ICM, crypto, insecure parameters)

Implementation Deep Dive (≈800–1000 words)

A) Target-state topology (zoning + explicit trust)

A repeatable zoning model that scales across on-prem, private cloud, and hybrid:

flowchart LR
  U[Users / Devices] -->|HTTPS + SSO| WAF[WAF/Reverse Proxy]
  WAF --> WD[SAP Web Dispatcher / LB]
  WD --> APP[AS ABAP (S/4/ECC/BW) + Gateway]
  APP --> DB[(SAP HANA)]
  APP --> INT[Integration (PI/PO/CPI/API GW)]
  INT --> BTP[SAP BTP Apps/Services]
  MGMT[Mgmt Zone: Jump/PAM/SIEM/Monitoring] --> APP
  MGMT --> DB

  classDef zone fill:#0b1f3a,color:#fff,stroke:#2b4c7e

Non-negotiables

• No direct internet reachability to app servers or HANA.
• All administrative access traverses a controlled management zone (jump host + PAM).
• Allow-list traffic between zones; block lateral movement by default.

B) Identity plane: SSO that is auditable and resistant to theft

1) Browser SSO (Fiori, web UIs): SAML2 or OIDC with strong policy

• For AS ABAP Fiori: configure SAML 2.0 trust in transaction SAML2, with signed assertions and tight audience restrictions.
  Reference: SAML 2.0 Configuration (AS ABAP) – SAP Help

Hardening patterns that are often missed

• Enforce IdP-side conditional access (device compliance, geo, risk signals) and step-up MFA for sensitive apps/groups.
• Set short session lifetimes for administrative Fiori content; avoid “remember MFA” for privileged roles.
• Ensure logout and session invalidation patterns are defined (especially for shared kiosks).

2) SAP GUI SSO: SNC/Kerberos internally, MFA externally/admin

• Use SNC with Kerberos to eliminate password exposure on corporate devices; require MFA when the access path is remote or privileged.
  Reference: SNC for AS ABAP – SAP Help

Operational control: disable password logon for privileged IDs where feasible (or enforce long, vaulted secrets and rotation).

C) Access control plane: role engineering that survives S/4HANA + Fiori complexity

1) ABAP role model (PFCG) with enforceable standards

Recommended structure

• Business roles (composites): aligned to job functions/processes.
• Derived roles: enforce org-level restrictions (company code, plant, sales org).
• Technical roles: batch, RFC, background processing—segregated from dialog.
• Admin roles: Basis/security/firefighter—separately governed via PAM.

Wildcards are design debt Create a policy that forbids * in critical authorization fields except with explicit exception records (ticket + expiry). Typical hotspots:

• S_USER_GRP, S_USER_AGR, S_USER_AUT
• S_TABU_DIS (especially with broad table auth groups)
• S_RFC, S_RFCACL
• S_SERVICE, S_ICF (service activation + access)

Engineering workflow

• Use SU24 proposals to reduce manual “auth creep.”
  Reference: SU24 (Authorization Default Values) – SAP Help

Troubleshooting discipline

• SU53 for last failed check + STAUTHTRACE (ST01 replacement) for full traces.
  Reference: Authorization Checks and Traces – SAP Help

2) Fiori authorization: separate exposure from permission

A robust Fiori design treats Launchpad catalogs/spaces/pages as UI exposure, not authorization. Backend authorization remains decisive.

Control pattern

• For each app: validate ICF service activation, OData service, and business object authorization.
• Enforce least privilege on Gateway/service objects rather than granting broad technical “fix” roles.

Practical test loop

1. App fails → check browser console/network (HTTP 401/403).
2. On backend: run SU53.
3. If inconclusive: run STAUTHTRACE for the user and reproduce.

Reference for Gateway/security concepts: SAP Gateway Security Guide – SAP Help

3) Emergency access (firefighter) as a monitored control, not a “super user”

Minimum viable firefighter design

• Time-boxed assignment (hours, not days)
• Mandatory reason code (ticket integration)
• Session/activity logging + post-review sign-off
• Separate firefighter IDs per system and per domain (Finance vs Basis)

This is where PAM integration pays off: credentials are not known by humans, sessions are recorded, and elevation is just-in-time.

D) Connectivity plane: shrink the perimeter by controlling interfaces

1) RFC: protect with SNC and reduce trust blast radius

Hard rules

• No plaintext RFC across zones.
• No shared RFC users.
• No “trusted RFC” unless you can prove compensating controls and tight scoping.

Least-privilege RFC design

• Create one technical communication user per interface.
• Restrict RFC authorizations (S_RFC) to function groups actually required.
• Constrain destinations and callers.

Advanced control many teams skip: Unified Connectivity (UCON) to allow-list RFC/HTTP calls and reduce the impact of credential theft or misconfiguration.
Reference: UCON (Unified Connectivity) – SAP Help

2) HTTP/OData/APIs: prefer OAuth2 + gateway enforcement

• Put APIs behind an API gateway (corporate or SAP) with rate limits, schema validation, and threat protection.
• Use OAuth2 client credentials for system-to-system; user-delegated flows for interactive scenarios.

On BTP, align with Authorization and Trust Management concepts and short-lived tokens.
Reference: Authorization and Trust Management (XSUAA) – SAP Help

3) BTP → on-prem: Cloud Connector as a blast-radius boundary

Cloud Connector design rules

• Avoid wildcard resource exposure.
• Separate subaccounts for non-prod/prod.
• Monitor and alert on mapping changes.

Reference: SAP Cloud Connector – SAP Help

E) Data protection plane: secure HANA and prevent silent mass extraction

1) HANA least privilege with auditability

Implement:

• Named DB users for admin with MFA-controlled access path
• Roles aligned to workload
• Encryption at rest + TLS for client connections
• HANA audit policies for privileged actions

Reference: SAP HANA Security Guide – Audit Policies

Example: create a focused audit policy (illustrative; tune events to your risk model):

-- Run as a privileged security admin in SAP HANA
CREATE AUDIT POLICY AUDIT_PRIVILEGE_CHANGES
  AUDITING SUCCESSFUL
  FOR CREATE USER, DROP USER, ALTER USER,
      CREATE ROLE, DROP ROLE,
      GRANT, REVOKE
  LEVEL INFO
  TRAIL TYPE SYSLOG;   -- or DATABASE, depending on your architecture

ALTER SYSTEM ALTER AUDIT POLICY AUDIT_PRIVILEGE_CHANGES ENABLE;

2) ABAP data access governance: watch the “exports,” not just logons

Most SAP data loss is authorized but inappropriate. Add controls around:

• Sensitive table access (where feasible)
• Mass download channels (ALV export, RFC extractions, CDS/OData reads)
• Analytics datasets and extract jobs

This is where detective controls (SIEM use-cases) matter more than theoretical “perfect RBAC.”

F) Monitoring & response: turn SAP logs into detections

1) Log sources to centralize (minimum set)

• ABAP Security Audit Log (SM19/SM20)
  Reference: Security Audit Log – Configuration (SAP Help)
• User/role change logs (including PFCG changes)
• ICM/HTTP access logs (Web Dispatcher + reverse proxy)
• HANA audit log
• PAM session logs for privileged actions

2) High-value SIEM detections (SAP-specific)

Build alerts and runbooks for:

• Mass role assignment or sudden privilege uplift (e.g., new composite roles assigned broadly)
• New RFC destinations to sensitive systems or changes to trust relationships
• Burst failed logons + successful logon from anomalous location/device
• Activation of ICF services in production outside approved change windows
• Creation/usage spikes of powerful technical users, background jobs scheduled by unusual users

Novel insight: Treat changes in interface configuration (destinations, Cloud Connector mappings, ICF activations) as Tier-0 security events—often more predictive than end-user behavior.

G) Assurance plane: security that doesn’t drift

1) Security Notes governance with evidence

Implement a lifecycle:

• Weekly review of SAP Security Notes
• Applicability assessment by component/version
• Patch SLAs by severity
• Evidence capture (note implemented, transport IDs, kernel levels, scan output)

Reference: SAP Security Notes & News – Process Entry Point

2) Continuous baseline enforcement

Move from “hardening project” to “hardening product”:

• Baseline parameter sets per component (AS ABAP, Web Dispatcher, HANA)
• Automated checks (config snapshots + diff)
• Exception management with expiry

Advanced Scenarios (≈500–600 words)

1) End-to-end principal propagation (without creating a security mess)

A frequent anti-pattern is using one powerful technical user to represent many humans across BTP → middleware → S/4. Instead, implement principal propagation where the business case demands auditability:

Pattern: User-delegated access

• User authenticates at IdP (OIDC/SAML)
• Token exchanged/propagated to middleware
• Backend authorizes as the user (or as a constrained “business technical user” with user context) and logs are attributable

Controls that make this safe

• Token audience (aud) restricted to the exact API/backend
• Short token lifetime (minutes), no refresh tokens for high-risk flows
• mTLS between gateway and sensitive backends
• Scope design mirrors business actions, not “read/write all”

On SAP BTP, align scope-to-role mapping through XSUAA roles/role collections and maintain strict separation of subaccounts.
Reference: Role Collections and Authorization (BTP) – SAP Help

2) RFC trust minimization with UCON + allow-listed integrations

If you must keep legacy RFC integrations:

• Remove blanket “trusted RFC.”
• Use UCON to explicitly allow-list:
  • which callers can reach which RFC-enabled function modules
  • which HTTP services are callable
• Combine with per-interface users and tight S_RFC scoping.

This provides “micro-segmentation at the ABAP interface layer,” which network segmentation alone cannot achieve.

Reference: UCON – Concept and Administration

3) Secure software supply chain for ABAP + UI5 extensions

Security architecture must include change pipelines:

• Enforce ABAP secure coding checks via ATC and block transports with high-risk findings.
  Reference: ABAP Test Cockpit (ATC) – SAP Help
• For UI5/front-end artifacts, ensure dependency hygiene and locked-down build pipelines (even when SAP-delivered libraries are used).

Example: enforce authorization checks in custom ABAP A high-risk custom pattern is missing authorization checks before sensitive operations:

" Example: enforce an authorization object check before an update
AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'
  ID 'BUKRS' FIELD lv_bukrs
  ID 'ACTVT' FIELD '02'.  "Change

IF sy-subrc <> 0.
  MESSAGE e398(00) WITH 'Not authorized to change postings for company code' lv_bukrs.
ENDIF.

" Proceed with update only after explicit check

Advanced guidance: make authorization checks testable—wrap checks in reusable classes and add ATC checks/peer review rules for “no DB update without AUTHORITY-CHECK.”

4) Ransomware-resilient operations (availability as a security requirement)

For SAP, ransomware impact is amplified by:

• shared file systems (interfaces, AL11 directories)
• transport directories
• backup catalogs and HANA backups

Architectural countermeasures:

• immutable backups and separate backup credentials
• segmentation between SAP app zones and backup infrastructure
• hardened jump hosts and PAM for all admin paths
• operational runbooks to restore HANA + AS ABAP in correct dependency order

Real-World Case Studies (≈300–400 words)

Case Study 1 — Global manufacturer: “Interfaces are the perimeter”

Context: S/4HANA 2022 on-prem, BW/4HANA, PI/PO, and a growing BTP footprint.
Issue: Audit found dozens of RFC users with broad access (S_RFC wide, some with SAP_ALL), hardcoded in middleware.
Approach:

• Full interface inventory; removed ~20% dormant destinations.
• Created per-interface technical users with derived roles and strict function group scoping.
• Implemented SNC for cross-zone RFC and rotated secrets into a vault.
• Added SIEM detections for “new RFC destination created/changed” and “RFC logon failures spike.” Outcome: Attack surface reduction was measurable (fewer privileged users, fewer active destinations). Support effort dropped because interface ownership and documentation became explicit.

Case Study 2 — Financial services: JIT privileged access + evidence automation

Context: ECC + S/4 coexistence, strict SoD and external audits.
Issue: Firefighter accounts existed but were shared, reviews were inconsistent, and evidence collection was manual.
Approach:

• PAM integrated: just-in-time elevation, recorded sessions, ticket-based reasons.
• Standardized emergency roles; removed standing admin access.
• Automated weekly evidence bundles (privileged sessions, role changes, critical config diffs). Outcome: Audit findings shifted from “control not operating effectively” to “operating with consistent evidence,” and mean-time-to-approve emergency access improved.

Case Study 3 — Retail: API-first security during peak season

Context: S/4HANA + heavy e-commerce integration, seasonal spikes.
Issue: OData endpoints were reachable through overly permissive routing; rate limiting was inconsistent.
Approach: API gateway in front, OAuth2 scopes mapped to business functions, throttling + anomaly alerts, and strict ICF service governance in production.
Outcome: Improved stability under load and reduced exposure from scraping and token replay attempts.

Strategic Recommendations (≈200–300 words)

A pragmatic 90-day → 12-month roadmap

0–90 days (stabilize and reduce blast radius)

• Centralize authentication at corporate IdP; enforce MFA for admins and remote access.
• Inventory interfaces (RFC/HTTP/OData/Cloud Connector). Remove dead paths.
• Implement baseline SIEM ingestion: ABAP Security Audit Log + HANA audit + proxy logs.
• Establish “no shared dialog users” and begin vaulting technical secrets.

3–6 months (standardize and operationalize)

• Role engineering program: naming standards, derived role strategy, wildcard eradication plan.
• PAM rollout: JIT elevation + firefighter workflows with post-review.
• UCON pilot in one high-risk production system to allow-list interfaces.
• Patch governance: Security Notes SLA + evidence workflow.

6–12 months (optimize and future-proof)

• Token governance (audience, lifetimes) and consistent OAuth2 for APIs.
• Continuous baseline/d drift detection across DEV/QAS/PRD.
• Automate compliance evidence and expand detection engineering with runbooks.

Risk mitigation principle: prioritize controls that reduce credential misuse + interface abuse first—these dominate real-world SAP incidents.

Resources & Next Steps (≈150 words)

Official SAP documentation (start here)

• SAP Security Notes & News (SAP Support)
• Security Audit Log (AS ABAP) – SAP Help
• SAML 2.0 Authentication (AS ABAP) – SAP Help
• Secure Network Communications (SNC) – SAP Help
• SAP HANA Security Guide – SAP Help
• SAP Cloud Connector – SAP Help
• Authorization and Trust Management (XSUAA) – SAP Help

Next steps (actionable)

1. Build an interface register (RFC/HTTP/OData/BTP mappings) with owners and authentication methods.
2. Define your security planes as deliverables with KPIs (MFA coverage, wildcard count, dormant interfaces removed, baseline drift rate).
3. Run a 2-week security architecture review against this guide and convert gaps into an execution backlog.