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 “Basis hardening + roles” to a multi-domain security architecture where identity, interfaces, and operations are the primary blast-radius multipliers. Modern landscapes (S/4HANA + Fiori + APIs + hybrid cloud) demand an explicit trust-boundary design: internet exposure must terminate in DMZ controls (WAF/reverse proxy + SAP Web Dispatcher), identity must be IdP-centric with MFA and conditional access, and east–west paths (RFC/HTTP/DB/admin) must be default-deny with protocol-aware allow lists.

Key recommendations:

1. Standardize a reference architecture with zoned segmentation + management plane isolation.
2. Treat SAP interfaces as products: build an interface catalog, classify by protocol and data sensitivity, and enforce consistent controls (TLS/mTLS, OAuth/SAML, SNC, gateway ACLs).
3. Operationalize monthly SAP Security Notes with tiered SLAs and drift monitoring.
4. Centralize SAP-relevant telemetry (ABAP Security Audit Log, ICM/Web Dispatcher, HANA audit) into SIEM with SAP-specific detections.
5. Reduce identity risk with IGA + SoD + privileged access management + audited emergency access.

Technical Foundation (≈400–500 words)

1) The security architecture problem SAP actually presents

SAP landscapes are not a single application; they are a federated system-of-systems: ABAP stacks, Fiori front ends, databases (HANA), integration protocols (RFC/IDoc/HTTP/OData), and a large operational surface (transports, batch jobs, background RFC, admin access). Security failures typically chain across domains:

• Identity (weak privileged controls or shared technical users)
• Interfaces (overexposed ICF/OData/RFC gateway; weak TLS/cert lifecycle)
• Operations (no SAP-aware monitoring, delayed patching, uncontrolled transports)

2) Canonical trust boundaries (what to make explicit)

A practitioner-grade enterprise security architecture should explicitly define the following boundaries:

1. User → IdP: primary authentication, MFA, conditional access
2. Browser/API client → Edge/DMZ: reverse proxy/WAF, rate limits, bot controls
3. DMZ → SAP Web Dispatcher/ICM: TLS/mTLS, strict URL routing, header sanitation
4. App tier → DB tier (HANA): isolated network, minimal inbound, audited admin endpoints
5. Admin plane → SAP/OS/DB: jump hosts + PAM, no direct admin from user subnets
6. Integration plane: separate runtime subnets, protocol allowlists, principal propagation where feasible

3) Security domains and where to anchor control ownership

• Identity & Access: IdP team + SAP security (authorizations, SoD, privileged access)
• Application: SAP Basis + SAP security (ICF, RFC gateway, SNC/TLS, parameters)
• Database: HANA team (audit, encryption, admin endpoint restrictions)
• Platform/OS/Cloud: infra security (hardening, EDR, patch, vulnerability mgmt)
• Network/Perimeter: network security (segmentation, WAF, inbound exposure)
• Operations: SOC + SAP operations (SIEM onboarding, IR playbooks, DR/backup)

4) Reference architecture baseline (zoned)

A “minimum viable secure” enterprise baseline remains zoned segmentation plus controlled exposure—enhanced by identity-centric policies and centralized detection.

flowchart LR
  Internet((Internet)) --> WAF[WAF / Reverse Proxy]
  WAF --> DMZWD[SAP Web Dispatcher (DMZ)]
  DMZWD --> ICM[ICM / SAP AS ABAP (App Zone)]
  ICM --> ABAP[ABAP App Servers]
  ABAP --> HANA[(SAP HANA DB Zone)]
  ABAP --> INT[Integration Runtime Zone\n(PI/PO, CPI, iPaaS)]
  Admin[Privileged Admins] --> PAM[PAM + Jump Hosts\n(Management Zone)]
  PAM --> ABAP
  PAM --> HANA
  ABAP --> SIEM[SIEM/SOC]
  HANA --> SIEM
  DMZWD --> SIEM

SAP documentation anchors for this foundation:

• Authentication and SSO mechanisms on AS ABAP, including SAML2 flows: SAP NetWeaver AS ABAP Security (Authentication/SSO)
• SAP HANA security capabilities (users/roles, auditing, encryption): SAP HANA Security Guide
• SAP Web Dispatcher security and TLS termination patterns: SAP Web Dispatcher Documentation

Implementation Deep Dive (≈800–1000 words)

1) Identity-centric access: SSO + MFA without weakening SAP authorization controls

Target state: IdP performs authentication (MFA/conditional access). SAP performs authorization (PFCG roles, org levels, SoD logic).

