Enterprise Security Architecture for SAP Landscapes: Complete Technical Guide

Executive Summary (≈150 words)

Enterprise SAP security succeeds when it is treated as an architecture (repeatable patterns + operational control loops), not a collection of hardening checklists. The highest-impact attacks in SAP landscapes typically target the control plane: identity, roles, RFC trust, and interface endpoints—often without “exploiting” a CVE.

This guide proposes a layered reference architecture built around three non-negotiables:

1. Identity-first control plane: Central IdP + strong federation (SAML/OIDC), MFA/conditional access, lifecycle automation via provisioning, and minimized SAP-local passwords (interactive users).
2. Standardized entry points and trust boundaries: DMZ reverse proxy (SAP Web Dispatcher or enterprise proxy), strict allow-listing of services, controlled RFC gateways (reginfo/secinfo + UCON), and explicit east-west segmentation aligned to Zero Trust.
3. Continuous assurance: A disciplined SAP Security Note lifecycle, certificate/key management as a platform service, and SAP-aware telemetry into a SIEM with detections for role changes, firefighter usage, gateway rule changes, and suspicious data access.

The outcome: lower blast radius, fewer audit findings, and dramatically improved detection/response in hybrid SAP landscapes.

Technical Foundation (≈450–500 words)

1) Threat model: where SAP landscapes fail in practice

Modern SAP platforms (S/4HANA, NetWeaver AS ABAP/Java, HANA, Fiori/UI5, PI/PO, CPI, BTP) concentrate risk into a few choke points:

• Identity fragmentation (multiple IdPs, inconsistent MFA, SAP-local passwords) → persistent access even after HR offboarding.
• Authorization drift (overgrown PFCG roles, unmanaged SU24 proposals, weak SoD enforcement) → excessive privilege becomes “normal.”
• Interface sprawl (ICF services, OData, RFC, IDoc, trusted RFC) → untracked entry points and lateral movement.
• Certificate and key sprawl (TLS/SNC expiration, unknown owners, manual rotations) → outages and emergency insecure workarounds.
• Logging without detection (SAL enabled but not centralized/parsed) → incidents become forensic failures.

2) Security architecture principles (SAP-adapted)

• Verify explicitly: every inbound path terminates at a policy enforcement point (reverse proxy/WAF/API gateway), and every system-to-system call is authenticated and authorized with scoped permissions.
• Assume breach: isolate admin plane, segment application tiers, minimize trust (especially trusted RFC), and monitor control-plane changes.
• Least privilege everywhere: for humans (business + admin), for technical users, and for interfaces (function module allow-lists, OData scopes, destination restrictions).
• Instrument and prove: controls must produce evidence continuously (audit logs, access reviews, SoD checks, patch SLAs, privileged session records).

3) Layered reference model (control planes + data planes)

flowchart TB
  subgraph Identity_Trust[Identity & Trust Layer]
    IdP[Corporate IdP\n(MFA/Conditional Access)]
    IAS[SAP Cloud Identity Services - IAS]
    IPS[SAP Cloud Identity Services - IPS]
    PKI[Enterprise PKI / Key Mgmt]
  end

  subgraph Entry[Perimeter / Entry Layer]
    WAF[WAF / Bot & Threat Protection]
    WD[SAP Web Dispatcher\n(DMZ, TLS policy, URL allow-list)]
    APIM[API Mgmt / Gateway\n(OAuth2, mTLS, throttling)]
    SAProuter[SAProuter (support connectivity)]
  end

  subgraph App[Application Layer]
    ABAP[S/4HANA / AS ABAP\n(ICF, RFC, UCON, PFCG, SAL)]
    JAVA[AS Java / Portal\n(if present)]
    CPI[SAP Integration Suite (CPI)]
    BTP[BTP Apps/Services]
  end

  subgraph Data[Platform & Data Layer]
    HANA[SAP HANA\n(roles, audit, encryption)]
    OS[OS/VM/Container\n(hardening, EDR)]
  end

  subgraph Ops[Security Operations Layer]
    SIEM[SIEM/SOC\n(correlation + detections)]
    PAM[PAM\n(vault, JIT, session recording)]
    GRC[SAP GRC / SAP IAG\n(SoD + provisioning governance)]
  end

  IdP --> IAS --> ABAP
  IPS --> ABAP
  PKI --> WD
  WD --> ABAP
  WAF --> WD
  APIM --> CPI --> ABAP
  ABAP --> HANA
  ABAP --> SIEM
  HANA --> SIEM
  PAM --> ABAP
  GRC --> ABAP

