RFC is SAP’s mechanism for calling functions across systems and trusted integrations. In practice, it becomes a governance concern when technical users can invoke sensitive modules with more privilege than their business role justifies, because the call path itself can carry the attack.
Expanded Definition
Remote Function Call, or RFC, is SAP’s established mechanism for invoking functions across systems and trusted integrations. In NHI governance, the key issue is not the transport alone but the authority attached to the technical identity that sends the call. When an RFC-enabled user, service account, or integration token can reach sensitive modules, the call path can bypass the business intent behind role design.
Definitions vary across vendors and SAP-adjacent tooling, but the governance principle is consistent: the caller’s technical reach must be constrained to the minimum functions needed, and the destination system must treat each invocation as a privileged action. That makes RFC closely aligned with least privilege, segmentation, and auditability as described in the NIST Cybersecurity Framework 2.0. For NHI teams, RFC is best understood as a trust boundary that can expand silently when technical users are over-entitled, especially across ERP, middleware, and third-party connectors.
The most common misapplication is treating RFC access as a harmless plumbing detail, which occurs when teams grant broad technical permissions because the function is “only for integration.”
Examples and Use Cases
Implementing RFC rigorously often introduces configuration and monitoring overhead, requiring organisations to weigh integration speed against the cost of tighter authorization design and traceability.
- A finance integration uses RFC to create vendor records, but the technical user also has authority to change payment terms, creating an NHI risk if the call path is abused.
- An SAP background job invokes RFCs during overnight processing, and the account behind the job should be restricted to the exact modules needed for batch execution.
- A third-party monitoring platform connects through RFC to read operational data, but excessive authorisations could let it trigger business logic instead of only retrieving status.
- An audit finds that RFC destinations are shared across teams, which prevents clear attribution when a sensitive function is called and complicates incident review.
- The Schneider Electric credentials breach illustrates how technical access paths can become security events when privileged credentials are exposed or reused across systems.
For implementation context, RFC controls should be evaluated alongside identity design guidance in the NIST Cybersecurity Framework 2.0, especially where system-to-system access must remain attributable and bounded.
Why It Matters in NHI Security
RFC matters because it is often the mechanism through which non-human identities reach core business functions. If the technical identity behind an RFC connection is over-privileged, then compromise of that identity can become direct access to sensitive workflows, master data, or operational controls. This is why RFC belongs in the same governance conversation as secrets management, service account review, and privileged access controls.
NHI Management Group reports that 97% of NHIs carry excessive privileges, a statistic that helps explain why integration paths such as RFC deserve scrutiny rather than trust by default. When RFC credentials are stored poorly, rotated infrequently, or shared across teams, the blast radius can extend well beyond the original system owner. The same pattern shows up in incident response, where a connector or batch account is discovered only after suspicious transactions, failed audit trails, or abnormal module execution. The strongest operational reference point is NHI visibility, because the organization cannot secure what it cannot inventory, monitor, or revoke.
Organisations typically encounter RFC risk only after an integration account is abused or a sensitive module is called unexpectedly, at which point RFC governance 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 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-02 | RFC abuse often stems from overprivileged technical identities and weak secret handling. |
| NIST CSF 2.0 | PR.AC-4 | RFC is a system-to-system access path that must be governed by least-privilege access controls. |
| NIST Zero Trust (SP 800-207) | SC-7 | RFC traffic should be treated as a trust-boundary crossing that needs explicit segmentation. |
Restrict RFC-connected identities to minimum required functions and review their secrets and entitlements.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
