T-codes accelerate access to business functions, but they also compress many actions into a small set of commands. If roles are overly broad, users can reach posting, maintenance, or reporting functions that should be separated. That creates segregation of duties risk, makes misuse easier, and increases the chance of unauthorised changes or hidden process abuse.
Why This Matters for Security Teams
Transaction codes are not the problem by themselves. The risk appears when they become a shortcut around role engineering, control validation, and segregation of duties. In SAP, a single T-code can expose posting, maintenance, approval, or reporting capabilities that are hard to see in a coarse role design. That makes privilege creep easier and detective controls less reliable.
This maps to the same identity failure pattern seen across broader enterprise access governance: broad entitlements, weak lifecycle control, and limited visibility. NHIMG research shows that 97% of NHIs carry excessive privileges, which is a strong reminder that over-broad access is the default failure mode, not the exception. The same principle applies when SAP access is granted by convenience rather than by task-specific need in Ultimate Guide to NHIs — Why NHI Security Matters Now.
Security teams should treat T-code assignment as an access design problem, not just a technical authorization issue. A role that looks acceptable in a spreadsheet can still allow toxic combinations once users chain multiple codes across business processes. In practice, many security teams encounter SoD violations only after an audit finding, fraud signal, or production incident has already exposed the weakness.
How It Works in Practice
Weak role design increases risk because SAP authorizations often operate at the level of broad business capability, while T-codes provide direct entry points into those capabilities. If a role includes several related codes without proper business restriction, a user may be able to create, post, change, approve, and review the same process chain. That breaks least privilege and makes misuse harder to detect.
Effective control design starts by mapping each T-code to the underlying business risk, then checking whether a single role grants incompatible functions. For example, the same person should not be able to create a vendor, change bank details, and execute payment-related activity without compensating controls. This is why SAP access reviews need both functional owners and security owners, not just technical administrators. The control logic should align with the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around least privilege, separation of duties, and access review discipline.
- Use T-code inventories to identify which commands expose create, change, approve, and post functions.
- Test role combinations for SoD conflicts before provisioning, not after go-live.
- Limit sensitive codes with derived roles, context checks, or approval gates where possible.
- Review emergency access separately from day-to-day access.
NHIMG guidance on Top 10 NHI Issues reinforces the broader point: when identities are granted too much standing access, the organisation inherits both hidden privilege and weaker accountability. These controls tend to break down in large SAP landscapes with custom T-codes, inconsistent role naming, and multiple support teams because entitlement drift outpaces manual review.
Common Variations and Edge Cases
Tighter T-code governance often increases operational overhead, requiring organisations to balance faster business access against stronger change control and review effort. That tradeoff is real, especially in environments with shared service centers, global templates, or heavy use of emergency access.
Not every broad role is automatically unsafe. Current guidance suggests the key question is whether the role bundles incompatible actions without a compensating control. A reporting role may be broad but still acceptable if it cannot create or alter master data. By contrast, even a small set of codes can be high risk if they enable end-to-end process abuse. This is where SAP controls should be paired with broader identity governance and monitoring, as described in Ultimate Guide to NHIs and the operating model in NIST Cybersecurity Framework 2.0.
Edge cases matter in custom ABAP-heavy systems, merger environments, and third-party support models, where code naming may not clearly reveal business impact. In those cases, best practice is evolving toward continuous access analysis rather than annual cleanup alone. If the organisation cannot accurately trace what a T-code really does, the role design is already too weak to trust.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 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-03 | Broad privileges and weak rotation increase hidden access risk. |
| CSA MAESTRO | IAM-04 | Highlights access governance for autonomous or high-impact workloads. |
| NIST CSF 2.0 | PR.AC-4 | Covers access authorization and privilege management for business systems. |
| NIST SP 800-63 | Supports identity assurance and access governance around privileged users. | |
| NIST AI RMF | Useful for governance and accountability where access decisions affect business outcomes. |
Review sensitive SAP access for overbroad entitlements and remove standing privilege where possible.
Related resources from NHI Mgmt Group
- How should security teams test and govern SAP transaction codes before users rely on them in production?
- Why do Salesforce integrations increase NHI risk?
- Why do SAP Fiori transaction codes create segregation-of-duties risk?
- Why do multi-tenant backup consoles create high-impact risk when agent identity checks are weak?