4) Minimum prerequisites (by component)

• Federation and identity services: SAP Cloud Identity Services (IAS/IPS) documentation and configuration patterns should be treated as platform standards, not project artifacts (SAP Cloud Identity Services – Identity Authentication, SAP Cloud Identity Services – Identity Provisioning).
• Integration: adopt OAuth2/mTLS/API policies where feasible (SAP Integration Suite overview).
• Database: HANA encryption, auditing, and role separation are mandatory baselines (SAP HANA Platform documentation).

Implementation Deep Dive (≈900–1000 words)

1) Standardized inbound web access (Fiori/ICM) — “One way in”

Target state: Internet/intranet users never reach ABAP app servers directly. All HTTP(S) enters via a controlled reverse proxy tier (SAP Web Dispatcher or enterprise proxy), optionally fronted by WAF.

Key controls

• TLS policy standardization: terminate TLS in DMZ only if you re-encrypt to backend (no cleartext hops). Prefer end-to-end TLS.
• Service allow-listing: treat ICF activation as deployment; expose only required paths for Fiori launchpad and OData services.
• Header and method governance: enforce strict HTTP methods and security headers at proxy layer; block WebDAV/TRACE unless explicitly required.

Sample: Web Dispatcher “policy-as-config”

Adjust parameters to your release; validate supported cipher suites and TLS versions in your Web Dispatcher/SAPCRYPTOLIB level.

# TLS: terminate at Web Dispatcher (DMZ) and enforce HTTPS
icm/server_port_0 = PROT=HTTPS,PORT=443,TIMEOUT=900,PROCTIMEOUT=600
icm/HTTPS/verify_client = 0
icm/HTTPS/trust_client_with_issuer = 1

# Disable weak protocols (verify with your kernel/crypto lib)
ssl/ciphersuites = 135:PFS:HIGH::EC_P256:EC_HIGH
ssl/client_ciphersuites = 150:PFS:HIGH::EC_P256:EC_HIGH

# URL filtering / routing governance (conceptual)
wdisp/trace = 1

Reference: SAP’s Web Dispatcher is documented as the standard reverse proxy/routing component for ABAP HTTP entry; align with product documentation for your NetWeaver/S/4 release (SAP NetWeaver documentation landing).

ABAP-side hardening anchors

• Deactivate unused ICF nodes; document and review quarterly.
• For SAP Gateway/OData: restrict services to business need, and apply strict authorization checks.
• Enable and forward security-relevant logs (see logging section).

2) Centralized SSO with MFA — “Identity is the control plane”

Interactive access targets

• Browser (Fiori/UI5/WebGUI/BSP): use SAML 2.0 federation via corporate IdP, optionally brokered through IAS to unify SAP cloud and on-prem trust.
• SAP GUI: use SNC with Kerberos (preferred in AD environments) or X.509 certificates for strong auth on RFC/DIAG channels.

Why IAS/IPS often becomes the “SAP identity fabric”

• IAS provides SAP-native federation patterns and simplifies trust across SAP cloud properties and BTP subaccounts (Identity Authentication).
• IPS provides provisioning connectors and transformations for SAP targets and directories (Identity Provisioning).

Advanced (often missed) control: step-up authentication for sensitive SAP actions
Even if SAP GUI users authenticate with Kerberos, you can require MFA at the IdP for high-risk browser applications and for privileged workflows (e.g., GRC request approvals, admin launchpads). Architect this as policy, not app-specific exceptions.

3) Secure system-to-system integration — “Kill shared secrets, constrain blast radius”

3.1 API-first integrations (preferred)

For new integrations, standardize on:

• OAuth2/OIDC with scoped tokens
• mTLS for system identity (where appropriate)
• Central policy controls (rate limits, threat protection, schema validation)

Use SAP Integration Suite (CPI) and/or API Management as the mediation plane (SAP Integration Suite).

Advanced pattern: token exchange + principal propagation

• Use principal propagation only when required (audit/legal need to attribute actions to a real user) and when you can prove end-to-end integrity: token issuance, audience restriction, expiry, mapping, and logs.

3.2 Legacy RFC/IDoc integrations (still common)

If you must use RFC:

