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 has shifted from “protect the SAP box” to designing a federated, continuously verified security fabric spanning ABAP, HANA, SAP BTP, and SaaS. The highest-value pattern in 2026 is a single enterprise Identity Provider (IdP) (e.g., Microsoft Entra ID / Okta / Ping) federated to SAP targets—often via SAP Cloud Identity Services (IAS/IPS)—with MFA + conditional access enforced centrally. On the SAP side, mature programs combine least-privilege role engineering (ABAP PFCG + Fiori catalogs/spaces/pages), SoD controls (GRC Access Control / SAP Cloud IAG), hardened trust boundaries (WAF/reverse proxy → Web Dispatcher → app zone → DB zone), and secure operations (Security Notes SLAs, configuration baselines, evidence-grade logging to SIEM).

Key recommendations:

1. Standardize on SAML 2.0 for browser SSO and OAuth2/OIDC for APIs, reduce “special-case SSO.”
2. Treat trust relationships (SAML, RFC trust, certificates, Cloud Connector mappings) as Tier-0 assets with inventory + attestation.
3. Build SAP-specific detections (SM20/HANA audit/ICM logs) before “log everything.”

Technical Foundation (≈400–500 words)

1) Threat model: what actually breaks in SAP landscapes

In modern SAP programs (S/4HANA 2023 on-prem/RISE, BW/4HANA, SAP BTP Cloud Foundry, and SaaS like SuccessFactors/Ariba), the most common compromise paths are:

• Over-permissive identities: SAP_ALL creep, broad wildcards (*) in authorization objects, shared technical users.
• Broken trust: unreviewed SAML trusts, “temporary” RFC trusted systems, stale certificates, Cloud Connector overexposure.
• Web/API exposure: Fiori/Gateway OData services activated by accident; insufficient edge controls; token misuse in integrations.
• Patch/config drift: delayed Security Notes; inconsistent kernel/ICM TLS posture; insecure profile parameters.

A security architecture must therefore define (a) identity, (b) authorization, (c) network & platform controls, and (d) operations as one coherent system.

2) Canonical control plane: Identity + Federation + Provisioning

A high-performing baseline is:

• Enterprise IdP as authentication authority (MFA, conditional access).
• SAP Cloud Identity Services:
  • IAS as federation hub / authentication proxy for SAP apps (and a bridge for some SAP SaaS trust patterns).
  • IPS for provisioning from HR/IGA into ABAP/BTP/SaaS targets.

SAP reference documentation:

• SAP Cloud Identity Services overview: SAP Cloud Identity Services (Help Portal)

3) SAP enforcement layers (defense-in-depth)

• Edge: WAF / reverse proxy + SAP Web Dispatcher (DMZ), strict TLS posture and routing.
  Web Dispatcher guidance: SAP Web Dispatcher (Help Portal)
• Application: ABAP authorization objects + PFCG roles; Fiori catalogs/spaces/pages; Gateway/OData scoping.
• Database: SAP HANA 2.0 SPS07+ encryption and audit, least privilege and tenant isolation.
  HANA security: SAP HANA Security Guide (Help Portal)
• Operations: Security Notes, configuration compliance, logging & SIEM.

4) Minimal reference architecture (hybrid “default”)

flowchart LR
  U[User Device] -->|HTTPS| WAF[WAF/Reverse Proxy]
  WAF --> WD[SAP Web Dispatcher<br/>DMZ]
  WD --> FES[Fiori FE / Gateway<br/>App Zone]
  FES --> BES[S/4HANA ABAP<br/>App Zone]
  BES --> HANA[(SAP HANA<br/>DB Zone)]

  U -->|SAML/OIDC| IdP[Enterprise IdP<br/>MFA/Conditional Access]
  IdP <-->|Federation| IAS[SAP IAS]
  IAS -->|Trust| BTP[SAP BTP Subaccount]

  IGA[IGA/IAG] --> IPS[SAP IPS]
  IPS --> BES
  IPS --> BTP

Implementation Deep Dive (≈800–1000 words)

