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 “Basis hardening + roles.” Modern landscapes (S/4HANA 2022/2023, HANA 2.0 SPS06+, SAP BTP, RISE/hyperscalers) demand a layered security architecture that treats SAP as a Tier-0 identity-dependent platform: compromise of identity, RFC trust, or admin boundaries often cascades across the ERP estate.

Key findings:

• Centralize authentication using an enterprise IdP with MFA and conditional access; use SAP Cloud Identity Services (IAS/IPS) as the SAP federation/provisioning hub for cloud and hybrid scenarios (IAS docs, IPS docs).
• Authorization remains the primary operational risk: adopt Fiori-first business role engineering with strict backend discipline, SU24 governance, and SoD lifecycle controls.
• Secure interfaces as hostile-by-default: harden RFC/IDoc/API connectivity, constrain callable endpoints (UCON where possible), and move secrets into PAM with rotation.
• SOC visibility must be SAP-aware: forward SAP Security Audit Log + HANA audit + Web Dispatcher/ICM telemetry into SIEM with SAP-specific detections and response runbooks.

Technical Foundation (≈400–500 words)

1) Threat model: why SAP is different

SAP systems concentrate privilege density: a single dialog user, RFC user, or integration technical account can read/alter financials, master data, payroll, or manufacturing execution. Attack paths in real programs tend to cluster into:

• Identity compromise (phishing, token replay, weak break-glass governance)
• Authorization abuse (overbroad PFCG roles, table access, debug/change rights)
• Interface lateral movement (trusted RFC destinations, technical user sprawl)
• Exposure of web entry points (Fiori/OData/ICF services activated by default-by-convenience)
• Patch latency (Security Notes backlog + kernel/HANA drift)

2) Reference architecture: six security planes

Use this as the mental model and operating blueprint:

1. Identity plane
   Enterprise IdP (Entra ID/Okta/Ping) + SAP IAS federation hub for SAP apps; OIDC/SAML standardization; MFA + conditional access enforced centrally.
   SAP reference: SAP Cloud Identity Services.

2. Access governance plane
   IAG (cloud) or GRC Access Control (on-prem) drives joiner/mover/leaver, access requests, approvals, recertification, SoD, and emergency access.
   SAP references: SAP Identity Access Governance, SAP GRC Access Control.

3. Network & ingress plane
   DMZ design: WAF/reverse proxy → SAP Web Dispatcher → ABAP ICM. Deny-by-default segmentation and explicit exposure management.
   SAP reference: (Web Dispatcher within NetWeaver docs) SAP Web Dispatcher (SAP NetWeaver).

4. Application plane
   ABAP profile hardening, ICF/OData discipline, secure RFC, UCON whitelisting, Fiori catalog governance, STAUTHTRACE-based troubleshooting.

5. Data plane
   SAP HANA: least privilege, audit policies, encryption controls, admin separation, backup security.
   SAP reference: SAP HANA Security Guide.

6. Operations plane
   Security Notes cadence, vulnerability management, configuration compliance, SIEM integration, SAP-specific IR playbooks.
   SAP references: SAP Security Notes and Updates, SAP Security Patch Day overview.

3) Trust boundaries (diagram)

flowchart LR
  U[Users/Devices] -->|MFA + Conditional Access| IDP[Enterprise IdP]
  IDP -->|SAML/OIDC| IAS[IAS Federation Hub]
  IAS -->|SAML| FIORI[Fiori Launchpad / Web UIs]
  IAS -->|OIDC/JWT| BTP[SAP BTP Apps / APIs]

  Internet((Internet)) --> WAF[WAF / Reverse Proxy]
  WAF --> WD[SAP Web Dispatcher (DMZ)]
  WD --> ICM[ABAP ICM]
  ICM --> APP[AS ABAP (S/4HANA)]
  APP --> HANA[(SAP HANA)]

  IGA[IGA: IAG / GRC AC] -->|Provision + Governance| APP
  IPS[IPS] -->|Identity sync| APP
  APP -->|Audit + Logs| SIEM[SIEM/SOC]
  HANA -->|Audit| SIEM
  WD -->|Access logs| SIEM

Implementation Deep Dive (≈800–1000 words)

1) Identity plane: “Single enterprise IdP + SAP federation hub”

1.1 Standardize protocol usage

• SAML 2.0: browser SSO for Fiori and classic SAP web UIs.
• OIDC: modern apps (BTP, custom services) and API access patterns.
• X.509 / Kerberos: SNC for SAP GUI and constrained RFC scenarios.

SAP’s implementation details vary by stack; anchor your design on SAP’s official guidance:

• SAML 2.0 authentication on AS ABAP
• Secure Network Communications (SNC)
• SAP Cloud Identity Services — IAS

