Enterprise Security Architecture for SAP Landscapes — Flagship Technical Guide (2026 Edition)

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

Executive Summary (≈150 words)

Enterprise SAP security in 2025–2026 is no longer “Basis hardening + roles + firewall.” Modern SAP landscapes are hybrid (S/4HANA + HANA + BTP + Integration Suite) and security failures most often occur at trust boundaries: identity federation gaps, over-privileged technical users, exposed ICF/OData services, and weak interface governance. The most resilient programs implement a federated identity plane (SAML/OIDC + MFA), a tiered network entry architecture (WAF/reverse proxy → Web Dispatcher → app tier → DB), and productized interface security (inventory, ownership, least-privilege technical users, UCON/RFC governance, API controls).

This guide delivers a practitioner-grade reference architecture and a set of build standards: role engineering methodology (SU24/PFCG), interface security standard, HANA audit + ABAP Security Audit Log baseline, and operational cadence for Security Notes, drift control, and incident response. The goal is simple: reduce blast radius, increase detection fidelity, and make audit evidence automatic.

Technical Foundation (≈400–500 words)

1) Threat model: what actually breaks in SAP landscapes

Across incident postmortems and hardening assessments, the highest-frequency pathways are:

• Identity fractures: local passwords persist “temporarily,” service accounts aren’t governed, MFA is inconsistent across entry points.
• Interface trust abuse: RFC technical users with broad authorizations, shared credentials, unmonitored destinations; HTTP endpoints left enabled in SICF/ICF.
• Authorization drift: roles accumulate noise because SU24 defaults weren’t curated; emergency fixes become permanent.
• Visibility gaps: logs exist but aren’t normalized into SIEM use-cases; changes to destinations/roles aren’t alerted.

2) Security architecture as layered control planes

A workable enterprise architecture uses six planes (each with explicit owners and evidence):

1. Identity & Access: IdP federation (SAML/OIDC), MFA, provisioning, access reviews, PAM/JIT.
2. Application: ABAP/Java/BTP secure configuration, service minimization (ICF/OData), secure coding and patching.
3. Platform & Database: HANA authN/Z, encryption, auditing, tenant isolation, OS hardening.
4. Network & Perimeter: zoning/DMZ, TLS termination strategy, egress control, admin isolation.
5. Monitoring & Response: audit logs → SIEM; detections tuned to SAP semantics; playbooks.
6. GRC: SoD, firefighter, change control, evidence retention.

3) Prerequisites and “non-negotiables”

Before optimizing, establish these foundations:

• Authoritative inventory (systems/clients, interfaces, technical users, certificates, external endpoints).
• One enterprise IdP strategy for SAP entry points (humans), with explicit exceptions for break-glass.
• Golden baselines: profile parameters, TLS/ciphers, audit settings, service exposure policies.
• An interface security program (ownership + lifecycle + credential governance), not a one-time cleanup.

4) SAP reference documentation anchors (you will use repeatedly)

• Cloud identity and federation patterns:
  • SAP Cloud Identity Services — Identity Authentication (IAS) documentation
  • SAP Cloud Identity Services — Identity Provisioning (IPS) documentation
• ABAP SAML / SSO foundations:
  • AS ABAP — SAML 2.0 support (Security)
• Front door component hardening:
  • SAP Web Dispatcher — Administration and Configuration
• HANA auditing and security:
  • SAP HANA Security Guide (Auditing, Auth, Encryption)
• Integration Suite security controls:
  • SAP Integration Suite — Security (Connectivity, OAuth, Certificates)

Implementation Deep Dive (≈800–1000 words)

Reference Architecture (hybrid) — trust boundaries first

flowchart LR
  U[Users / Admins] -->|SAML/OIDC + MFA| IDP[Enterprise IdP (Entra ID/ADFS)جه]
  IDP --> IAS[Optional: SAP IAS Proxy IdP]
  U -->|Admin via JIT/PAM| PAM[Bastion + PAM Vault + Session Recording]

  subgraph DMZ[DMZ / Edge Zone]
    WAF[WAF / Reverse Proxy]
    WD[SAP Web Dispatcher]
  end

  subgraph APP[App Zone]
    FES[Fiori FES / AS ABAP]
    ECC[ECC/S4 Backends]
    PO[PI/PO or Integration Runtime]
  end

  subgraph DATA[Data Zone]
    HDB[(SAP HANA 2.0 SPS06+)]
    HSR[HANA System Replication]
    BKP[Backup Targets (Encrypted)]
  end

  subgraph CLOUD[SAP BTP]
    BTP[BTP Subaccounts / CF/Kyma]
    IS[Integration Suite]
    IAS --> BTP
  end

  WAF --> WD --> FES --> ECC --> HDB
  ECC -->|RFC/HTTP(S) APIs| PO
  IS -->|OAuth2/mTLS| ECC
  HDB --> HSR --> BKP

  FES -->|Audit| SIEM[SIEM/SOAR]
  ECC -->|Security Audit Log| SIEM
  HDB -->|HANA Audit| SIEM
  WD -->|Access logs| SIEM
  IS -->|Security events| SIEM