• Create one technical communication user per interface (no shared mega-users).
• Remove broad authorizations; grant only the specific function groups/BAPIs needed.
• Enforce gateway allow-lists (reginfo/secinfo) and enable UCON where possible to control remote-enabled function modules.

Sample: gateway reginfo allow-list concept

# Allow only approved application servers/clients to register
P TP=extprog HOST=10.10.20.15 ACCESS=10.10.0.0/16
P TP=SAPXPG  HOST=10.10.20.16 ACCESS=10.10.0.0/16

# Default deny
D TP=* HOST=* ACCESS=*

Sample: gateway secinfo allow-list concept

# Allow specific RFC program IDs to talk to allowed hosts/users
P USER=RFC_MES_001 HOST=10.20.30.40 TP=Z_MES_RFC*
D USER=* HOST=* TP=*

Architectural decision: Treat trusted RFC as a high-risk exception. If used, document:

• business justification,
• scope boundaries,
• monitoring requirements (destinations, caller systems),
• periodic recertification.

4) Authorization engineering (PFCG + CDS/DCL) — “Least privilege as a product”

Role model (recommended)

• Business role (job function) → Composite role(s) → Single roles
• Use derived roles for org levels (company code, plant, sales org) rather than copying roles.
• Maintain SU24 proposals in a controlled workflow to prevent drift and “trace-to-production” privilege creep.

Advanced control: data-level authorization with CDS DCL In S/4HANA, many “who can see which rows” requirements are best expressed at CDS level (and tested like code).

Example DCL (illustrative):

@EndUserText.label: 'Restrict Sales Orders by Sales Org'
define role ZR_SO_BY_VKORG {
  grant select on ZI_SalesOrder
    where VKORG = aspect pfcg_auth( 'V_VBAK_VKO', 'VKORG' );
}

Why this matters: it reduces dependence on application-layer filtering, and it creates a reviewable artifact that can be versioned and transported.

5) Privileged access isolation (PAM + admin plane)

Baseline pattern

• No shared admin accounts for humans.
• Enforce named admin IDs, with break-glass access via PAM (time-bound), and session recording.
• Use hardened jump hosts / privileged workstations.
• Monitor and alert on control-plane actions: user/role maintenance, RFC destination changes, gateway config edits, table display of sensitive tables.

Advanced (high leverage) detection: privilege change rate anomalies
Alert on:

• spikes in role assignments,
• assignment of high-risk profiles,
• emergency user activity outside change windows,
• new RFC destinations created/changed.

6) Logging, detection, and evidence automation

Logging sources to centralize

• ABAP Security Audit Log (SAL)
• ICM/Web Dispatcher access + error logs
• HANA audit logs
• OS/EDR telemetry and system logs
• Integration plane logs (CPI/API Mgmt)

HANA auditing and security are part of the platform’s standard capabilities (SAP HANA Platform documentation).

Operational guidance

• Normalize identity fields: SAP user, client, external subject (SAML NameID), source IP, transaction, RFC destination, service name.
• Build SAP-aware parsers and correlation rules in SIEM.

Example: HANA audit policy (illustrative SQL)

-- Enable auditing (validate syntax for your HANA revision)
ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM')
SET ('auditing configuration','global_auditing_state') = 'true' WITH RECONFIGURE;

-- Create an audit policy for critical actions
CREATE AUDIT POLICY AUDIT_CRITICAL_ACTIONS
  AUDITING ALL
  FOR ALTER SYSTEM, CREATE USER, DROP USER, GRANT, REVOKE
  LEVEL INFO
  TRAIL TYPE DATABASE;
ALTER AUDIT POLICY AUDIT_CRITICAL_ACTIONS ENABLE;

Advanced Scenarios (≈550–600 words)

1) Hybrid: BTP ↔ on-prem via Cloud Connector (least privilege by design)

Cloud Connector is frequently treated as “just a tunnel,” but architecturally it is a policy enforcement point. Key advanced controls:

• Expose only required virtual hosts/paths (not entire systems).
• Use distinct Connector instances per trust zone (e.g., finance vs manufacturing).
• Audit connector configuration changes and forward logs.

Reference for connectivity patterns and service exposure concepts: SAP BTP Connectivity documentation.

