Security teams should separate custom logic from the SAP core, use transport controls, and enforce review before code reaches production. The goal is to preserve upgradeability while still supporting business-specific changes. Strong governance also means version control, testing in non-production systems, and limiting direct modification of standard objects so changes remain traceable and reversible.
Why This Matters for Security Teams
ABAP customisation is not just a development concern. In large SAP estates, it becomes a security, change-management, and resilience problem because code that is embedded too deeply into the core can create upgrade blockers, hidden privilege paths, and fragile dependencies. Security teams need governance that preserves the ability to patch and modernise SAP while preventing uncontrolled modifications that are difficult to test, audit, or reverse.
The practical risk is that custom objects often outlive the business requirement that created them. That is why NHI Management Group consistently stresses lifecycle discipline in its guidance, including Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the broader risk framing in Top 10 NHI Issues. The same pattern applies in SAP: unmanaged change paths become operational debt. NIST CSF 2.0 also reinforces that secure change control and recovery planning are part of resilient governance, not optional extras. In practice, many security teams encounter upgrade failures only after a critical business release has already depended on undocumented custom code.
How It Works in Practice
Effective ABAP governance starts with a simple separation principle: keep custom logic out of standard objects whenever possible. Use enhancement points, exits, BAdIs, wrapper services, and controlled extension layers instead of direct modification of SAP core code. That approach reduces regression risk and makes upgrades more predictable because the original vendor-delivered objects remain intact.
Security teams should require transport-based promotion, peer review, and change approval before code reaches production. That includes scanning custom ABAP for hardcoded secrets, privileged RFC usage, unsafe authorisation checks, and direct table access that bypasses business controls. Where the codebase supports it, enforce version control outside the SAP development system so changes are traceable from request to deployment. The governance goal is to make every change reversible, testable, and attributable.
For high-risk changes, tie release approval to non-production validation, including regression testing against upgrade scenarios and critical business workflows. Current guidance suggests treating custom code the same way NHI teams treat sensitive workload credentials: minimise standing privilege, limit reach, and review every privileged path. This aligns well with the NIST Cybersecurity Framework 2.0 emphasis on controlled change, and with NHI governance practices described in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. These controls tend to break down when multiple SAP teams share loosely governed transport paths because code ownership and approval accountability become diluted.
Common Variations and Edge Cases
Tighter ABAP control often increases delivery overhead, so organisations have to balance release speed against upgradeability and auditability. That tradeoff is most visible in highly customised SAP landscapes where business units depend on legacy code that cannot be refactored quickly.
One common edge case is the need to support temporary emergency fixes. Best practice is evolving, but current guidance suggests treating break-glass changes as exceptional, time-bound, and fully logged, with post-implementation review before the next normal transport cycle. Another case is third-party add-ons that behave like pseudo-core dependencies: they may not be custom ABAP, but they can still create the same upgrade exposure if they alter standard behaviour or rely on undocumented interfaces.
Security teams should also distinguish between low-risk configuration and true code change. Configuration drift can be easier to correct than ABAP modification, but both need ownership and evidence. Where SAP landscapes span multiple regions or business lines, governance should include a clear exception process, dependency inventory, and release freeze criteria tied to patch windows. The risk is not merely that a change will fail today, but that it will make the next support pack or S/4HANA migration materially harder to execute. In the worst cases, teams discover that customisation was effectively treated as permanent infrastructure only after an upgrade programme has already stalled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Custom ABAP often embeds secrets and privileged access paths. |
| OWASP Agentic AI Top 10 | Runtime code paths and privilege checks need tighter review discipline. | |
| CSA MAESTRO | GOV-1 | Governance and ownership controls fit large SAP change management. |
| NIST CSF 2.0 | PR.IP-3 | Secure change control is central to avoiding upgrade risk. |
| NIST AI RMF | GOVERN | Governance principles help structure accountability for custom code risk. |
Inventory and eliminate embedded secrets in custom ABAP, then move access to managed rotation and retrieval.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities in cloud environments?
- How should security teams implement SAP data masking in large HANA environments without breaking relational integrity?
- How should security teams implement passkeys in B2B environments without creating recovery risk?
- How should security teams implement AI gateway logging without creating operational risk in production environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