1) Identity & SSO: a pragmatic standardization pattern

1.1 Choose your “center of gravity”

Recommended in most enterprises:
Enterprise IdP → IAS (optional proxy) → SAP targets

• IdP enforces MFA/conditional access.
• IAS simplifies trust routing for SAP cloud properties and BTP.

Rule: every “extra” authentication method becomes a long-term exception you will pay for in incident response and audits.

1.2 ABAP SAML2 setup (S/4HANA 2023 / AS ABAP 7.50+)

On the ABAP system (Service Provider role):

• Use transaction SAML2 to configure the Local Provider, import IdP metadata, and define NameID/user mapping.
• Prefer stable identifiers (employeeID/userPrincipalName) over email aliases.

Official guidance:

• Configuring SAML 2.0 in AS ABAP (Help Portal)

Hardening tips that are often missed

• Enforce signed assertions and signed response (where supported).
• Limit accepted audiences and recipient URLs to the exact Web Dispatcher hostnames.
• Set strict clock skew; fix NTP across DMZ/app/IdP nodes.

1.3 Kerberos/SNC for SAP GUI and RFC (where it still matters)

If you have SAP GUI-heavy operations or sensitive RFC, SNC remains a high-assurance layer.

• Use Kerberos (SPNEGO) or X.509-backed SNC via a supported SNC library.
• Document exactly which users/groups are eligible for SNC to reduce “silent downgrade” to password logons.

Reference:

• Secure Network Communications (SNC) (Help Portal)

2) Authorization engineering: ABAP + Fiori without role entropy

2.1 Treat SU24 as a control, not a convenience

SU24 proposals are the only scalable way to keep roles tight while staying maintainable through upgrades.

Field pattern

• Maintain SU24 during build waves (per app/process).
• Enforce a policy: no wildcard authorizations without explicit risk acceptance and owner sign-off.

2.2 ABAP authorization check (developer-facing example)

Use explicit checks, and log failures meaningfully.

DATA: lv_bukrs TYPE bukrs VALUE '1000'.

AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'
  ID 'BUKRS' FIELD lv_bukrs
  ID 'ACTVT' FIELD '03'. "Display

IF sy-subrc <> 0.
  " Optional: raise application log / security event
  MESSAGE e398(00) WITH 'Not authorized for company code' lv_bukrs.
ENDIF.

Architectural note: Security architecture should include secure ABAP development standards and periodic scans for missing AUTHORITY-CHECK on sensitive custom transactions.

2.3 Fiori role model (S/4HANA 2022/2023)

Use business roles built from:

• Catalogs (apps)
• Spaces/pages (UX layout)
• Backend authorizations for OData + business objects

Avoid “mega catalogs” and unmanaged group sprawl.

Reference:

• SAP Fiori Launchpad on ABAP Platform (Help Portal)

Hardening checklist (commonly skipped)

• Deactivate unused ICF services; treat new activations as change-controlled.
• Restrict OData services to necessary scopes; avoid blanket service enablement.

3) Edge and network security: Web Dispatcher done properly

3.1 DMZ routing and TLS posture (Web Dispatcher 7.89+)

A solid baseline:

• Internet/Partner → WAF/Reverse proxy → Web Dispatcher (DMZ) → App zone
• TLS 1.2 minimum, TLS 1.3 where policy allows and platform supports it.
• Strong cipher suites; disable legacy renegotiation and weak suites.

Illustrative Web Dispatcher profile snippets (adapt to your standards):

# Listen only on HTTPS
icm/server_port_0 = PROT=HTTPS,PORT=443,TIMEOUT=600,PROCTIMEOUT=600

# Enforce modern TLS (platform-dependent; validate in your release)
ssl/protocols = 1,2,3,4  # Example only; use your SAP-recommended mapping
ssl/ciphersuites = 135:PFS:HIGH::EC_P256:EC_HIGH

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

# Request limits (basic abuse resistance)
icm/HTTP/max_request_size_KB = 10240
icm/keep_alive_timeout = 10

Web Dispatcher documentation:

• SAP Web Dispatcher Configuration (Help Portal)

Advanced control: terminate TLS at WAF for inspection and re-encrypt to Web Dispatcher (or pass-through if regulated), but make the decision explicit and documented.

3.2 RFC attack surface reduction (Gateway ACLs)

For ABAP RFC Gateway:

• Maintain reginfo and secinfo strictly (deny-by-default where feasible).
• Monitor changes as security events.

Example reginfo (conceptual):

P TP=* HOST=appserver1.example.com ACCESS=*
P TP=/usr/sap/* HOST=appserver2.example.com ACCESS=*
D TP=* HOST=* ACCESS=*

Reference:

• RFC Gateway Security (Help Portal)

4) SAP HANA security: make DB controls enforceable (HANA 2.0 SPS07)

4.1 Least privilege + auditable admin

• Separate DBA break-glass from day-to-day admin.
• Use roles and analytic privileges; minimize direct catalog privileges.

Example (illustrative):

-- Create a technical role with minimal read access to a schema
CREATE ROLE Z_APP_READ_ONLY;
GRANT SELECT ON SCHEMA ZAPP TO Z_APP_READ_ONLY;

-- Assign to a technical user (service principal pattern)
GRANT Z_APP_READ_ONLY TO ZAPP_SVC_USER;

4.2 Encryption and audit as architecture, not “settings”

• Turn on encryption at rest (data + log + backup where required).
• Enable HANA auditing for privileged operations and sensitive object access.

Reference:

• SAP HANA Auditing (Help Portal)

5) Secure operations: make Security Notes and logging executable

5.1 Security Note intake-to-deploy (repeatable SLAs)

A mature process includes:

• Weekly triage + risk scoring
• Emergency lane for critical notes
• Environment parity (Dev/Test/Prod) to avoid “can’t patch because drift”

Official portal:

• SAP Security Notes and Updates (SAP Support Portal)

5.2 Logging: define detections first, then wire the sources

Key SAP sources:

• ABAP Security Audit Log (SM20)
• Change documents for user/role tables
• ICM/HTTP logs (Fiori/Gateway)
• HANA audit log

ABAP audit reference:

• Security Audit Log (Help Portal)

Minimum viable detections (start here)

• Privileged role assignment (PFCG) to dialog users
• User master changes (lock/unlock, password resets)
• RFC destination creation/changes
• Activation of new ICF services
• Excessive failed logons from a source IP or unusual geography (when available)

Advanced Scenarios (≈500–600 words)

1) API-first security: OAuth2, JWT validation, and principal propagation

1.1 Standard: OAuth2 for APIs, SAML for humans

• Humans: SAML2 (browser SSO)
• Systems: OAuth2 Client Credentials / JWT Bearer
• High-assurance system-to-system: mTLS + OAuth2 (defense-in-depth)

If you use SAP BTP:

• Centralize API exposure in SAP API Management (or enterprise gateway) for threat protection, schema validation, quotas, and token validation.

Reference:

• SAP API Management (Help Portal)

1.2 Token exchange pattern (advanced but extremely effective)

A common hard hybrid requirement:
User authenticates to BTP, calls an API that ultimately hits on-prem S/4 as the user (not as a shared technical user).

Pattern (conceptual):

1. User authenticates via IdP/IAS to BTP app (OIDC).
2. BTP service exchanges/obtains a token suitable for downstream.
3. On-prem component validates token and maps identity.

This is where many projects fail: they implement “SSO” but not end-to-end principal propagation.

Architectural control point: define which integrations must be end-user and which must be technical—then prove it with logs.

2) SAP BTP trust and authorization boundaries (Cloud Foundry)

In BTP Cloud Foundry:

• Treat each subaccount as a security boundary.
• Use separate subaccounts per environment (DEV/TEST/PROD) and per data classification where needed.
• Minimize role collections; map IdP groups to role collections with clear ownership.

Reference:

• SAP BTP Security (Help Portal)

3) Cloud Connector: reduce “accidental internal exposure”

SAP Cloud Connector is powerful—and commonly over-permissioned.

Controls that materially reduce risk:

• Whitelist the minimum internal hosts/paths (deny-by-default mindset).
• Separate connectors by environment; restrict who can administer connector mappings.
• Monitor connector config drift as a Tier-0 change.

Reference:

• SAP Cloud Connector (Help Portal)

4) ABAP surface reduction: UCON (where applicable) and service allowlisting

If your ABAP stack supports UCON (Unified Connectivity), use it to control RFC and external calls at a fine-grained level—especially valuable in integration-heavy estates where “everything talks to everything.”

Reference:

• Unified Connectivity (UCON) (Help Portal)

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

Case 1 — Global manufacturer: OT-adjacent S/4 with partner access

Landscape: S/4HANA 2023 on-prem, multiple plants, shop-floor integrations, vendor remote support.
Problem: Partner access was implemented with shared SAP*adjacent accounts and broad RFC exposure.
Architecture change:

• Implemented PAM with time-bound elevation and session control.
• Moved external access to a controlled entry: WAF → Web Dispatcher → Fiori; blocked direct app server reachability.
• Locked down RFC Gateway (reginfo/secinfo) and introduced an interface service-account standard (owner, rotation, auth method).

Outcome: reduced remote-access risk footprint and improved audit outcomes; the biggest win was not “new tooling,” but removing undocumented trust paths.

Case 2 — Financial services: hybrid BTP extensions with strict monitoring

Landscape: S/4HANA + BTP extension apps + enterprise SIEM.
Problem: The SIEM had data, but no SAP detections; investigations took days.
Architecture change:

• Defined 12 SAP detection stories (privileged role assignment, ICF activation, RFC destination changes, unusual logon patterns).
• Standardized identity: enterprise IdP with conditional access; IAS as federation hub.
• Implemented API gateway policies (OAuth validation, quotas) for BTP-exposed services.

Outcome: mean time to detect dropped materially; auditors accepted evidence packs generated from consistent, versioned logging sources.

Strategic Recommendations (≈200–300 words)

A phased roadmap that works in enterprises

First 90 days (stabilize and reduce blast radius)

• Create a trust inventory: SAML trusts, RFC trusted systems, certificates, Cloud Connector mappings.
• Enforce MFA + conditional access at the enterprise IdP for SAP access paths.
• Implement Security Notes SLAs and an emergency patch lane.
• Turn on/validate baseline logging (SM20, ICM, HANA audit) and forward to SIEM.

6 months (standardize and govern)

• Roll out a role engineering standard: SU24 governance, naming conventions, approval workflow, and SoD checks (GRC/IAG).
• Reduce entry points: Web Dispatcher as the consistent SAP HTTP ingress; retire direct app server exposure.
• Implement service-account governance (ownership, rotation, secrets vault, technical-user patterns).

12–18 months (optimize and modernize)

• API-first modernization: OAuth2 everywhere for integrations; eliminate password-based interfaces.
• Continuous control monitoring: drift detection for SAP profile parameters, Gateway ACLs, and connector mappings.
• Formalize incident response playbooks specific to SAP (forensic readiness, evidence, tabletop exercises).

Resources & Next Steps (≈150 words)

Priority SAP documentation to anchor your program

• Identity and federation: SAP Cloud Identity Services (Help Portal)
• ABAP SAML configuration: Configuring SAML 2.0 in AS ABAP (Help Portal)
• Web Dispatcher: SAP Web Dispatcher (Help Portal)
• HANA security: SAP HANA Security Guide (Help Portal)
• BTP security: SAP BTP Security (Help Portal)
• Cloud Connector: SAP Cloud Connector (Help Portal)
• Security Notes operations: SAP Security Notes and Updates (SAP Support Portal)

Immediate action items

1. Publish your SAP Security Reference Architecture (zones, entry points, identity flows).
2. Stand up a trust attestation cadence (quarterly) and a role recertification cadence (at least semi-annual).
3. Build 10–15 SAP-specific SIEM detections tied to real incident scenarios and audit controls.