Common failure mode: broad exposure of /sap/opu/odata/* or unrestricted RFC resources to BTP subaccounts.
Fix: use path-based allow-lists + separate subaccounts per environment + strong identity mapping rules.

2) RISE / hyperscaler SAP: shared responsibility as an architectural artifact

In RISE/private cloud or hyperscaler IaaS, security responsibilities split across:

• SAP (some basis/infra operations depending on contract),
• Customer (identity, authorizations, integration, monitoring, many configuration controls),
• Hyperscaler (physical/underlay).

Advanced practice: maintain a Responsibility Assignment Matrix that maps:

• patch ownership (OS, DB, kernel, app),
• log access (where, retention, how exported),
• incident response hooks (who can isolate, who can revoke access, who holds keys).

Tie this to your audit evidence model: if you can’t retrieve logs or prove patch posture, you’ll fail both IR and compliance.

3) Certificate lifecycle as a platform service (avoid outages + insecure exceptions)

Root cause pattern: SAP landscapes accumulate cert endpoints (Web Dispatcher, ICM, SAProuter, CPI, IAS, SNC PSEs, STRUST), and owners are unclear.

Advanced control loop

• Inventory certificates (endpoint, purpose, owner, renewal method, expiration).
• Automate renewals where possible (ACME is not universally supported in classic SAP components; often you integrate enterprise PKI + scripted deployment).
• Enforce rotation windows and pre-expiry alerting in monitoring.

Architectural decision: separate trust stores for:

• public inbound TLS,
• internal service-to-service mTLS,
• SNC/SSO certificates,
• partner integrations.

4) DevSecOps for ABAP + extensions (often underbuilt)

Move beyond “periodic scans”:

• Gate transports with automated checks (ATC variants, secure coding checks, and regression authorization tests).
• Treat security config and roles as version-controlled artifacts (where tooling allows), with peer review and change traceability.
• For BTP extensions: include dependency scanning, SBOM generation, and secrets detection.

Developer entry points for SAP BTP security and app development practices can be anchored from official learning content (SAP Developers – SAP BTP Security (topic entry)---

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

Case Study 1 — Global manufacturing: IT/OT boundary with RFC-heavy plant integrations

Situation: Multiple plants running MES/SCADA integrations into central S/4HANA via RFC/IDoc. Outages occurred due to ad-hoc credential changes; security team found shared RFC users with broad privileges.

Architecture implemented

• Segmented plant networks with explicit allow-lists to SAP gateway.
• Replaced shared RFC accounts with per-interface communication users; credentials vaulted and rotated.
• Implemented gateway reginfo/secinfo default-deny, and introduced UCON governance for remote-enabled function modules.
• Deployed standardized DMZ entry with Web Dispatcher for all HTTP access; eliminated direct app server exposure.

Outcome

• Reduced lateral movement opportunities (explicit allow-listing).
• Measurably improved auditability: every interface had an owner, purpose, and bounded authorizations.
• Incident response improved because gateway denials and RFC errors were centrally logged and correlated.

Lesson: In OT-adjacent environments, availability requirements push teams toward insecure shortcuts; automated credential rotation + deterministic allow-lists preserve uptime and security.

Case Study 2 — Financial services: SoD + privileged access modernization

Situation: Strong SOX pressure, recurring audit findings for “excessive access,” and weak evidence for emergency access.

Architecture implemented

• Centralized SSO + MFA through corporate IdP, with IAS brokering for SAP cloud properties.
• Implemented PAM with time-bound elevation and session recording for Basis and security admins.
• Integrated access requests and SoD analysis using SAP governance tooling, and operationalized quarterly access reviews.
• Built SIEM detections for: mass role assignment, firefighter usage outside approved windows, and changes to RFC destinations.

Outcome

• Audit evidence shifted from manual screenshots to system logs + session records.
• Reduced privileged standing access; faster detection of policy violations.

Lesson: SoD is not “a GRC project”; it is an operational product requiring telemetry, workflow, and enforcement points.

Strategic Recommendations (≈250 words)

1. Standardize three “golden paths” first

• Inbound web: DMZ reverse proxy + strict allow-list + consistent TLS.
• Outbound/integration: API-first with OAuth2/mTLS; RFC only with bounded technical users + gateway/UCON controls.
• Admin access: PAM + jump hosts + named admins; monitor control-plane changes.

2. Modernize identity in phases (reduce SAP-local passwords)

• Phase 1: SAML for browser apps + MFA/conditional access at IdP; stabilize IAS/IPS patterns where needed.
• Phase 2: SNC/Kerberos for SAP GUI; restrict password logon to break-glass scenarios.
• Phase 3: automate joiner/mover/leaver provisioning and recertification.

3. Treat roles, CDS/DCL, and interface policies as governed artifacts

• Version, review, transport, and recertify.
• Implement regression testing for authorizations, not just functional testing.

4. Operationalize continuous assurance

• Monthly SAP Security Note process with risk triage, testing, deployment, and verification (especially HotNews). Use SAP’s official Security Notes and News entry points to anchor the program (SAP Security Notes and News).
• Centralize SAP-aware logs into SIEM with high-signal detections (privilege change anomalies, gateway config changes, emergency access).

Resources & Next Steps (≈150 words)

High-value official SAP documentation (start here)

• Identity & federation: SAP Cloud Identity Services – Identity Authentication
• Provisioning automation: SAP Cloud Identity Services – Identity Provisioning
• Integration security baseline: SAP Integration Suite
• HANA security and auditing foundations: SAP HANA Platform documentation
• Security patch governance: SAP Security Notes and News
• BTP connectivity controls: SAP BTP Connectivity

Immediate action items (2–4 weeks)

• Declare and publish your “golden paths” (inbound, integration, admin).
• Build a certificate inventory with owners and expiry alerting.
• Turn on SAP-specific SIEM detections for privilege changes, firefighter usage, and RFC/gateway configuration changes.

Appendix A — Control Objective Matrix (practitioner baseline)

Control Objective	SAP-Specific Control Mechanisms	Evidence/Telemetry (What auditors & SOC need)
Strong authN (users)	SAML/OIDC federation, SNC/Kerberos, MFA at IdP, conditional access	IdP sign-in logs + SAP logon events correlated by user/client
Least privilege (users)	PFCG role engineering, derived roles, SU24 governance, CDS/DCL where applicable	Role assignment logs, periodic access review evidence, auth trace samples
SoD (prevent/detect)	SAP GRC / SAP IAG workflows, risk analysis at request time, firefighter process	SoD rule set, violation reports, approvals, firefighter session logs
Secure inbound access	Web Dispatcher in DMZ, strict ICF activation, TLS standard	Proxy access logs, ICM logs, service allow-list documentation
Secure system-to-system	OAuth2/mTLS via Integration Suite/API Mgmt; RFC: bounded users + reginfo/secinfo + UCON	Destination change logs, gateway denials, interface inventory with owners
Data protection	HANA encryption/audit, key mgmt, authorization at row level (CDS/DCL)	HANA audit trails, key rotation records, sensitive data access detections
Change control	Transport governance, peer review for roles/policies, ATC/security checks gating	Change tickets linked to transports, ATC results, config drift reports
Vulnerability mgmt	SAP Security Notes monthly cadence + verification	Patch SLAs, note implementation logs, compensating controls for deferrals
Monitoring & IR	SAL + HANA + proxy logs → SIEM, SAP-specific playbooks	SIEM alerts, runbooks, incident timelines, containment actions

Appendix B — Operational Runbooks (minimum viable)

Runbook 1: SAP Security Notes lifecycle (monthly + HotNews fast lane)

1. Ingest new notes; triage by HotNews and system exposure.
2. Map to impacted components (ABAP, HANA, Web Dispatcher, Java, CPI).
3. Test in QAS with regression focus (auth + interfaces).
4. Deploy with verification steps (version checks, functional smoke tests).
5. Produce evidence (note list, implementation dates, exceptions with compensating controls).

Anchor program governance on SAP’s Security Notes and News guidance (SAP Security Notes and News).

Runbook 2: Certificate rotation (quarterly rehearsal)

• Inventory endpoints (STRUST PSEs, Web Dispatcher, SAProuter, CPI, IAS).
• Rotate in non-prod first; validate cipher/protocol compatibility.
• Deploy with rollback steps; verify chain/trust stores; update monitoring thresholds.

Runbook 3: Emergency access (“firefighter”) response

• Approval + time-boxing + PAM session recording.
• Post-activity review within 24–48 hours.
• SIEM correlation: emergency logon → critical T-codes → role/user changes → sensitive table reads.

Runbook 4: SAP-specific incident playbooks (high signal)

• Mass role assignments, new privileged roles, RFC destination changes, gateway rule changes, repeated failed logons, unusual remote function calls.
• Containment actions: disable user, revoke tokens, block destination, tighten gateway allow-list, isolate app server segment, rotate secrets in vault.