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 + firewall rules.” Modern SAP landscapes (S/4HANA + Fiori + APIs + BTP + SaaS) require a layered security architecture where identity is the primary control plane, network zones are used to reduce blast radius (not as the main trust boundary), and SAP-native authorization models (PFCG, CDS/DCL, HANA privileges) are engineered and continuously governed.

Key recommendations:

1. Converge on a single enterprise identity plane (Azure AD/Okta/Ping) and standardize SAP integrations using SAML 2.0 for interactive access and OAuth2/JWT for system-to-system access (especially OData/API traffic).
2. Front every inbound SAP web surface (Fiori, ICF, OData) with WAF + reverse proxy + SAP Web Dispatcher, enforcing TLS, header hardening, and strict path routing.
3. Treat RFC as a high-trust channel: minimize trusted RFC, apply gateway ACLs (reginfo/secinfo), and implement UCON/RFC allowlisting to shrink callable function modules.
4. Operationalize SAP Security Patch Day + continuous drift detection (ICF exposure, STRUST certs, RFC destinations, privileged roles).
5. Make logs actionable: forward ABAP Security Audit Log + HANA audit + proxy/WAF telemetry to SIEM with a small set of high-fidelity detections.

Technical Foundation (≈450 words)

1) Why SAP security architecture is different

SAP landscapes are ecosystems, not single applications. A production business process can traverse:

• Browser → Fiori Launchpad → SAP Gateway/OData → S/4HANA ABAP → RFC to other SAP systems → HANA queries → outbound calls to BTP/SaaS.
• Admin tooling paths: SAP GUI, RFC, OS-level access, DB access, transport pipelines.

In this ecosystem, authorization is the real security boundary inside ABAP: if a user or technical identity has broad authorizations, perimeter controls merely delay misuse. Conversely, perfect PFCG design without controlling ICF/RFC exposure invites exploitation.

Two SAP-specific realities drive the architecture:

• Many protocols, many runtimes: HTTP(S) (ICF/ICM), RFC/CPIC, DIAG, SMTP, SAProuter, Web Dispatcher, Gateway/OData, and potentially Java services. Security must be consistent across channels.
• Configuration is part of the attack surface: an accidentally activated ICF node, a permissive RFC destination, or a forgotten trusted RFC relationship can undo a year of GRC work.

2) The five-plane reference model (defense in depth)

1. Identity plane: IdP federation, MFA, provisioning, privileged access, technical identities.
2. Network & access plane: zones (DMZ/app/db), reverse proxies/WAF, routing, admin bastions.
3. Application plane: ABAP authorization, ICF/Gateway hardening, RFC controls, secure development.
4. Data plane: HANA encryption/audit, data access model (CDS/DCL, analytic privileges), retention/ILM.
5. Operations plane: patching (Security Notes), monitoring/detection, incident response, continuous assurance.

A practical rule: each plane must “fail closed”. If a control is bypassed at one layer (e.g., network path found), the next layer (identity/auth) still blocks meaningful access.

3) Canonical deployment patterns

• Classic on-prem 3-tier with DMZ: WAF/Reverse Proxy → SAP Web Dispatcher → ABAP ICM → HANA (separate zone).
• Hybrid with SAP BTP: outbound-only integration via Cloud Connector; IAS-mediated identity; API Management for exposure.
• RISE/Hosted private cloud: similar technical layers, but critical to define shared responsibility for OS/DB/SAP kernel patching, cert lifecycle, and log export.
• SaaS-first: fewer platform controls; governance shifts to identity, business role design, API governance, audit evidence automation.

4) Documentation anchors (official SAP)

Use SAP component security guides as baseline and treat deviations as explicit risk decisions:

• SAP Security Notes lifecycle: SAP Security Notes and Updates (Support Portal)
• ABAP platform security concepts and authentication: AS ABAP Security (SAP Help Portal)
• SAP HANA security and auditing: SAP HANA Security Guide (SAP Help Portal)
• SAP Web Dispatcher positioning and configuration entry point: SAP Web Dispatcher (SAP Help Portal)
• SAP BTP identity/auth services:
  • SAP Identity Authentication (SAP Help Portal)
  • Authorization and Trust Management (XSUAA) (SAP Help Portal)
  • SAP BTP Connectivity & Cloud Connector (SAP Help Portal)

Implementation Deep Dive (≈900 words)

A) Identity plane: SSO, provisioning, and technical identities

