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 landscapes (S/4HANA, ECC, BW/4, BTP, and SAP SaaS) remain high-impact targets because authorization changes and interface identities can directly move money, alter supply chains, or manipulate financial reporting—often without “exploiting” anything beyond misconfiguration. Modern SAP security architecture therefore must treat identity as the control plane, enforce defense-in-depth across tiers, and operationalize security as an always-on product (patching, governance, detection, and recovery).

Key recommendations:

1. Centralize authentication in an enterprise IdP (Entra ID/Okta/Ping) with MFA + conditional access, while keeping authorization enforcement in SAP (ABAP roles/PFCG + Fiori + OData).
2. Standardize a reference architecture: segmented network + hardened ABAP/HANA + controlled integration patterns (API gateway, mTLS/OAuth2, Cloud Connector) + PAM-governed privileged access.
3. Establish a monthly SAP Security Notes cycle, configuration drift monitoring, and SIEM detections engineered for SAP abuse cases (role escalation, RFC misuse, ICF service activation, suspicious postings).

Technical Foundation (≈400–500 words)

1) Landscape model and trust boundaries

Most enterprises still operate a 3-system landscape (DEV → QAS → PRD), frequently extended with sandbox, pre-prod, and dual maintenance tracks. Security architecture must assume that DEV is hostile compared to PRD (developer tooling, broad access, frequent change). A secure blueprint defines explicit trust boundaries across:

• Network/DMZ (reverse proxy/WAF, IP allowlists, admin jump paths)
• OS/platform (hardened build, EDR, privileged access segregation)
• Database (SAP HANA 2.0 SPSxx) (audit, encryption, least privilege)
• SAP application layer (ABAP Platform / S/4HANA) (PFCG roles, auth objects, secure parameters)
• UI layer (Fiori/GUI) (SSO, TLS, device posture)
• Integration layer (RFC/SNC, HTTP/OData, API gateway, BTP connectivity)
• Identity layer (IdP, provisioning, governance, PAM)
• Operations (logging → SIEM, vulnerability mgmt, incident response)

A practical architectural mantra: every interface is a security boundary—RFC destinations, ICF services, OData endpoints, background users, schedulers, and BTP service bindings.

2) Identity vs. authorization (don’t conflate)

• Authentication answers “Who are you?” (SAML2, OIDC, Kerberos, X.509, MFA).
• Authorization answers “What can you do?” and is enforced primarily in SAP:
  • ABAP: authorization objects + fields/values aggregated into PFCG roles
  • S/4HANA Fiori: backend authorizations + Fiori catalogs/spaces/pages + OData service authorization

Architectural anti-pattern: “We federated logon, so we’re secure.” In reality, most SAP incidents stem from over-privileged roles, weak technical users, and ungoverned interfaces.

3) SAP-specific security building blocks

• STRUST / PSEs: ABAP key store for TLS, signatures, SNC identities
• SNC (Secure Network Communications): strong auth + encryption for SAP GUI/RFC
• ICF / SICF + OData services: the most common web exposure surface in S/4HANA
• SAP Web Dispatcher: SAP-aware reverse proxy for HTTP(S) (often DMZ)
• HANA audit: database-level evidence for auth events and sensitive actions

Authoritative component references:

• ABAP Platform security topics: SAP NetWeaver Application Server ABAP – Security
• SAP HANA security topics: SAP HANA Platform – Security
• SAP Web Dispatcher guidance: SAP Web Dispatcher
• SAP Cloud Connector: SAP Cloud Connector
• SAP Cloud Identity Services (IAS/IPS): SAP Cloud Identity Services
• SAP Security Notes program: SAP Security Notes and News
• SAP PSRT process: SAP Product Security Response Team (PSRT)

Implementation Deep Dive (≈800–1000 words)

Reference architecture (on-prem + hybrid) with trust boundaries

