What breaks when SAP code is modified directly instead of using extensibility and transport controls?

Why This Matters for Security Teams

Directly modifying SAP code turns a controlled enterprise platform into a patchwork of exceptions. The immediate problem is not just upgrade pain. It is also loss of traceability, weaker segregation of duties, and a higher chance that security fixes, transport approvals, and regression testing fall out of sync. NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for configuration control, change management, and auditability.

For teams managing business-critical SAP landscapes, the real risk is that one-off edits become invisible dependencies. A change that looks harmless in production can collide with future support packs, custom authorisations, or downstream integrations. That is why SAP extensibility and transport governance exist: they preserve the ability to prove what changed, who approved it, and whether the change can be safely reversed. NHI Mgmt Group has repeatedly shown how unmanaged embedded credentials and opaque control points create enterprise exposure, including in the Ultimate Guide to NHIs — Standards. In practice, many security teams discover the control gap only after a release fails or a hotfix has already been pushed through production.

How It Works in Practice

Secure SAP change management separates what the business needs from how the core product is altered. Instead of editing standard objects directly, teams use approved extensibility patterns such as user exits, BAdIs, side-by-side extensions, or application-specific configuration. transport controls then ensure each change is versioned, tested, approved, and moved through environments in a predictable sequence. That matters because the transport record becomes the evidence trail for audit, incident response, and rollback.

This approach is strongest when paired with clear ownership and code scanning. Security teams should treat custom SAP objects like any other privileged change surface: define who can create or approve them, require testing against patch baselines, and validate that transport content does not introduce embedded secrets or unreviewed logic. The broader NHI risk is relevant here too, because custom code often embeds technical credentials, service users, or API endpoints that later get copied into other systems. NHIMG documents this pattern in SAP SQL Anywhere Monitor Hardcoded Credentials and in the SAP Breach research.

A practical control stack usually includes:

• Transport approval before promotion into production
• Code review for modified or custom objects
• Regression testing aligned to SAP support and patch cycles
• Inventory of customisations with business owner and technical owner
• Secret scanning and credential removal from all custom code

These controls tend to break down when organisations allow emergency fixes to bypass the transport path because the shortcut creates an undocumented state that cannot be cleanly tested or reversed.

Common Variations and Edge Cases

Tighter change control often increases delivery time, so organisations must balance speed against the risk of losing upgradeability. That tradeoff is most visible in regulated environments, highly customised SAP estates, and migrations where teams are under pressure to keep legacy processes running while modernising core systems.

There is no universal standard for every SAP extension pattern yet, but current guidance suggests preserving the vendor core wherever possible and limiting direct modification to exceptional cases with formal risk acceptance. In some environments, business-critical workarounds may remain temporarily in place until a replacement extension is built, but those exceptions need expiry dates, ownership, and review triggers. The most common failure mode is assuming a direct code change is cheaper than a transport-safe extension. It often is not, because the hidden cost appears later during upgrades, security patching, and audit evidence collection. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for documenting those controls, but the operational discipline still has to be enforced in SAP release management.

Related resources from NHI Mgmt Group

• What breaks when child accounts are populated manually instead of using controlled vault migration processes?
• What breaks when provider API keys are stored directly in application code instead of a controlled gateway or secret store?
• What breaks when LLM access is integrated directly into each application instead of using a shared gateway?
• What breaks when identity events are treated as brand exposure instead of governance opportunities?