A1. Standardize authentication by channel

Channel	Recommended auth	Rationale
Human (browser/Fiori)	SAML 2.0 to ABAP (or IAS brokering)	Mature enterprise SSO + conditional access at IdP
Human (SAP GUI)	SNC (Kerberos or X.509)	Encrypts DIAG, supports strong auth in regulated environments
System-to-system APIs	OAuth2/JWT (scopes)	Token-based least privilege; API gateway enforcement
Legacy integrations	Cert-based TLS + restricted technical users	Reduce password usage; enable rotation

For SAP BTP apps and services, align to OAuth-based flows and avoid long-lived basic credentials. XSUAA is the canonical authorization service for many BTP application runtimes: Authorization and Trust Management (XSUAA).

Practical standard (what to enforce as policy):

• No shared dialog users for business usage.
• No password-based technical users where a token/certificate is possible.
• One integration = one technical identity (traceability), with a dedicated role and a dedicated log/monitoring pattern.

A2. Provisioning and governance model (practitioner baseline)

• Authoritative source: HR (e.g., SuccessFactors/Employee Central) → IGA (SAP IAG or equivalent).
• Access request + SoD: SAP Access Control / SAP IAG for workflows, SoD analysis, and emergency access governance.
• Privileged access: PAM (CyberArk/BeyondTrust) for shared admin IDs, session recording, and just-in-time elevation.

Hard rule: interactive users should not be the same identities used for interfaces/background. Separate identity populations and enforce different control objectives (MFA vs rotation vs monitoring).

Concrete access governance measures that actually hold up in audits:

• Unique assignment: ensure each PFCG business role maps to one IGA entitlement; avoid “manually assign PFCG roles in prod.”
• Role owner + periodic review: each business role has an accountable owner; run quarterly certification with remove/attest outcomes recorded.
• Emergency access: firefighter IDs are time-bound, workflow-approved, and fully logged (transaction usage + change logs).

A3. BTP + IAS identity topology (hybrid pattern)

A robust model is: Corporate IdP → IAS (as SAP hub) → BTP subaccounts + SAP SaaS. IAS provides SAP-centric federation and user store features: SAP Identity Authentication Administration.

When IAS is worth it

• You have multiple SAP SaaS properties (SuccessFactors, Ariba, Concur) and want consistent conditional access patterns.
• You need SAP-focused user lifecycle features (user attributes, groups) without pushing everything into corporate IdP.
• You want to centralize SAP trust configuration (cert rollover, SAML metadata) once.

A4. Step-by-step: Configure SAML 2.0 SSO for ABAP (Fiori / Web GUI)

Goal: corporate IdP authenticates users; ABAP trusts SAML assertions; users are mapped to ABAP users.

1. Prerequisites

• Working HTTPS on ABAP (ICM) and valid server TLS certificate in STRUST (see Data plane for cert lifecycle notes).
• Hostnames stable: decide the official Fiori URL (e.g., “).
• Time sync (NTP) correct on IdP and ABAP (SAML is time-sensitive).

2. Enable and configure SAML provider (ABAP)

• Transaction: SAML2
• Choose “SAML 2.0 Configuration” → “Enable SAML 2.0 Support” (if not enabled).
• Maintain:
  • Local Provider settings:
    • Name: S4P_FIORI
    • Endpoint base URL: “
  • Trusted Providers:
    • Import IdP metadata XML (Azure AD/Okta/Ping).
    • Set signature requirements to Signed assertions (and ideally signed responses).
  • Certificates:
    • Ensure IdP signing certificate is present and valid.
    • Plan rollover: import “Next” cert before cutover.

3. User mapping strategy (choose one, document it)

• Common approach: map SAML NameID or mail to ABAP user.
• In SAML2 → “Trusted Provider” → “Identity Federation”:
  • Configure User ID mapping mode: e.g., “E-Mail” or “Logon ID”.
  • If using email mapping, enforce uniqueness in SU01 (no duplicates).

4. Activate SAML for target services

• Transaction: SICF
• For Fiori launchpad:
  • /sap/bc/ui5_ui5/
  • /sap/bc/ui2/
  • /sap/bc/ui2/flp
• For OData/Gateway (if applicable):
  • /sap/opu/odata
• For each service: right-click → “Activate Service” (only what you need) and set logon procedure as required by your platform version.
  • Also ensure anonymous access is not enabled unless explicitly required.