flowchart LR
  U[Users<br/>Managed Devices] -->|SAML/OIDC + MFA| IdP[Enterprise IdP<br/>Entra/Okta/Ping]
  U -->|SNC Kerberos/X.509| GUI[SAP GUI]

  subgraph DMZ[DMZ]
    WAF[WAF / Reverse Proxy]
    WD[SAP Web Dispatcher]
    WAF --> WD
  end

  subgraph APP[Internal Network: SAP App Tier]
    FLP[Fiori Launchpad / ICF]
    ABAP[ABAP App Servers]
    ICM[ICM HTTP(S)]
    WD --> ICM
    ICM --> ABAP
    GUI --> ABAP
  end

  subgraph DB[Internal Network: DB Tier]
    HDB[(SAP HANA)]
  end

  ABAP --> HDB

  subgraph INT[Integration Zone]
    APIM[API Gateway]
    CPI[SAP Integration Suite / CPI]
    CC[SAP Cloud Connector]
  end

  ABAP <-->|RFC/SNC| ABAP2[Other SAP Systems]
  APIM <-->|OAuth2/mTLS| ICM
  CPI <-->|TLS/OAuth2| APIM
  CC <-->|Outbound TLS| BTP[BTP Subaccounts]
  
  subgraph SECOPS[Security Operations]
    SIEM[SIEM/UEBA]
    PAM[PAM Vault + JIT + Session Record]
  end

  ABAP -->|Audit/Change/ICM logs| SIEM
  HDB -->|Audit| SIEM
  PAM --> ABAP
  PAM --> HDB

Design intent: authenticate centrally; minimize direct inbound paths; isolate tiers; funnel web traffic through Web Dispatcher + WAF; treat integrations as first-class identities.

1) Identity and SSO (enterprise IAM as the control plane)

Web/Fiori: SAML2 or OIDC with conditional access

• Standard pattern: Enterprise IdP ↔ (optional bridge) SAP Cloud Identity Services (IAS) ↔ SAP systems.
• Enforce: MFA, device compliance, geo-risk policies, step-up for sensitive apps.

Implementation anchors:

• IAS/IPS capabilities: Identity Authentication (IAS) and Provisioning (IPS) overview

Advanced practice (often missed): immutable identity mapping

• Define a single enterprise identifier (e.g., employeeUUID) and map consistently:
  • IdP claim → IAS attribute → ABAP USR21-BNAME strategy or SU01 mapping for logon IDs
• Enforce uniqueness across on-prem + BTP + SAP SaaS to prevent “shadow admin” identities.

SAP GUI & RFC: SNC (Kerberos or X.509)

Goal: reduce password-based GUI logons and harden RFC.

ABAP profile signals (example; validate per release):

# Enforce stronger session hygiene (examples – tune to your ops model)
login/min_password_lng = 14
login/password_expiration_time = 90
rdisp/gui_auto_logout = 900

# SNC (conceptual—implementation varies by SNC product)
snc/enable = 1
snc/accept_insecure_gui = 0
snc/accept_insecure_rfc = 0

Use vendor SNC libraries (SAP Cryptographic Library/CommonCryptoLib) aligned to your kernel level; apply crypto library updates as part of your patch cadence. See component guidance under SAP NetWeaver AS ABAP.

2) Certificate, TLS, and key management (STRUST + standardized PKI)

STRUST: operationalizing PSE lifecycle (cutting-edge: “certificate SRE” approach)

Most SAP programs treat certificates as a one-off. A mature architecture manages certs like code:

• Standard naming: PSE_<SID>_<ENV>_<PURPOSE>
• Short-lived certs where feasible (90–180 days)
• Automated renewal pipeline (PKI → CSR → deployment → post-checks)
• Alerting for expiry, chain changes, weak signatures

Generate/maintain PSE via sapgenpse (example pattern):

# Create a new PSE (example)
sapgenpse gen_pse -p SAPSSL.pse -x 'changeit' -r SAPSSL.req \
  "CN=wd.example.com, OU=SAP, O=ExampleCorp, C=US"

# Import signed certificate chain
sapgenpse import_own_cert -p SAPSSL.pse -x 'changeit' \
  -c wd_signed.crt -r root_ca.crt -r issuing_ca.crt