Design intent: every arrow is an authenticated, authorized, encrypted, logged interaction—or it is forbidden by default.

Step 1 — Identity plane: “Central IdP + Federation Everywhere” (humans)

1.1 Choose a trust pattern (and stick to it)

Two workable enterprise patterns:

• Pattern A (recommended): Corporate IdP → IAS → SAP BTP + SAP apps
  IAS acts as a policy enforcement and trust normalization layer (especially valuable across multiple BTP subaccounts and mixed SAP apps).
  Reference: IAS configuration concepts (tenants, applications, conditional access integrations)

• Pattern B: Direct trust from Corporate IdP to each SAP target
  More brittle at scale; increases operational overhead and exception handling.

1.2 ABAP SAML2 configuration (practitioner notes)

On AS ABAP 7.50+ / S/4HANA 1909–2023+, SAML is configured via transaction SAML2 (local provider) and STRUST for TLS and signing.

Key implementation details that reduce future incidents:

• Use stable subject identifiers (e.g., immutable employee ID) rather than email where possible.
• Decide user mapping: NameID → ABAP user (SY-UNAME) mapping strategy; avoid multiple users mapping to same subject.
• Harden assertions: require signed assertions; prefer short session lifetime; define re-auth for privileged apps at IdP.

SAP documentation anchor: AS ABAP — SAML 2.0 authentication

Operational tip (often missed): document exactly where MFA is enforced (IdP policy) and how you treat non-browser flows (RFC/system-to-system) so auditors don’t force MFA onto batch users.

Step 2 — Network & perimeter: DMZ entry with Web Dispatcher (and fewer “exposed things”)

2.1 TLS termination strategy (WAF vs Web Dispatcher vs ICM)

A hardened enterprise approach:

• Internet: terminate at WAF, then re-encrypt to Web Dispatcher, then re-encrypt to ICM (yes, “TLS everywhere”).
• Keep internal trust minimal; DMZ is not trusted.

SAP Web Dispatcher reference: SAP Web Dispatcher documentation

2.2 Web Dispatcher config patterns (sample)

Typical parameters for HTTPS endpoints and secure routing (illustrative; align to your cipher policy and kernel/Web Dispatcher release such as 7.93/7.94):

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

# Enforce TLS and validate backend certs (when re-encrypting)
ssl/client_sni_enabled = TRUE
icm/HTTPS/verify_client = 0              # client cert optional unless doing mTLS
ssl/client_ciphersuites = 135:PFS:HIGH::EC_P256:EC_HIGH

# Reduce information leakage
icm/HTTP/server_header = FALSE
icm/HTTP/show_server_header = FALSE

# Route only intended systems/paths; deny-by-default via routing rules
wdisp/system_0 = SID=FES, MSHOST=message.server.local, MSPORT=3601, SRCSRV=*:443