1.2 Decide your identity key strategy (non-obvious failure mode)

Most SAP programs stumble on user mapping drift. Make an explicit decision and document it:

Attribute	Recommended use	Why
Immutable employee/person ID	Preferred unique key	Survives email/UPN renames and M&A
Email/UPN	Good for login UX	Changes frequently; causes mapping breaks
SAP username (BNAME)	Keep stable	Avoids churn and audit confusion

Design pattern (pragmatic):

• Use enterprise immutable ID as the linking identifier (provisioning + mapping).
• Allow email/UPN as login identifier in IdP/IAS.
• In ABAP, keep BNAME stable; avoid encoding org structure into usernames.

1.3 IAS as proxy/hub: certificate & metadata rotation discipline

Treat SAML metadata like production certificates: rotate on a schedule, not during outages.

• Create an internal runbook: metadata refresh windows, backout plan, and validation checks (Fiori launchpad, OData call, logout flow).
• Ensure TLS and SAML certs are inventoried and monitored (expiry alerts at 60/30/7 days).

Operational control: enforce “no manual certificate installs” by using enterprise certificate lifecycle tooling where possible, but keep SAP-specific exceptions documented.

2) Access governance plane: provisioning + SoD + emergency access

2.1 Choose IGA control points

• IAG (cloud-first) for standardized workflows, access reviews, and SAP-delivered connectors where applicable: SAP IAG documentation.
• GRC Access Control (common in large on-prem estates) for mature SoD and firefighter patterns: SAP Access Control documentation.

Hard requirement (often missed): treat technical users (RFC, system, comm users, background users) as first-class identities in IGA:

• Named owner
• Justified purpose
• Expiry/review cadence
• Vaulted secret or certificate-based auth
• Monitoring use cases (unexpected source system, off-hours, volume spikes)

2.2 Emergency access: “break-glass without breaking audit”

Implement two layers:

1. Identity break-glass: local SAP user(s) not dependent on IdP/IAS (for IdP outage).
2. Privilege break-glass: firefighter/JIT elevation with approvals and session evidence.

Key controls:

• Store break-glass credentials in PAM with check-out, MFA, and session recording.
• Test quarterly (restore procedure + audit evidence extraction).

3) Ingress & network plane: DMZ + Web Dispatcher baseline

3.1 Reference ingress pattern

Internet → WAF/Reverse Proxy → SAP Web Dispatcher (DMZ) → ABAP ICM → Fiori/Gateway

Why Web Dispatcher still matters in 2025-era landscapes:

• SAP-aware routing, header handling, backend health checks, and controlled exposure in front of ICM.
• It becomes the choke point for SAP URL governance (what paths are reachable, with what headers and TLS posture).

SAP baseline reference: SAP NetWeaver documentation (Web Dispatcher)

3.2 Practical Web Dispatcher hardening (sample profile snippets)

These are representative; validate against your kernel/Web Dispatcher version and corporate crypto baseline.

# icm/server_port_0 = HTTPS listener
icm/server_port_0 = PROT=HTTPS,PORT=443,TIMEOUT=900,PROCTIMEOUT=600

# Enforce modern TLS configuration via SSL server PSE
ssl/server_pse = $(DIR_INSTANCE)/sec/SAPSSLS.pse

# Prefer re-encryption to backend when policy requires
wdisp/system_0 = SID=S4P, MSHOST=s4p-msg, MSPORT=3601, SSL=1

# Reduce information disclosure
icm/HTTP/show_server_header = FALSE

# Request size constraints (tune for your OData payloads)
icm/HTTP/max_request_size_KB = 10240

# Access logging (feed SIEM)
icm/HTTP/logging_0 = PREFIX=/usr/sap/WDP/D00/log/access_, LOGFORMAT=combined, MAXSIZEKB=102400

Advanced control (high value): adopt an exposure allowlist for internet-facing SAP paths (e.g., only /sap/bc/ui5_ui5/, /sap/bc/ui2/, required OData services), and actively deny everything else at WAF/proxy. This shrinks the “ICF surprise surface area” dramatically.

4) Application plane: ABAP + Fiori authorization engineering

4.1 Fiori authorization chain (where teams get it wrong)

A Fiori tile being visible is not authorization. Production-safe access requires:

1. User has business role with catalog/space/page
2. OData/ICF services are activated and reachable
3. Backend authorizations permit the underlying business object/action
4. Gateway/OData authorization checks are correctly enforced

SAP starting point for Fiori security: SAP Fiori documentation (SAP Help Portal)

4.2 ABAP least privilege: role design + SU24 governance