Then import into ABAP via STRUST for the relevant PSE (e.g., SSL Server Standard).

Web Dispatcher TLS posture

• Terminate or bridge TLS; prefer TLS 1.2+ (TLS 1.3 where supported in your stack level).
• Disable legacy ciphers; enforce strong suites aligned with enterprise cryptographic standard.

Reference: SAP Web Dispatcher configuration and security

3) ABAP authorization architecture (least privilege that survives reality)

Role engineering: “productized authorization design”

Key design decisions

• Roles are built from business capabilities (not org chart).
• Separate:
  • End-user business roles (stable)
  • Power/privileged roles (rare, PAM-controlled)
  • Technical communication roles (interface-scoped, monitored)

SU24 governance (high leverage)

• Treat SU24 as controlled configuration; changes must be reviewed because they influence role generation and can silently broaden access after upgrades.

Toxic combination prevention

• Implement SoD (e.g., vendor creation + payment execution) via SAP GRC AC or SAP IAG (or equivalent governance). Use SAP as enforcement and GRC/IAG as workflow + analytics.

Authoritative anchor for ABAP authorization concepts: AS ABAP authorization and user administration

Fiori authorization: stop treating “tile visible” as “access granted”

A secure Fiori model requires three aligned layers:

1. Launchpad content (catalogs/spaces/pages): what users can see
2. OData/ICF service enablement: what endpoints exist
3. Backend authorizations: what actions can execute

Advanced control: build an “OData service allowlist” per business domain and enforce:

• only required services activated in /IWFND/MAINT_SERVICE
• service users are minimized; prefer principal propagation where audit requires it

References:

• S/4HANA and Fiori security topics: SAP S/4HANA security

4) Secure integration patterns (where SAP estates usually fail)

RFC hardening (SAP-to-SAP)

Rules that materially reduce risk:

• No shared generic RFC users across landscapes
• No broad “trusted RFC” unless there is a documented business requirement and compensating monitoring
• Tight authorizations for RFC users (function/module- and object-scoped)
• SNC for RFC where feasible; otherwise enforce TLS and strong secrets rotation via PAM

API-first integrations (HTTP/OData/event): OAuth2 + scopes + gateway

Put an API gateway in front of SAP APIs where possible:

• Enforce OAuth2/OIDC scopes, throttling, schema validation
• Centralize token lifetime, rotation, anomaly detection
• Require mTLS for B2B high-risk channels

ABAP outbound HTTP client with TLS (conceptual snippet):

DATA: lo_http TYPE REF TO if_http_client.

cl_http_client=>create_by_url(
  EXPORTING
    url                = '
  IMPORTING
    client             = lo_http
).

lo_http->request->set_method( 'POST' ).
lo_http->request->set_header_field( name = 'Content-Type' value = 'application/json' ).
lo_http->request->set_cdata( '{"orderId":"12345"}' ).

" TLS validation depends on STRUST-maintained PSE and certificate chain
lo_http->send( ).
lo_http->receive( ).

WRITE: / lo_http->response->get_status( ).

Operational requirement: ensure the outbound TLS trust chain is maintained in STRUST, and block “trust all” anti-patterns.

BTP connectivity: Cloud Connector as a controlled choke point

Use Cloud Connector to keep inbound closed and control exposure by:

• explicit resource allowlisting
• least-privilege principal propagation mappings
• separate subaccounts per environment; separate runtime identities per subaccount

Reference: SAP Cloud Connector – configuration and security

5) Hardening baselines (ABAP, HANA, Web Dispatcher) + drift control

ABAP hardening (repeatable baseline)

Baseline includes:

• password policy (even with federation)
• session timeouts, failed logon lockouts
• disable unused ICF services
• restrict sensitive transactions (role maintenance, transports, debugging) to controlled admin roles
• strict client strategy (no uncontrolled client copies; SCC4 locked down)

ABAP security guidance anchor: SAP NetWeaver AS ABAP Security

HANA hardening + audit (HANA 2.0 SPSxx)