Advanced control (high value): implement path allowlists for SAP services at the edge (WAF + Web Dispatcher routing), so /sap/bc/* isn’t broadly reachable unless explicitly required.

Step 3 — Authorization engineering: make roles your “real firewall”

3.1 Role design method (ABAP/PFCG) that scales

A proven enterprise model:

• Business role = composed role (job function)
• Derived roles = org unit restrictions (company code, plant, sales org)
• Technical roles = Basis/admin separated from business content
• Emergency roles = firefighter (time-bound + logged)

Naming standard (example):

• Z_BR_AP_CLERK (business role)
• Z_DR_AP_CLERK_BUKRS_1000 (derived role)
• Z_TECH_RFC_S4_SFDC_READONLY (technical interface role)

3.2 SU24 governance: reduce “authorization noise”

If SU24 defaults are wrong or ungoverned, your roles bloat and reviewers stop trusting role content.

Practitioner pattern:

• Establish a SU24 change board (yes, really).
• Any SU24 adjustment must be linked to a business process and tested.
• For high-risk objects, require explicit manual insertion (not auto-proposal).

Step 4 — Interface security standard: “interfaces as products” (RFC + HTTP + APIs)

4.1 Inventory and classify every interface

Minimum inventory fields:

• Protocol: RFC / HTTP(S) / SOAP / OData / IDoc / JDBC
• Authentication: SSO / OAuth2 / Basic / x.509 / SAP assertion
• Principal: end-user propagation vs technical user
• Data sensitivity: PII/finance/OT
• Owner + lifecycle (sunset date)

4.2 UCON for RFC exposure control (ABAP)

Where available, UCON allows you to reduce RFC attack surface by controlling which function modules are callable and by whom—especially useful in ECC/S/4 with legacy RFCs.

• Control goal: deny-by-default for sensitive RFCs and restrict remote-enabled modules.
• Implementation is typically done via UCON cockpit and scenario configuration.

Concept anchor: SAP NetWeaver AS ABAP Security — Connectivity and communication security

4.3 HTTP/OData: reduce ICF surface area aggressively

Most SAP systems accumulate enabled services over years.

Baseline:

• Disable unused SICF nodes.
• Restrict /sap/opu/odata* exposure to only what’s required.
• Enforce CSRF protections (don’t punch holes “for convenience”).
• Place OData behind edge controls (WAF rules + allowlists).

Gateway/OData concept anchor: SAP Gateway foundation (OData) documentation

Step 5 — Platform & database: HANA security and audit that’s SIEM-ready

5.1 HANA auditing (HANA 2.0 SPS06+)

Enable auditing for:

• User and role administration
• Privileged operations
• Sensitive schema/table reads (selectively—balance performance)

Documentation anchor: SAP HANA Security Guide — Auditing

Example (illustrative SQL):

-- Check auditing status
SELECT * FROM SYS.AUDIT_CONFIGURATION;

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

-- Create an audit policy for user/role changes
CREATE AUDIT POLICY AUD_USER_ADMIN
  FOR ALTER USER, CREATE USER, DROP USER, ALTER ROLE, CREATE ROLE, DROP ROLE
  LEVEL INFO
  TRAIL SYSLOG;
ALTER AUDIT POLICY AUD_USER_ADMIN ENABLE;

Cutting-edge insight: choose an audit trail that your SIEM can ingest with minimal parsing friction (e.g., SYSLOG forwarding). “We enabled auditing” is not evidence; normalized events with detections are.

5.2 HSR and backup channels are security boundaries

For HANA System Replication, treat replication links and backup targets as Tier-0:

• Encrypt replication traffic (where supported in your deployment pattern).
• Ensure backup storage is encrypted and access-controlled.
• Monitor for configuration drift on replication endpoints.

Step 6 — Logging baseline + SIEM detections (make it operational)

6.1 Minimum audit logging baseline (practical)

Layer	Log source	Minimum events	Purpose
ABAP	Security Audit Log	logon failures, user creation/lock/unlock, role/profile changes, RFC logons	insider + credential abuse
ABAP	ICM/ICF/Gateway logs	admin/service changes, unusual HTTP status spikes	web attack visibility
HANA	HANA audit	privileged actions, user/role changes, sensitive reads (targeted)	DB-level accountability
Edge	WAF/Web Dispatcher	allow/deny, bot/signature events, auth redirects anomalies	perimeter signal
BTP	IAS/IPS logs	admin changes, provisioning errors, auth anomalies	identity drift

ABAP Security Audit Log concept anchor: AS ABAP Security — Audit logging

6.2 High-value detections (SAP-specific, not generic)

• Privileged role assignment spike (e.g., multiple users granted SAP_ALL, SAP_NEW, or your defined admin composites).
• New RFC destination created/modified followed by first-time usage.
• Mass read pattern on sensitive tables (where feasible—HANA audit selectively, ABAP traces during investigation).
• ICF service activation in production outside change window.
• Suspicious technical user usage (interactive dialog logon for a comms user).

Step 7 — Patching and drift control: Security Notes as an engineering cadence

A mature SAP program treats patching as a pipeline:

• Monthly ingestion of Security Notes + kernel updates, with emergency lane.
• Pre-production validation with automated regression for critical business transactions.
• Drift monitoring against “golden” profile parameters and TLS/cert inventory.

Security Notes process anchor: SAP Security Notes and Updates (Support Portal guidance)

Advanced Scenarios (≈500–600 words)

A) Principal propagation without creating a compliance nightmare

Goal: preserve end-user identity across UI → middleware → backend for traceability and SoD.

Reality: many landscapes mix:

• Human SSO (SAML/OIDC) for Fiori/browser
• Technical users for system-to-system (RFC, CPI, legacy)

Advanced pattern: constrain where propagation is mandatory:

• Financial approvals, vendor master changes, payroll interfaces → prefer propagation.
• High-volume telemetry/replication → technical user acceptable with compensating controls.

For BTP-centric extensions, implement app-to-backend calls using OAuth2 with narrowly-scoped authorities. For example, in BTP XSUAA-driven apps, define scopes in xs-security.json and map to backend authorizations through a controlled mapping layer.

BTP security concept anchor: SAP BTP Security (Identity, Authorization, Trust)

B) “Zero Trust-ish” SAP: conditional access + step-up for privileged actions

A modern enterprise stance:

• All interactive access goes through IdP with MFA.
• Step-up (re-auth) for:
  • SAP admin launchpads
  • Emergency access workflows
  • Financial posting apps above thresholds

Novel implementation detail: use IdP authentication context (MFA claim) to drive routing:

• Standard apps allowed after normal MFA
• Admin apps require stronger context → enforced at IdP and verified via assertion properties

This is architecture, not a checkbox: you’re building tiered assurance into the user journey.

IAS anchor for auth policies: IAS — Authentication and Conditional Access concepts

C) Integration Suite hardening beyond “rotate a password”

Integration middleware becomes an identity broker and a high-value pivot point.

Hardening patterns:

• Separate dev/test/prod tenants (or subaccounts) and isolate credentials per environment.
• Store secrets in managed mechanisms; rotate automatically.
• Enforce API allowlists, throttling, and schema validation where available.

Documentation anchor: SAP Integration Suite — Security

D) SAP HANA multi-tenant (MDC): tenant isolation and audit boundaries

For MDC landscapes:

• Treat system DB as Tier-0: limit admins, log everything, and separate duties.
• Ensure tenant DB users/roles are not administered by broad shared accounts.
• Align HANA audit policy scope with tenant sensitivity (don’t drown in noise; target the crown jewels).

HANA MDC security anchor: SAP HANA Platform — Security guide

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

Case 1 — Global manufacturer: “RFC sprawl” cleanup prevented lateral movement

Context: ECC + BW + PI/PO + S/4HANA carve-in-progress; hundreds of RFC destinations, many using shared technical users with broad authorizations.

What changed:

• Built an interface inventory and assigned owners per business domain.
• Split shared RFC users into per-interface identities; implemented vault-managed credential rotation.
• Implemented UCON controls for sensitive remote-enabled functions and reduced callable surface.

Outcome: reduced high-privilege technical users by ~70%, eliminated shared passwords, and enabled meaningful monitoring (baseline per interface). Security team could finally alert on “first use” or “usage outside schedule.”

Case 2 — Retailer with internet-facing Fiori: WAF + allowlist routing avoided exposed-service incidents

Context: Fiori launchpad exposed for partners; periodic pen tests found stray enabled ICF services and broad /sap/bc/* reachability.

What changed:

• Implemented DMZ pattern: WAF → Web Dispatcher → FES.
• Added strict path allowlists in edge routing; disabled unused SICF services; hardened headers.
• Centralized certificate lifecycle monitoring (no more surprise expirations).

Outcome: pen test findings shifted from “exposed endpoints” to “expected residual risk,” and operations stabilized (fewer urgent cert renewals).

Case 3 — Regulated pharma: audit evidence became automatic

Context: GxP/SOX controls required proof of access governance, emergency access review, and change traceability.

What changed:

• Standardized role engineering and SU24 governance workflow.
• Enforced PAM for admin access and firefighter for emergency changes.
• Forwarded ABAP/HANA/edge logs to SIEM with SAP-specific detections.

Outcome: audit cycle time reduced materially because evidence was produced by design (logs + workflows), not assembled manually.

Strategic Recommendations (≈200–300 words)

A pragmatic 12-month roadmap (minimize disruption, maximize risk reduction)

0–60 days (stabilize the basics)

• Produce authoritative inventory: systems/clients, interfaces, technical users, certs, external endpoints.
• Pick your identity trust pattern (Corporate IdP ↔ IAS ↔ SAP) and document exceptions.
• Establish logging baseline: ABAP Security Audit Log + HANA audit + edge logs → SIEM.

60–180 days (shrink attack surface)

• DMZ entry standard: WAF/reverse proxy + Web Dispatcher; eliminate direct exposures.
• ICF/OData service minimization in production; implement allowlist routing.
• Interface security standard: per-interface technical users, vault rotation, usage monitoring.

180–365 days (industrialize governance)

• Role engineering factory: SU24 governance, naming standards, regression-tested role transport pipeline.
• JIT/PAM for admins; tighten break-glass procedures and test quarterly.
• Continuous controls monitoring: drift detection for profile params, destinations, security-relevant config.

Risk posture principle: prioritize controls that reduce blast radius and improve detection—SAP security succeeds when prevention and observability mature together.

Resources & Next Steps (≈150 words)

Official SAP documentation (starter set)

• SAP Cloud Identity Services — IAS and IPS
• AS ABAP Security — SAML 2.0 Authentication
• AS ABAP Security — Security Audit Log
• SAP HANA Security Guide
• SAP Web Dispatcher
• SAP Integration Suite — Security
• SAP Security Notes & Updates (process guidance)

Next actions (what I’d do next week)

1. Stand up a cross-functional “SAP trust boundaries” workshop (Identity, Basis, Network, GRC, App teams).
2. Create your interface inventory and pick the first 20 high-risk interfaces for remediation.
3. Implement SIEM detections for: privileged role assignment spikes, RFC destination changes, ICF activations, and suspicious technical user logons.