Pattern A — Fiori/HTTP via SAML2 or OIDC

• Use SAML 2.0 for classic NetWeaver / Fiori scenarios where your enterprise IdP is SAML-native.
• Use OIDC where SAP components natively support it or where API management validates JWTs upstream.

Implementation notes (ABAP SAML2, high-level):

1. Establish trust: IdP metadata ↔ SAP SP metadata
2. Enforce strong NameID mapping and immutable user identity (avoid email as primary key unless governed)
3. Require MFA at IdP; disable SAP password fallback for internet-facing paths

SAP anchor: SAML 2.0 in AS ABAP (Configuration/Concepts)

Operational hard rule: if SAML is enabled for a service, block alternative auth methods for the same endpoint at the reverse proxy (avoid “SSO bypass” via Basic/Forms).

Pattern B — SAP GUI/RFC via SNC (Kerberos/X.509)

SNC is the enterprise-grade control that’s often underutilized in 2025-era landscapes—yet it remains the most effective way to prevent credential replay and to enable strong auth for GUI/RFC.

Typical ABAP profile parameters (illustrative baseline):

snc/enable = 1
snc/gssapi_lib = /usr/sap/<SID>/SYS/exe/run/libsapcrypto.so
snc/identity/as = p:CN=<SID>, O=<ORG>, C=<CC>
snc/data_protection/use = 3   # 1=auth only, 2=integrity, 3=privacy
snc/accept_insecure_gui = 0
snc/accept_insecure_rfc = 0

SAP anchor: Secure Network Communications (SNC) on AS ABAP

Advanced technique (not commonly implemented well):
Use two-tier trust: Kerberos for workforce GUI, X.509 for system-to-system RFC where service principals and SPNs are hard to govern (e.g., third-party middleware). This reduces “everything is Kerberos” operational fragility.

2) Application attack-surface reduction: ICF, RFC, and “services as inventory”

A) ICF hardening (SICF)

• Disable unused services aggressively; many landscapes carry years of activated endpoints.
• Enforce consistent authentication methods per path (no mixed auth on sensitive endpoints).
• Apply URL routing and allow-listing at Web Dispatcher/reverse proxy so ABAP is not the policy decision point.

SAP anchor: Internet Communication Framework (ICF) on AS ABAP

Practical control: Maintain an “ICF baseline manifest” per product version (S/4HANA 2022/2023) and continuously detect drift (new activations).

B) RFC Gateway controls (reginfo/secinfo)

Gateway ACLs are still one of the highest leverage controls against lateral movement and rogue program registration.

Example secinfo (deny-by-default posture):

# Deny external program starts unless explicitly allowed
P TP=* HOST=* ACCESS=NO
# Allow only vetted middleware host(s) to start specific programs
P TP=/usr/sap/<SID>/SYS/exe/run/sapxpg HOST=mw01.corp.local ACCESS=YES

Example reginfo (control program registration):

# Deny registrations by default
P TP=* HOST=* ACCESS=NO
# Allow only specific program IDs from specific hosts
P TP=Z_MIDDLEWARE_RFC HOST=mw01.corp.local ACCESS=YES

SAP anchor: RFC Gateway Security (reginfo/secinfo concepts)

Advanced technique:
Treat gateway rules like firewall policy-as-code:

• Store reginfo/secinfo in version control
• Require pull-request approvals
• Deploy via automation (Ansible/Salt)
• Validate with a synthetic “registration attempt” test in CI

This turns a historically manual, high-risk file edit into a controlled change artifact.

3) TLS everywhere: Web Dispatcher/ICM + certificate lifecycle as a first-class system

For SAP HTTP surfaces (Fiori, OData, SOAP), TLS mismanagement is a recurring outage and risk driver. Adopt:

• TLS termination at WAF/reverse proxy (internet) and TLS re-encryption to Web Dispatcher/ICM
• mTLS for sensitive internal service-to-service calls (where feasible)

ICM SSL profile example (illustrative):

icm/server_port_0 = PROT=HTTPS,PORT=443,PROCTIMEOUT=600,TIMEOUT=60
ssl/server_pse = $(DIR_INSTANCE)/sec/SAPSSLS.pse
ssl/client_sni_enabled = TRUE

SAP anchor: TLS/SSL Configuration for AS ABAP (ICM and PSE)

Certificate lifecycle operating model (minimum):

• Central inventory (CN/SAN, system, owner, expiry, chain)
• Rotation runbooks tested quarterly
• Expiry alerts ≥ 45 days
• Separate issuing CAs for external vs internal trust