• Enforce a release discipline where SU24 proposals are reviewed during deployments, not after access incidents.
• Use traces to validate missing authorizations:
  • SU53 for last failure
  • STAUTHTRACE (preferred for deep analysis on modern releases)
  • ST01 (legacy but still useful)

4.3 Code-level guardrails (ABAP example)

Even with perfect roles, custom code must enforce authorization consistently.

"Example: protect a custom action with an authorization object
AUTHORITY-CHECK OBJECT 'Z_SALES_OP'
  ID 'VKORG' FIELD lv_vkorg
  ID 'ACTVT' FIELD '02'. "Change

IF sy-subrc <> 0.
  MESSAGE e001(zsec) WITH 'Not authorized for sales org' lv_vkorg.
ENDIF.

Advanced insight: treat “custom authorization objects” as part of your security architecture, not a dev artifact. Maintain:

• Naming standard (Z_*)
• Field-level semantics
• Test cases (positive/negative)
• SoD mapping where applicable

5) Interface & API security: secure RFC explicitly, not by network adjacency

5.1 RFC destination governance (minimum standard)

• Inventory all SM59 destinations and classify: business-critical, legacy, decommission candidate.
• Each destination must map to an owned technical identity with:
  • least-privilege PFCG role
  • credential lifecycle (vault + rotation)
  • expected source system allowlist (firewall + app checks)

Control you should adopt if available: Unified Connectivity (UCON) to constrain RFC-enabled function modules to explicit allowlists.
SAP reference: Unified Connectivity (UCON) on AS ABAP

5.2 OAuth2 for SAP-to-API (where feasible)

For modern integrations, move toward OAuth2 flows rather than static passwords. In SAP landscapes this typically means:

• API gateway (SAP API Management or enterprise equivalent)
• OAuth2 client credentials with scoped access
• Short-lived tokens, rotated secrets/certs

SAP BTP security building block reference: XSUAA service (SAP BTP)

6) Data plane: SAP HANA security baseline (HANA 2.0 SPS06+)

6.1 Enforce auditability and admin separation

SAP reference: SAP HANA Auditing

Example: create a minimal audit policy targeting high-risk events.

-- Create an audit policy for privilege/user/role changes
CREATE AUDIT POLICY "AUD_PRIVILEGE_CHANGES"
  AUDITING ALL
  FOR CREATE USER, DROP USER, ALTER USER,
      CREATE ROLE, DROP ROLE,
      GRANT PRIVILEGE, REVOKE PRIVILEGE,
      GRANT ROLE, REVOKE ROLE
  LEVEL INFO
  TRAIL TYPE SYSLOG;

ALTER AUDIT POLICY "AUD_PRIVILEGE_CHANGES" ENABLE;

Advanced insight: route HANA audit to a centralized facility (e.g., syslog) and forward to SIEM, but keep a local retention buffer for incident response when SIEM pipelines fail.

7) Operations plane: continuous security operations for SAP

7.1 Patch & Security Notes SLAs (make it measurable)

SAP’s monthly cadence is non-negotiable at scale. Build a tiered SLA:

• Internet-facing components (Web Dispatcher, ICM, Gateway): fastest patch window
• Core ABAP stack: regular monthly/quarterly
• HANA revisions: planned cadence with regression validation

SAP source of truth: SAP Security Notes and Updates

Track KPIs:

• % of “Hot News” notes applied within X days
• Median age of open Security Notes by system role (prod/dev)
• Kernel/HANA revision drift across landscape

7.2 SOC integration: SAP logs that matter

• ABAP Security Audit Log (logons, RFC, user/role changes): Security Audit Log (AS ABAP)
• HANA audit (privilege grants, role changes)
• Web Dispatcher/ICM access logs for exposed endpoints

Detection examples that work in practice:

• Privileged role assignment outside approved change window
• Repeated failed logons followed by success for privileged IDs
• RFC invocation from a new source system/client
• Sudden activation of multiple ICF services

Advanced Scenarios (≈500–600 words)

1) Zero Trust for SAP: what’s realistic vs aspirational

Classic ABAP authorization is RBAC-heavy, but you can still implement Zero Trust principles around it:

• Identity assurance: enforce MFA + conditional access at IdP/IAS for all interactive access (Fiori, admin portals).
  Reference: IAS configuration concepts

• Network segmentation: treat internal integration subnets as untrusted; allow only explicit flows (e.g., CPI → Web Dispatcher → specific OData).
  Practical win: fewer “shadow RFC” paths.

• Continuous verification: correlate SAP events with IdP risk signals (impossible travel, device compliance).
  Advanced approach: build a SOC enrichment pipeline that tags SAP events with IdP session/device posture for investigations.

2) Principal propagation in hybrid landscapes (reduce shared secrets)

Where supported, prefer user-context propagation instead of shared technical users:

• SAP BTP Connectivity via Cloud Connector can support principal propagation patterns depending on scenario and corporate identity setup.
  Reference: SAP Cloud Connector documentation

Architectural guardrail: do not propagate high privilege. Propagated identities should still be constrained by SAP roles and SoD controls.

3) “Exposure governance” for Fiori/OData (a cutting-edge operating model)

Most organizations secure Fiori at go-live, then slowly drift. The advanced model is to manage exposure like an API product:

• Maintain a service registry: each active ICF node and OData service has an owner, business justification, data classification, and approved consumers.
• Enforce default-off activation:
  • New service activation requires a ticket/approval + automated evidence capture (before/after snapshots).
• Implement an automated “exposure diff” report (daily/weekly) that alerts on:
  • newly activated services
  • changes in SICF activation states
  • new externally reachable paths through Web Dispatcher rules

This is rarely implemented, but when it is, it measurably reduces accidental exposure and speeds audits.

4) Crypto lifecycle & post-quantum readiness (start now with inventory)

Post-quantum isn’t an SAP-only project; the immediate action is cryptographic inventory:

• TLS endpoints: Web Dispatcher, ICM, SAProuter, API gateways
• SAML signing/encryption certs (IAS/IdP and ABAP)
• SNC libraries and certificate usage
• HANA TLS and internal service certs

Deliverable: a living “SAP crypto bill of materials” with owners and rotation schedules.

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

Case 1: Global manufacturing — stopping RFC lateral movement

A multi-plant manufacturer found that 60% of SM59 destinations used shared technical IDs with broad authorizations (including S_RFC* patterns). The remediation program:

• Built a technical identity registry (owner, purpose, system scope).
• Moved credentials into PAM with enforced rotation.
• Implemented UCON allowlists for critical inbound RFC modules (UCON docs).
• Added SIEM detections for “RFC from new source” and “unexpected function group usage.”

Outcome: measurable reduction in privileged RFC capability and fewer audit findings related to uncontrolled interfaces.

Case 2: Retail — hardening internet-facing Fiori at peak scale

A retailer running Fiori externally (partners) had periodic WAF blocks but limited SAP-layer visibility. They implemented:

• WAF → Web Dispatcher DMZ architecture with strict path allowlisting.
• Web Dispatcher/ICM access log forwarding to SIEM and correlation with SAP Security Audit Log (Security Audit Log).
• Controlled OData activation workflows with ownership metadata.

Outcome: fewer false positives during seasonal spikes, faster incident triage (clear request provenance), and a stable method to approve/deny new exposure requests.

Case 3: Financial services — identity-centered controls under RISE constraints

In a RISE-aligned model, infrastructure controls were partially shared/managed. The customer focused on what they fully controlled:

• Central IdP MFA + conditional access, IAS federation hub (IAS docs).
• GRC/IAG-driven provisioning, recertification, firefighter.
• SAP-specific SOC playbooks and strong audit evidence pipelines.

Outcome: improved audit posture without relying on deep infrastructure-level changes.

Strategic Recommendations (≈200–300 words)

1. Adopt the six-plane reference architecture as an enforceable standard
   Document required building blocks per system class (internal vs internet-facing; prod vs non-prod). Make deviations time-bound with risk acceptance.

2. Make identity and technical-user governance your fastest risk reducer
   Central IdP + MFA + IAS hub + IPS provisioning removes entire categories of weak authentication and orphaned access (IAS, IPS).

3. Treat exposure as a product: implement “exposure allowlisting” and service ownership
   This single shift prevents the most common SAP web hardening failures (ICF/OData drift).

4. Engineer authorizations, don’t accumulate them
   Run an explicit role engineering program during S/4/Fiori transitions: job-based roles, SU24 governance, minimized derived role usage, and SoD lifecycle embedded into change management.

5. Operationalize SAP security as continuous control monitoring
   Monthly Security Notes SLAs with dashboards; configuration drift detection; and SIEM detections tuned to SAP semantics. Use SAP’s Security Notes pipeline as a first-class operational process (SAP Security Notes and Updates).

Resources & Next Steps (≈150 words)

High-value official SAP documentation (anchor set)

• SAP Cloud Identity Services: Identity Authentication (IAS), Identity Provisioning (IPS)
• AS ABAP security: Security Audit Log, SAML 2.0 on AS ABAP, Secure Network Communications (SNC), UCON
• HANA: SAP HANA Security Guide, SAP HANA Auditing
• Security maintenance: SAP Security Notes and Updates

Immediate action plan (2 weeks)

• Publish identity key standard + break-glass model.
• Inventory: ICF/OData exposure, SM59 destinations, technical users.
• Start SAP log forwarding to SIEM with 5 SAP-specific detections and one tested IR playbook.