HANA audit should be enabled and forwarded to SIEM.

Example: enable auditing + create audit policy (illustrative SQL)

-- Enable auditing (requires proper privileges)
ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('auditing configuration', 'global_auditing_state') = 'true' WITH RECONFIGURE;

-- Example policy: audit user changes and privilege grants
CREATE AUDIT POLICY "AUDIT_USER_PRIV_CHANGES"
AUDITING ALL
FOR CREATE USER, DROP USER, ALTER USER, GRANT PRIVILEGE, REVOKE PRIVILEGE
LEVEL INFO
TRAIL TYPE SYSLOG;

Reference: SAP HANA Platform Security

Web Dispatcher hardening (DMZ posture)

Example (representative) Web Dispatcher profile controls

# Enforce HTTPS and disable weak protocols per your supported stack
icm/server_port_0 = PROT=HTTPS,PORT=443,TIMEOUT=600,PROCTIMEOUT=600

# Canonical host handling (avoid host header ambiguity)
icm/host_name_full = webdisp-prd.example.com

# Limit exposure; route only required backends
wdisp/system_0 = SID=PRD, MSHOST=msg-prd.example.com, MSPORT=3601, GROUP=PUBLIC

Reference: SAP Web Dispatcher

Cutting-edge improvement: treat Web Dispatcher as internet-grade even for intranet:

• WAF rules for OWASP Top 10
• strict headers, method restrictions
• anomaly detection on request paths for OData enumeration

6) Privileged access (PAM + emergency access) as a first-class architecture layer

Architecture goals

• Named admin accounts only
• No standing “superuser” for humans; use JIT elevation
• Vault + rotate secrets for technical users (RFC, CPI, background users, DB accounts)
• Session recording for PRD administrative actions

Emergency access (“Firefighter”) should be:

• ticket-bound
• time-boxed
• logged and reviewed
• SoD-checked after the fact

Security operations tie-in: any emergency access event should generate SIEM incidents with mandatory review.

7) Logging, audit, and detection engineering (SAP-aware SIEM)

Must-forward logs

• ABAP Security Audit Log (SM19/SM20)
• User/role change evidence (role assignments, SU01 changes)
• Transport/import logs (to correlate “change → behavior”)
• ICM/HTTP access logs (Fiori/OData)
• HANA audit/auth events
• OS logs (privileged commands, service changes)

Detection use-case pack (high signal in SAP)

• Privileged role assigned outside approved workflow
• New RFC destination created/changed + immediate spike in RFC calls
• Activation of new SICF/ICF service in PRD
• Multiple failed logons from new geo/device + successful logon
• Background job created that calls sensitive function modules
• Changes to security-relevant profile parameters

Patch governance anchor: SAP Security Notes and News

Advanced Scenarios (≈500–600 words)

1) “Zero Trust for SAP” without breaking SAP

Problem: SAP estates historically relied on “internal network = trusted.” Modern attacks and hybrid work break that assumption.

Pattern

• Identity-driven access: conditional access, MFA, device posture
• Micro-segmentation: isolate app servers, DB, integration components; deny lateral movement
• Explicit allowlists for east-west traffic (RFC, SQL, HTTP)
• Prefer mTLS/OAuth2 over network location assumptions

Practical nuance: some SAP protocols are chatty and sensitive to latency. Implement segmentation with:

• deterministic rules (no dynamic “any-any”)
• tested maintenance windows
• performance baselines (RFC latency, dialog response time, enqueue contention)

2) Principal propagation: when to insist, when to avoid

Use principal propagation when:

• financial/regulatory traceability requires the human identity across systems
• audit/legal requires per-user accountability end-to-end

Avoid principal propagation when:

• integration is purely system-to-system and business context can be logged in payload with integrity controls
• legacy endpoints can’t securely validate propagated identities

Hybrid strategy (recommended)

• Use technical identities with strong controls + include immutable business identifiers in payload
• For high-risk processes, propagate principal and enforce scope-based authorization at the API gateway

3) RISE with SAP / hyperscaler operating model: shared responsibility security architecture