4) Authorization architecture: least privilege without role explosion

A sustainable model for S/4HANA 2023 is:

• Job-based business roles (composites)
• Derived roles for organizational levels (plant/company code/sales org)
• Strict governance for high-risk objects and cross-client/system-wide authorizations

High-risk authorization objects to explicitly gate (examples):

• User/role admin: S_USER_*
• Table access: S_TABU_DIS, S_TABU_NAM
• RFC power: S_RFC, S_RFCACL
• Debug/change: S_DEVELOP
• Transaction wildcards: S_TCODE

SAP anchor: AS ABAP Authorization Concept (Roles, authorization objects)

Advanced technique: “Authorization blast-radius scoring”
Add a numeric score to roles based on:

• Count of wildcarded objects (e.g., ACTVT=*, RFC_TYPE=*)
• Presence of table-display/change objects
• Presence of admin objects
  Use the score in IGA workflows: higher score → stronger approval + shorter recertification interval.

5) SAP HANA security: isolate, audit, encrypt, and minimize “SYSTEM”

For SAP HANA 2.0 SPS06+ (typical enterprise baseline):

• Keep HANA in a DB zone with no direct end-user access
• Use named admin users; restrict SYSTEM to break-glass
• Turn on auditing aligned to threat models and compliance

HANA audit policy examples (illustrative SQL):

-- Enable auditing (system-wide)
ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') SET ('auditing','global_auditing_state') = 'true' WITH RECONFIGURE;

-- Create an audit policy for critical actions
CREATE AUDIT POLICY AUDIT_PRIVILEGED_CHANGES
  FOR ALTER USER, CREATE USER, DROP USER, ALTER ROLE, CREATE ROLE, DROP ROLE
  LEVEL INFO
  TRAIL TYPE DATABASE;

-- Activate it
ALTER AUDIT POLICY AUDIT_PRIVILEGED_CHANGES ENABLE;

SAP anchor: SAP HANA Auditing (Security Guide)

Advanced technique: Export audit trails to SOC tooling in near-real time
If your SOC relies on syslog pipelines, design a controlled forwarder path (management zone) and ensure tamper-resistant retention. The goal is not “logs exist,” but “logs are usable for investigations.”

6) Operations as security: notes, patches, configuration drift, and transport integrity

A) SAP Security Notes operationalization

Treat SAP’s monthly cadence as a program, not an email notification:

• Triage within 48 hours
• Tiered SLA: internet-facing components (e.g., Web Dispatcher, ICM, Gateway) patched first
• Sandbox validation + targeted regression suites for critical business processes

SAP anchor: SAP Security Notes and Updates (process entry point)

B) Transport path as a security boundary

Controls to implement:

• Only a small, audited group can import to production
• Dual control for emergency fixes
• Traceability requirement → change record → transport → import log

Advanced technique: “Transport anomaly detection”
Feed STMS import logs into SIEM and alert on:

• Imports outside window
• Imports by unusual users
• Re-imports of older transports
• Imports that modify security-critical objects (auth objects, ICF nodes, RFC destinations)

Advanced Scenarios (≈500–600 words)

1) Hybrid landscape: SAP BTP extensions and identity unification

When extending S/4HANA with BTP, you introduce a second authorization plane (BTP role collections) and new trust edges (Destinations, Cloud Connector).

Architectural requirements:

• One authoritative IdP (enterprise IdP) federated to SAP identity services where applicable
• Strong governance for destinations (they often become “hidden backdoors”)
• Principle of least privilege across subaccounts, service instances, and runtime identities

SAP anchor: SAP BTP Security (Identity, roles, subaccounts)

Advanced technique: Token exchange pattern for API calls
Use an API gateway to validate JWT/OIDC tokens and perform token exchange to downstream SAP systems where feasible, rather than distributing long-lived technical credentials inside destinations.

2) OT-adjacent manufacturing: integration plane containment

Common risk: SAP connects to plant systems where patching and identity are weaker.

Pattern:

• Dedicated integration subnet (PI/PO, iPaaS runtime, or hardened middleware)
• Strict firewall rules: plant systems cannot initiate connections to SAP app servers directly
• Service accounts are vaulted; rotate secrets; disallow interactive logon
• Monitor for protocol anomalies: unusual RFC registrations, unexpected IDoc partners, sudden bursts

Advanced technique: “Protocol allowlisting by business process”
Instead of “permit RFC from middleware,” specify:

• exact gateway program IDs
• exact RFC destinations
• exact function groups/whitelisted remote-enabled modules
  This turns integration security into a governed contract.

3) High-assurance environments (SOX/GxP): security changes without breaking validation

Problem: hardening and patching can invalidate a validated state.

Pattern:

• Pre-approved hardening baselines with documented risk rationale
• Environment parity (DEV/QA/PRD) with automated config drift reports
• Patch qualification packs: list of affected components, test evidence, rollback plan

Advanced technique: “Security parameter drift as a controlled deviation”
Track SAP profile/security parameter drift as deviations with expiration dates. Deviations must either be remediated or re-approved—preventing permanent “temporary exceptions.”

4) Detection engineering: SAP-specific use cases that catch real attacks

Minimum viable detections (SOC-ready):

• Privileged role assignment (PFCG/user master changes) outside approval workflow
• Firefighter/emergency access usage without post-review within X hours
• RFC gateway denies (spikes indicate probing)
• Service user interactive logon or GUI logon attempts
• Mass table reads / unusual extract volumes (contextualized by job/run calendars)

SAP anchor: Security Audit Log (AS ABAP) concepts

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

Case 1 — Financial services: role governance + emergency access modernization

A global bank running S/4HANA 2022 faced audit findings: excessive access, inconsistent SoD controls, and weak emergency access evidence. We implemented:

• Job-based business roles with derived org-level roles
• “Critical authorization score” gating in IGA workflows
• Emergency access with time-bound assignment, reason codes, and session logging
• SIEM correlation: privileged role assignment → subsequent sensitive transactions within 24h

Outcome: audit findings dropped significantly, and the business accepted fewer “forever exceptions” because the access risk became measurable and visible.

Case 2 — Manufacturing with OT adjacency: gateway containment stopped lateral movement

A manufacturer had SAP-connected plant middleware with inconsistent host security. We:

• Micro-segmented the integration subnet
• Enforced RFC Gateway default-deny with reginfo/secinfo
• Moved technical credentials into a vault with rotation
• Built detections for gateway violations and new RFC destination creation

Outcome: during an unrelated malware incident, lateral movement attempts via program registration failed at the gateway layer; SOC had high-confidence alerts based on denies.

Case 3 — Pharma GxP: patching with validated-state constraints

A life sciences client needed security patch SLAs without breaking validation. We:

• Created a security baseline “validation pack” (documented parameters, evidence scripts)
• Established quarterly patch trains with pre-approved test suites
• Implemented drift monitoring so “hotfix hardening” didn’t silently persist

Outcome: patch latency improved while maintaining validated evidence integrity.

Strategic Recommendations (≈200–300 words)

1. Adopt a single SAP Security Reference Architecture (zoned network + identity-centric access + centralized logging). Publish it as a product standard, not a slide deck.
2. Build an interface catalog (RFC/HTTP/OData/IDoc/files). Classify by data sensitivity and exposure, then apply a control bundle per interface class (TLS/mTLS, SNC, gateway ACL, WAF/API policies, monitoring).
3. Modernize identity: enforce IdP MFA + conditional access for interactive users; reduce SAP-local password usage; harden and rotate technical identities; implement PAM and audited emergency access.
4. Operationalize patching and drift control: tie SAP Security Notes to tiered SLAs; instrument configuration drift (ICF activation, gateway rules, security parameters, cert expiry) with automated reporting.
5. Invest in SAP-aware detection engineering: onboard ABAP Security Audit Log, ICM/Web Dispatcher logs, HANA audit logs; build correlation rules that map to SAP abuse paths (privileged role assignment, RFC probing, anomalous extracts, emergency access misuse).
6. Measure what matters: patch latency, number of internet-exposed endpoints, interface count by risk tier, critical role assignments, firefighter usage rate, audit-log coverage.

Resources & Next Steps (≈150 words)

Start with SAP’s official baselines and operationalize them into your enterprise control library:

• AS ABAP security, authentication/SSO, SNC, ICF, audit logging: SAP NetWeaver AS ABAP Documentation
• HANA roles, encryption, and auditing: SAP HANA Platform Security Guide
• Edge pattern and TLS termination: SAP Web Dispatcher Documentation
• Monthly patch governance input: SAP Security Notes News
• Cloud/hybrid security foundation: SAP BTP Security

Next steps: formalize your reference architecture diagrams, publish standard configurations (gateway ACL templates, ICF baselines, TLS profiles), and implement a 90-day program to inventory interfaces + onboard SAP telemetry into SIEM with 10–15 high-signal detections.