5. Enforce SSO and reduce fallback risk

• Disable weak fallback mechanisms where possible:
  • Avoid Basic auth exposure on internet-facing endpoints.
  • Ensure Web Dispatcher / reverse proxy does not allow direct access to internal hostnames.
• Validate:
  • Browser access: confirm IdP redirect works.
  • Session behavior: logout, session timeout, and re-auth.

Operational tip: record the SAML metadata endpoints and renewal dates as a standard artifact. Most SSO outages are certificate rollover failures, not “auth bugs.”

A5. Step-by-step: Configure SNC for SAP GUI (DIAG) with Kerberos

Goal: encrypt SAP GUI traffic and enforce strong authentication without passwords.

1. Plan the method

• Kerberos via Microsoft AD is most common for enterprises.
• Choose a supported SNC library (commonly SAP’s CommonCryptoLib with Kerberos integration, or a partner library depending on platform).

2. Core ABAP profile parameters (example baseline)

• snc/enable = 1
• snc/gssapi_lib = $(DIR_EXECUTABLE)/sapcrypto.dll (path differs by OS)
• snc/identity/as = p:CN=S4P, O=Company, C=US (example; align with your SNC principal)
• snc/accept_insecure_gui = 0 (force SNC; test carefully in lower env first)
• snc/data_protection/min = 3 (max protection; “3” typically = privacy/integrity/auth)

3. User mapping

• Transaction: SU01
• Maintain SNC name (e.g., p:CN=user@COMPANY.COM) for each user, or use rules / external mapping if supported.

4. Test and cutover

• Use SAP GUI connection string with SNC enabled.
• Monitor failed logons (Security Audit Log) during pilot.
• Roll out gradually (start with admin users, then business users).

A6. OAuth2/JWT for APIs: ABAP Gateway + API Management pattern

For OData and API traffic, you want token-based access, enforced at the gateway and validated by ABAP.

Common enterprise pattern:

• Client → API Gateway (e.g., Apigee, Azure API Management, SAP API Management)
• Gateway obtains/validates JWT (OAuth2)
• Gateway forwards to SAP via HTTPS, with principal propagation (JWT/SAML) or a constrained technical user, depending on capability and risk.

ABAP-side starting points (varies by release):

• Transaction SOAUTH2: configure OAuth 2.0 clients/providers if using ABAP as authorization server or for inbound/outbound scenarios.
• Transaction STRUST: maintain trust anchors/certs if validating tokens via TLS endpoints.
• For BTP-centric JWT, validate via IAS/XSUAA trust where supported; keep the trust config documented and tested.

B) Network & access plane: DMZ patterns and admin paths

B1. Inbound web traffic reference flow

Internet/WAN
  → WAF / Reverse Proxy (TLS policy + threat protection)
    → SAP Web Dispatcher (SAP-aware routing, optional TLS re-encrypt)
      → ABAP ICM/ICF (Fiori + OData via Gateway)
        → Backend ABAP + HANA

Design intent:

• Keep ABAP ICM off the internet.
• Enforce deny-by-default routing at the proxy/Web Dispatcher (only required paths/hosts).
• Terminate TLS at the edge and re-encrypt to backend for regulated environments.

B2. SAP Web Dispatcher hardening (sample profile)

Below is a practical starting point (adjust to your version; test carefully):

# --- Listener ---
icm/server_port_0 = PROT=HTTPS,PORT=443,PROCTIMEOUT=600,TIMEOUT=60

# --- TLS configuration (PSE maintained via sapgenpse/STRUST pipeline) ---
ssl/ssl_lib = $(DIR_EXECUTABLE)/sapcrypto.dll
ssl/server_pse = $(DIR_INSTANCE)/sec/SAPSSLS.pse

# Prefer modern protocols/ciphers (exact parameters vary by kernel)
ssl/client_ciphersuites = 150:PFS:HIGH::EC_P256:EC_HIGH
ssl/ciphersuites = 150:PFS:HIGH::EC_P256:EC_HIGH

# --- Routing: restrict and explicitly map ---
wdisp/system_0 = SID=S4P, MSHOST=s4p-msg.internal.corp, MSPORT=3601, SRCSRV=*:443

# Optional: block unused paths early (example)
icm/HTTP/mod_0 = PREFIX=/sap/public/bc, FILE=$(DIR_PROFILE)/deny_public_bc.conf