In RISE and managed-cloud models, the key architectural shift is control ownership clarity:

• What SAP/hyperscaler patches vs what you patch
• Who controls network, WAF, TLS termination
• How logs are exported to your SIEM
• How emergency access works with provider operations

Tie your architecture to explicit RACI and validate evidence flows for audit.

4) Policy-as-code for SAP BTP (advanced governance)

Treat BTP subaccounts like cloud infrastructure:

• Separate subaccounts per environment (DEV/QAS/PRD)
• Restrict who can create service instances / bindings
• Control entitlements and role collections via code + review

BTP governance anchor: SAP BTP documentation

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

Case 1 — Global manufacturer: ransomware resilience + SAP containment

A manufacturer with SAP S/4HANA 2021 and HANA 2.0 SPS05 experienced credential theft on a Windows admin workstation. SAP production impact was prevented because:

• SAP admins had named accounts and required PAM JIT for privileged actions.
• HANA and ABAP tiers were micro-segmented, preventing lateral movement from app to DB.
• Web traffic was forced through Web Dispatcher + WAF; direct ICM access was blocked.
• SIEM detections alerted on anomalous RFC usage spikes tied to a technical user.

Lesson learned: segmentation and PAM stopped a “generic IT incident” from becoming an ERP integrity incident.

Case 2 — Retailer: Fiori/OData exposure and service sprawl

A retailer accelerating Fiori rollout enabled dozens of OData services “just in case,” causing uncontrolled exposure. Remediation included:

• OData service allowlist with ownership per business domain
• Monthly review of SICF activations in PRD
• Gateway throttling + OAuth scopes at the API gateway
• A standardized troubleshooting playbook (SU53 + ST01 + service authorization)

Lesson learned: Fiori authorization is a 3-layer model; visibility is not authorization.

Case 3 — Financial services: SoD modernization + emergency access replacement

A bank reduced “SAP_ALL culture” by:

• implementing SoD analytics and access request workflows
• replacing standing admin access with Firefighter sessions (ticketed, recorded)
• building a “privileged role library” with narrow, task-based admin bundles

Lesson learned: executive sponsorship matters, but success required operationally frictionless emergency access.

Strategic Recommendations (≈200–300 words)

A pragmatic 90–180 day roadmap

1. Stabilize identity

   • Federate SSO for web and (where feasible) GUI; enforce MFA and conditional access.
   • Implement immutable identity mapping across on-prem + BTP + SAP SaaS.

2. Shrink the blast radius

   • Enforce network segmentation across app/DB/integration zones.
   • Funnel inbound web through Web Dispatcher (DMZ) + WAF; block direct internal ports.

3. Fix the biggest SAP-specific risks

   • Role redesign waves targeting privileged access, table access, debugging, transports.
   • Interface identity governance: inventory, vault, rotate, monitor.
   • Disable unused ICF services; govern OData activation.

4. Operationalize security

   • Monthly SAP Security Notes cycle with SLAs and exception governance.
   • SIEM detections engineered for SAP abuse patterns; establish incident playbooks.
   • Configuration drift checks for ABAP/HANA/Web Dispatcher and baseline enforcement.

Anchors: SAP Security Notes and News, SAP PSRT

Resources & Next Steps (≈150 words)

Canonical SAP documentation to ground your architecture

• ABAP security and authorization: SAP NetWeaver AS ABAP
• HANA security and auditing: SAP HANA Platform
• Reverse proxy entry point: SAP Web Dispatcher
• Hybrid connectivity controls: SAP Cloud Connector
• Hybrid identity bridge: SAP Cloud Identity Services (IAS/IPS)
• Patch cadence: SAP Security Notes and News

Action items for technical leaders

• Publish one reference security architecture and enforce it via design reviews.
• Build an SAP-focused detection backlog with log onboarding and correlation rules.
• Stand up an “integration identity governance” program (ownership, vaulting, rotation, monitoring).
• Treat authorizations as a product: versioning, metrics, stewardship, and continuous improvement.