An ABAP transport request is the controlled package used to move development objects and configuration changes between SAP environments. It records what changed, who changed it, and where it should be deployed. This mechanism supports governance, traceability, and orderly promotion from development to test and production.
Expanded Definition
An ABAP transport request is the SAP change vehicle that packages development objects, repository updates, and configuration changes for controlled movement across landscapes. In NHI security terms, it is not just a release artifact but a governance checkpoint that records ownership, authorization, sequence, and target system intent.
Definitions vary across vendors when transport governance is discussed alongside deployment pipelines, but the core idea remains the same: a transport request preserves traceability from development through test and production. That traceability matters because the ABAP runtime often contains sensitive business logic, privileged integrations, and automation that behave like NHIs when they execute with persistent authority. For a broader identity-risk view, NHI Mgmt Group’s Ultimate Guide to NHIs explains why non-human execution paths need the same rigor as human access. From a control perspective, the change record should support least privilege, separation of duties, and auditability aligned to NIST Cybersecurity Framework 2.0.
The most common misapplication is treating a transport request as a simple delivery wrapper, which occurs when teams bypass review controls and move privileged code without verifying who approved the change or what system impact it creates.
Examples and Use Cases
Implementing transport governance rigorously often introduces process friction, requiring organisations to weigh deployment speed against control integrity, especially when ABAP changes support business-critical automation.
- A developer updates an SAP authorization object and the change is bundled into a transport request that must be approved before release to quality assurance.
- A basis team separates configuration transports from custom code transports so that production promotion can be staged and audited.
- An operations team reviews transport logs after an unexpected job failure to determine which object changed, who released it, and whether the target system received the correct version.
- A security team correlates a transport containing RFC-enabled logic with service-account activity to check whether the change expands machine-to-machine trust.
- Change managers use the transport history to support evidence collection for access review and release governance, similar to the structured visibility guidance discussed in the Ultimate Guide to NHIs and the NIST change-management intent within NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
ABAP transport requests matter because they create the governance boundary between an approved change and an uncontrolled one. In SAP estates, a poorly controlled transport can introduce new privileged pathways, alter background job behavior, or weaken the guardrails around service accounts and technical users. That makes the transport record part of the identity-control surface, not merely a deployment record.
The NHI risk is amplified when transport approvals and production access are loosely connected. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which is why change control must account for what code or configuration can execute after promotion. When transport handling is weak, organisations lose the ability to prove whether an automated action was intended, reviewed, and safely released. That gap aligns with the broader governance expectations described in NIST Cybersecurity Framework 2.0, especially around access control, change assurance, and auditability.
Organisations typically encounter the risk only after an unauthorized production change, at which point transport request lineage becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Change provenance and privileged execution paths affect NHI governance and traceability. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and approval boundaries govern who can move changes into production. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust emphasizes verifying each change path before it reaches a sensitive runtime. |
| NIST SP 800-63 | AAL2 | Strong operator authentication is needed where transport approval gates protect production. |
| CSA MAESTRO | Agentic workflows need controlled promotion, lineage, and execution guardrails. |
Track who released each transport and restrict privileged changes to approved, auditable workflows.
Related resources from NHI Mgmt Group
- Why does MCP transport design create new risk when headers and request bodies can disagree?
- What is the difference between network trust and request-level identity trust?
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?