Operationally, treat the Web Dispatcher profile as security-as-code: version it, promote via controlled change, and validate every change using an automated smoke test (HTTP 200/302 on allowed paths, HTTP 404/403 on forbidden paths).

Concrete “deny by default” routing approach

• Enumerate only the paths you intend to expose (typical examples):
  • /sap/bc/ui2/flp
  • /sap/bc/ui5_ui5/
  • /sap/opu/odata/ (only if required externally; many enterprises keep OData internal)
  • /sap/public/ping (health checks only, if needed)
• Explicitly deny everything else at the edge (WAF/reverse proxy) and again at Web Dispatcher.

If you maintain a deny file for paths, keep it human-readable and reviewed:

# deny_public_bc.conf (example concept; syntax depends on your ICM mod usage)
# Deny legacy public BC endpoints unless explicitly needed
deny   /sap/public/bc
deny   /sap/bc/bsp/sap
deny   /sap/bc/gui/sap/its

B3. Reverse proxy / WAF: concrete controls that matter for SAP

A WAF in front of SAP should not be a generic checkbox. Configure it with SAP-aware intent:

• TLS policy

  • Only TLS 1.2/1.3
  • Strong cipher suites
  • Disable renegotiation if possible
  • HSTS enabled for public domains: Strict-Transport-Security: max-age=31536000; includeSubDomains

• Header hardening (baseline)

  • X-Content-Type-Options: nosniff
  • X-Frame-Options: SAMEORIGIN (or DENY if no embedding)
  • Content-Security-Policy tuned for Fiori (start in report-only mode to avoid breaking apps)
  • Remove server-identifying headers where possible

• Request limits

  • Max header size, max body size, max URL length
  • Rate limits for login endpoints
  • Bot protection for internet-facing portals

• Authentication enforcement

  • If using SAML, block direct basic-auth attempts from the internet where feasible.
  • For APIs, enforce JWT validation at the gateway and pass through only validated traffic.

Validation checklist (do this in test)

• Attempt to access internal ICF paths directly → should be blocked at proxy/WAF.
• Attempt OPTIONS / unusual methods where not needed → blocked.
• Attempt high-rate login attempts → throttled and alerted.

B4. Admin access paths: bastion, segmentation, and “break glass”

Admin access is often where SAP landscapes fail audits. The goal is not “no admin access,” but one controlled way to administer.

Recommended admin path pattern

• Admin workstation → VPN / ZTNA → Privileged Access Workstation (PAW) / Bastion → SAP GUI / HANA Studio / SSH
• No direct admin access from unmanaged endpoints
• MFA required, and sessions recorded for high privilege

Concrete network segmentation

• DMZ: WAF, reverse proxy, Web Dispatcher
• App zone: ABAP app servers, message server
• DB zone: HANA
• Mgmt zone: monitoring, backup, jump hosts
• Block east-west by default; open only required ports

Ports to explicitly document (examples; verify your architecture)

• HTTPS: 443 (WAF → Web Dispatcher → ICM)
• SAP message server: 36xx
• SAP gateway: 33xx
• HANA SQL: 3xx15 (instance-based)
• SAProuter (if used): 3299

B5. SAProuter and remote vendor access (controlled)

If you use SAProuter:

• Place SAProuter in a controlled zone (often DMZ or mgmt zone, depending on model).
• Use a strict saprouttab allowlist (no wide-open routes).
• Time-bound vendor rules: enable only during approved windows.

Example concept for saprouttab (illustrative):

• Allow only specific SAP OSS destinations and only from specific internal hosts.
• Deny everything else.

C) Application plane: ABAP hardening, ICF/Gateway controls, RFC/UCON, and secure development

C1. ABAP authorization model: design for least privilege (not “role explosion”)

Practical role architecture (works at scale)

• Business roles: aligned to job functions (e.g., AP Clerk, Production Planner)
• Technical roles: used by interfaces/background jobs (strictly separated)
• Composite roles: bundle business roles; never assign technical roles to dialog users unless justified and approved
• Derived roles: manage org-level restrictions (company code, plant) using org fields

Concrete build steps (repeatable)

1. Identify the transaction/app list per job.
2. Build a menu role in PFCG, generate authorizations.
3. Use trace tools:
   • SU53 (last authorization check)
   • STAUTHTRACE (richer trace; recommended for complex Fiori/OData)
4. Restrict with org values and authorization object fields.
5. Remove “wildcards” (*) from sensitive objects.

