Teams should treat RFC permissions as high-risk identity scope, not just transport access. Remove broad S_RFC grants, eliminate wildcard function access, and restrict technical users to named modules that match their business purpose. The safest model is least-privilege invocation with continuous review of destinations, trusted relationships, and privileged technical accounts.
Why This Matters for Security Teams
RFC is not just a transport mechanic in SAP; it is an identity and authorization boundary that can expose powerful function modules, privileged technical users, and trusted system relationships. When teams leave broad S_RFC access in place, they often create a path from a low-friction integration account to highly sensitive business functions. That is why the risk profile resembles non-human identity sprawl more than ordinary application access. NHI Management Group has repeatedly shown that hidden identity risk is a core control gap, including in the Ultimate Guide to NHIs — Why NHI Security Matters Now and the Top 10 NHI Issues.
Security teams often underestimate RFC exposure because the privilege is embedded in technical configuration rather than surfaced as a classic user entitlement. That makes it easy to miss in reviews, especially when access has accreted through years of basis administration and integration work. The control problem is familiar across identity domains: according to NIST Cybersecurity Framework 2.0, access governance only works when permissions are continually aligned to current business need. In practice, many security teams discover RFC misuse only after an integration account has already been used to enumerate or invoke functions it should never have reached.
How It Works in Practice
The safest approach is to treat each RFC-capable account as a workload identity with tightly bounded purpose, not as a shared technical convenience. Start by inventorying every destination, trusted relationship, and technical user that can invoke RFC-enabled functions. Then classify those calls by business purpose and remove any wildcard or broad function access that is not explicitly required. In SAP environments, the most important question is not “can this account connect?” but “which named modules should this identity be able to call, and why?”
In practice, teams reduce risk by combining least privilege with continuous review. That means separating administrative access from operational integration access, limiting trusted RFC relationships to specific source systems, and ensuring technical users cannot pivot into unrelated business processes. The same principle appears in broader NHI guidance from 52 NHI Breaches Analysis, where exposed identity pathways often become the real entry point rather than the application itself. For governance, map RFC accounts to ownership, rotation, and offboarding processes just as you would for APIs, service accounts, or secrets. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it frames why unmanaged technical identities keep accumulating excess privilege.
- Remove generic or wildcard S_RFC access unless a documented exception exists.
- Bind each technical account to a named business service and owner.
- Review RFC destinations and trusted RFC relationships on a fixed cadence.
- Revoke dormant or duplicate technical users quickly, not at the next annual audit.
- Log and alert on unusual module invocation patterns, especially privileged function calls.
These controls tend to break down in highly customized SAP landscapes where many interfaces depend on legacy shared users and undocumented function dependencies.
Common Variations and Edge Cases
Tighter RFC control often increases operational overhead, requiring organisations to balance security hardening against interface stability and support burden. That tradeoff is especially real in older SAP estates, where business-critical integrations may fail if teams remove access too aggressively. Current guidance suggests phasing changes rather than making a single large cutover, because undocumented dependencies are common and a rushed cleanup can disrupt payroll, procurement, or data replication.
There is no universal standard for this yet, but the practical direction is clear: every exception should be explicit, time-bound, and owned. In mixed landscapes, some RFC users are effectively batch integrations, while others behave like privileged administrative bridges. Those should not be governed the same way. Teams should also distinguish between a low-risk read-only call and a function that can change master data, trigger workflows, or reach sensitive transaction paths. The more a destination can alter state, the more it should be treated as privileged identity scope. That aligns with the broader risk posture described in NIST CSF 2.0 and in NHI-focused research such as the The 52 NHI breaches Report, which reinforces that overlooked machine identities are often the fastest route to material compromise.
In practice, the hardest cases are third-party connections, cross-system trust chains, and emergency break-glass accounts, where business pressure frequently keeps excessive access alive long after the original need has passed.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | RFC accounts are non-human identities that often retain excessive privileges. |
| NIST CSF 2.0 | PR.AC-4 | RFC permissions are access rights that should be managed and reviewed continuously. |
| NIST AI RMF | The risk is identity governance for autonomous technical access, requiring ongoing oversight. |
Inventory RFC identities, remove wildcard access, and enforce least privilege with owner review.
