The permission model that governs whether an SAP system accepts callback activity during remote function calls. If it is too broad, an allowed destination can become a larger execution path than the business case requires, creating a hidden privilege expansion route.
Expanded Definition
RFC callback trust describes the permission boundary SAP uses to decide whether a remote function call can trigger callback activity back into a trusted destination. In practical NHI governance, it is less about the remote call itself and more about whether the callback path is allowed to execute with an authority level that exceeds the original business purpose.
This matters because callback trust can transform a narrowly scoped integration into a broader execution path, especially when the destination is treated as implicitly trusted across interfaces, RFC destinations, or background processing chains. Guidance across vendors is not fully standardised, so teams should treat callback trust as an access-control decision that must be reviewed alongside NIST Cybersecurity Framework 2.0 concepts for access governance and monitoring. NHI Management Group treats this as an identity and privilege design issue, not just an SAP transport setting. The most common misapplication is allowing callback trust broadly for convenience, which occurs when interface teams enable it for testing and never narrow it for production.
Examples and Use Cases
Implementing RFC callback trust rigorously often introduces integration friction, requiring organisations to weigh system reliability against the cost of tighter destination controls and more frequent change management.
- A finance system permits callback activity only for a named technical destination, preventing a generic RFC path from being reused by unrelated jobs.
- An SAP landscape uses callback trust during a controlled batch process, but the destination is paired with strict monitoring and documented ownership, as recommended in the Ultimate Guide to NHIs.
- A migration team temporarily enables callback trust for a cutover window, then removes it after validating the integration path against NIST Cybersecurity Framework 2.0 access controls.
- A supplier portal integration is denied callback trust because the third-party use case does not require execution back into the core SAP system, reducing unnecessary NHI exposure.
- A security review identifies that a callback destination was reused across multiple interfaces, so ownership and allowed operations are split before production release.
Why It Matters in NHI Security
RFC callback trust is significant because it can silently widen the effective permissions of a service account, integration user, or technical destination without changing the visible business workflow. That creates a hidden privilege expansion route, which is exactly the kind of NHI weakness that turns ordinary automation into an attack path.
NHIMG research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, and callback trust can be one of the mechanisms that makes those privileges operationally real rather than merely theoretical. When callback paths are overtrusted, investigators may find that a benign interface account can reach downstream systems, trigger secondary actions, or touch data beyond its intended scope. This is why callback trust should be reviewed with the same discipline used for secrets handling, destination ownership, and least privilege. It aligns with the broader guidance in the Ultimate Guide to NHIs, especially where visibility and privilege reduction are concerned. Organisations typically encounter the risk only after an unexpected transaction, unauthorised callback, or audit finding exposes how far the trusted path could really execute.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Callback trust can expand NHI execution paths beyond intended privilege boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and least privilege govern whether callback activity is allowed. |
| NIST Zero Trust (SP 800-207) | Zero trust treats every callback path as explicitly authorized, not implicitly trusted. |
Restrict trusted callbacks to named destinations and review every path for privilege creep.