High-risk authorization objects to treat as security boundaries

• S_USER_* (user admin)
• S_RFC (RFC function/module authorization)
• S_TCODE (transaction start)
• S_TABU_DIS / S_TABU_NAM (table maintenance)
• S_DEVELOP (workbench access)
• S_TRANSPRT (transport management)
• S_SERVICE (service/ICF-related, varies by release)
• S_ICF (ICF service authorization in some scenarios)

C2. ICF service governance: “activated equals exposed”

ICF is a common drift problem: teams activate nodes for testing and forget to disable them.

Step-by-step: ICF hardening workflow

1. Transaction SICF
2. Export a list of active services (build a baseline per system role: DEV/QAS/PRD)
3. For each active node, record:
   • Business owner
   • Technical owner
   • URL path
   • Authentication method
   • Whether it is internet-facing, intranet-only, or internal-only
4. Disable everything not required in production.
5. Put a monthly drift check in place (compare against baseline).

Minimum posture

• Only activate what you use.
• Prefer SAML SSO (interactive) or OAuth/JWT (API) patterns over basic auth.
• Ensure error handling does not leak stack traces in internet scenarios (test with malformed requests).

C3. SAP Gateway / OData controls that reduce real risk

OData exposure often becomes “accidental API publication.” Control it intentionally:

• Catalog which services are active

  • Transaction /IWFND/MAINT_SERVICE (Gateway service maintenance)
  • Remove services not required; document owners.

• Enforce authorization

  • Ensure OData services check proper authorization objects and are not “open.”
  • For custom services, ensure you implement DPC_EXT checks (don’t rely on UI hiding).

• External exposure policy

  • If OData must be external, put it behind API gateway and enforce:
    • JWT validation
    • Rate limiting
    • IP allowlists for partners
    • Schema validation (where possible)

C4. RFC as a high-trust channel: minimize, restrict, and monitor

RFC is powerful: it can be used for legitimate integration, and it can be used for lateral movement.

Controls (in order of impact)

1. Reduce trusted RFC

   • Trusted RFC can bypass password prompts and expand blast radius if compromised.
   • Keep a documented list; review quarterly.

2. Gateway ACLs: reginfo/secinfo

   • Maintain explicit allowlists for:
     • Which external programs can register at the gateway (reginfo)
     • Which hosts/users can start external commands (secinfo)
   • Configure profile parameters (examples):
     • gw/acl_mode = 1 (enable ACL checking; verify exact behavior on your release)
     • gw/reg_info = $(DIR_DATA)/reginfo
     • gw/sec_info = $(DIR_DATA)/secinfo

Example reginfo concept (illustrative):

• Permit only specific program IDs and source hosts.
• Deny all others.

Example secinfo concept (illustrative):

• Permit only approved external RFC server programs and only from approved hosts.
• Deny everything else.

3. UCON (Unified Connectivity) allowlisting

   • Use UCONCOCKPIT to restrict:
     • RFC function module access
     • External calls
     • Legacy interfaces
   • Start with monitoring mode, then enforce mode.
   • This is one of the most effective SAP-native ways to shrink the callable surface area.

4. Technical user hardening

   • In SU01, ensure technical users:
     • Are type “System” or “Communication” (not Dialog)
     • Have password policy aligned to rotation (or no password if using cert/token patterns)
     • Have only required RFC authorizations (S_RFC) and nothing broad like S_RFC with RFC_NAME=*

Step-by-step: RFC destination governance

1. Transaction SM59
2. For each destination, record:
   • Owner
   • Purpose
   • Authentication method (user/password vs SNC vs certificates)
   • Endpoint host and whether it’s internal
3. Enforce:
   • No shared service accounts across destinations
   • Strong auth where possible (SNC/certs)
   • Logging and alerting on failures and unusual volumes

C5. ABAP secure development baseline (minimal but effective)

Even with strong platform controls, custom code can undermine everything.

Minimum ABAP secure coding practices to operationalize:

• Run ATC (ABAP Test Cockpit) with security-relevant checks in your pipeline.
• Enforce no hardcoded secrets; use secure stores where applicable.
• For OData/custom ICF:
  • Validate input strictly
  • Avoid dynamic SQL
  • Enforce authorization checks in backend, not only in UI

Example pattern: explicit authorization check in ABAP (illustrative)

• Use AUTHORITY-CHECK against the correct object before sensitive operations.
• Log failures meaningfully (without exposing secrets).

D) Data plane: encryption, key management, HANA audit, and data access design

D1. Encryption in transit (end-to-end)

Targets

• Browser → WAF/proxy: HTTPS
• Proxy → Web Dispatcher: HTTPS
• Web Dispatcher → ABAP ICM: HTTPS
• ABAP → HANA: encrypted (HANA TLS)
• ABAP ↔ ABAP (RFC/DIAG): SNC where feasible
• Integrations: TLS + mTLS where appropriate

Certificate lifecycle (what to document and automate)

• Certificate owners and renewal dates
• Where certificates live:
  • ABAP: STRUST (PSEs)
  • Web Dispatcher: SAPSSLS.pse (often managed with sapgenpse)
  • HANA: instance SSL config / keystore
• Renewal procedure and rollback plan

Practical renewal steps for ABAP TLS cert (high-level)

1. Generate CSR in STRUST for the relevant PSE (commonly SSL Server Standard).
2. Get it signed by enterprise CA.
3. Import the signed certificate and full chain.
4. Distribute and restart ICM if required.
5. Validate with:
   • Browser test
   • openssl s_client from proxy network segment (where allowed)
   • Monitoring check (cert expiry alerting)

D2. HANA encryption at rest and auditing

HANA provides encryption and auditing capabilities that should be treated as baseline for regulated environments.

At-rest encryption

• Enable data and log volume encryption where required by policy.
• Ensure key management and backups are aligned to encryption (encrypted backups, key escrow policy).

HANA audit

• Enable audit policy for:
  • User and role changes
  • Privilege grants/revokes
  • Logon/logoff and failed logons
  • Reads on sensitive schemas (where feasible without overwhelming volume)

Example HANA audit policy concept (illustrative; adapt to your SQL dialect/version):

• Create an audit policy that logs:
  • CREATE USER, ALTER USER, DROP USER
  • GRANT, REVOKE
  • Failed logons
  • Changes to critical roles

Operationally:

• Store audit logs in a protected location.
• Forward to SIEM (see Operations plane) or at least to a central log platform with retention controls.

D3. Data access model: CDS/DCL, analytic privileges, and “who can read what”

In S/4HANA, authorization is increasingly enforced at the semantic layer:

• CDS views + DCL (Data Control Language) rules
• Analytic privileges (more common in pure HANA analytic scenarios)

Governance practices

• Treat CDS authorization design as part of your role engineering lifecycle.
• Keep a matrix:
  • Business role → CDS access category → sensitive fields → masking requirements (if any)

Data masking / privacy

• If you have privacy constraints (PII), implement:
  • Field-level controls where supported
  • Output controls in apps/services
  • Logging and justification for privileged access

D4. Retention and ILM: avoid “security by infinite retention”

Security and compliance often conflict with “keep everything forever.” Define:

• Retention periods by data class (financial, HR, operational logs)
• Legal hold procedures
• Secure deletion processes where required

E) Operations plane: patching, logging, monitoring, and continuous assurance

E1. SAP Security Patch Day: make it a system, not a meeting

A workable monthly patch process looks like this:

1. Intake

• Track SAP Security Patch Day releases.
• Pull relevant notes for your components (ABAP, HANA, Web Dispatcher, ICM, Gateway, etc.).

2. Triage

• Tag each note:
  • “Hot” (internet-facing, auth bypass, RCE, widely exploited)
  • “High”
  • “Normal”
• Decide SLA by tag (e.g., Hot = 7 days, High = 30 days, Normal = 90 days), aligned to your risk policy.

3. Build and test

• Apply notes in DEV, then QAS.
• Validate:
  • Fiori login
  • Key OData services
  • Core transactions
  • Interfaces (RFC, IDoc, PI/PO/CPI where applicable)

4. Deploy

• Move via controlled change window.
• Confirm kernel/ICM/Web Dispatcher updates where needed (not only ABAP notes).

5. Evidence

• Store:
  • Note list, implementation status, test results, change approvals
  • This becomes audit-ready evidence automatically.

E2. Logging that matters: ABAP Security Audit Log + HANA + edge telemetry

ABAP Security Audit Log

• Configure in:
  • Transaction SM19 (configuration)
  • Transaction SM20 (analysis)
• Recommended to log at least:
  • Logon/logoff (success + failure)
  • RFC logons
  • User changes
  • Authorization failures (with care—can be noisy)

Example configuration approach (conceptual)

• Define an audit profile for production:
  • Include critical events
  • Exclude extremely noisy low-value events
• Write to filesystem or database per your operational model.
• Ensure retention and integrity controls.

HANA audit

• Enable audit policies for privileged activities and authentication events (see Data plane).

Edge telemetry

• WAF: blocked requests, anomalies, bot signals
• Reverse proxy: auth failures, unusual paths
• Web Dispatcher: backend routing errors, unexpected endpoints

E3. Forwarding to SIEM: high-fidelity detections (start small)

Instead of “forward everything and drown,” start with a small set of reliable detections:

• Repeated failed logons for privileged users (ABAP + HANA)
• Use of emergency access / firefighter outside approved windows
• Activation of new ICF services in production (drift)
• Creation/changes of RFC destinations (SM59 changes)
• New trusted RFC relationships
• Changes to critical roles (PFCG role change transport/import)
• Unusual OData call volume or access to sensitive entity sets
• Certificate expiry < 30 days (ABAP STRUST, Web Dispatcher, proxy)

Concrete drift detection ideas (actionable)

• Weekly export snapshots:
  • SICF active services list
  • SM59 destinations list
  • STRUST certificate inventory (subject, issuer, expiry)
  • List of users with critical authorizations (e.g., SAP_ALL, SAP_NEW, S_USER_* scopes)
• Compare to baseline and alert on deltas.

E4. Incident response in SAP: pre-plan the moves

SAP incidents are hard when you’re improvising. Pre-build:

• A break-glass procedure (who can do what, how to log, how to revoke)
• A containment playbook:
  • Disable user (SU01), revoke roles, lock technical users
  • Disable ICF services (SICF) if exploited
  • Disable/adjust RFC destinations (SM59) and gateway ACLs (reginfo/secinfo)
  • Rotate certificates/secrets where relevant
• Forensics readiness:
  • Ensure Security Audit Log and HANA audit are retained and accessible to responders

F) Governance, Risk & Compliance (GRC): SoD, emergency access, and control automation

F1. Segregation of Duties (SoD) that aligns with SAP reality

SoD is only effective if it maps to how SAP is used.

Core SoD practices:

• Maintain a ruleset aligned to your processes (Procure-to-Pay, Order-to-Cash, Record-to-Report).
• Enforce SoD checks at:
  • Access request time (prevent)
  • Periodic review time (detect/correct)
• Treat “temporary exceptions” as time-bound with documented compensating controls.

F2. Emergency access (firefighter) done correctly

Minimum standard:

• Firefighter IDs are not personal daily drivers.
• All usage is:
  • Approved
  • Time-bounded
  • Logged (what transactions, what changes)
  • Reviewed after the fact

In SAP GRC Access Control (or equivalent), implement:

• Firefighter owner
• Controller/reviewer role
• Automated log collection and review workflow

F3. Control automation: reduce manual evidence work

Controls you can automate with low effort:

• Patch compliance report (notes implemented vs pending)
• Privileged user inventory
• Role change reports (what changed, who approved)
• Interface inventory (SM59/RFC destinations) with ownership
• Certificate expiry dashboards

This shifts audits from “screenshots” to repeatable, system-generated evidence.

Reference Architecture Blueprint (practical summary)

If you need a “minimum secure” enterprise blueprint that works across most landscapes:

1. Identity

• Corporate IdP with MFA + conditional access
• SAML 2.0 for interactive SAP web access
• SNC for SAP GUI in regulated environments
• OAuth2/JWT for APIs and system-to-system

2. Edge

• WAF + reverse proxy in DMZ
• SAP Web Dispatcher with strict routing (allowlist only)
• TLS everywhere, with managed certificate lifecycle

3. Core SAP controls

• Least-privilege PFCG roles, no wildcards on sensitive objects
• ICF governance (baseline + drift detection)
• Gateway service inventory and authorization enforcement
• RFC minimization + gateway ACLs + UCON allowlisting

4. Data

• HANA encryption and audit (policy-driven)
• CDS/DCL governance for semantic-layer authorization

5. Operations

• Monthly Security Notes process with SLAs
• ABAP Security Audit Log + HANA audit + edge telemetry to SIEM
• Incident playbooks tailored to SAP knobs (SICF/SM59/SU01/UCON)

If you implement only one principle end-to-end: treat SAP configuration as code and continuously detect drift. That single shift eliminates a large fraction of real-world SAP security failures.