Introducing SAP ICF Services: Concepts and General Considerations
Last Updated: 1/5/2026
The Internet Communication Framework (ICF) is an integrated component of the SAP Application Server that acts as the interface between the Internet Communication Manager (ICM) and HTTP-enabled ABAP applications. While the ICM handles the physical connection to the internet, the ICF serves as the logical entry point for processing requests, configured via transaction SICF.
Because every active ICF service represents a potential attack surface, managing this layer is a critical component of SAP security. Improper configuration can allow unauthorized access to sensitive data or functionality directly via the web.
Related SAP Tables
There are two SAP tables related to ICF services. The first one is ICFSERVICE, which has two main columns: one to indicate the ICF service name, and another one to indicate its parent (see more information about ICF parents in the paragraph below). The second one is ICFSERVLOC, which has the same main columns as the previous table, and one extra column that indicates whether a service is active or not.
What Is the ICF Tree?
In transaction SICF you can see an ICF tree. There, it can be assumed that each ICF service has a parent and respects a hierarchy. When you create one, its location in the tree determines the path from which you can access it from a web browser. For example, for ICF service ITMVC2, the path is /sap/bc/bsp/sap/itmvc2 and the URL to use that service is <HOST>:<ICM_PORT>/sap/bc/bsp/sap/itmvc2. Of course, that node must be active to allow calls to that URL.
The ICF tree is built based on the information from the two tables mentioned before. It’s important to highlight that some ICF services may have the same name, however, their parents are not the same. Therefore, we can affirm that when being built, the ICF tree uses both main columns (name and parent id) to make sure which service is active. As an example, please see below image which shows two services with the same name, but under different parent nodes:
What Services Should Be Deactivated?
When an SAP AS ABAP is deployed, every ICF service is available, but in an inactive state. Having all services deactivated reduces the surface of possible attacks. Afterward, each SAP customer should decide which service to activate.
To know if ICF services are active or not, The Onapsis Platform has several vulnerability assessments that could be run to check those services. Also, there is a vulnerability assessment to retrieve the list of all ICF services that are enabled.
ICF Security Risks
Every ICF service that is active could potentially represent a security risk. It can be accessed directly from the Internet by HTTP protocol. Only the needed ICF services must be active and for specific users with restrictive authorizations.
Be careful with some services that do not require authentication, as all of them must be reviewed, including services with stored logon data. At Onapsis, we also have a vulnerability assessment to check if there is any ICF service with stored logon data. Contact us today for more information.
The authorization object that allows you to call an URL of an ICF service is S_ICF, so roles or profiles containing it should be assigned only to users that need it.
ICF services vs SAP Security Baseline
SAP Security Baseline is a document where it is detailed all the security settings that we should configure in our SAPs to be secure.
Regarding ICF services, it states everything we have already mentioned in this blog and the following two extra points:
- Review the ICF services which do not require authentication and use the report RSICFCHK
- As mentioned in several SAP Security Notes (#626073, #1394100, #1417568, #1422273, #1487606), the following services should be deactivated:
- /sap/bc/echo
- /sap/bc/FormToRfc
- /sap/bc/report
- /sap/bc/xrfc
- /sap/bc/xrfc_test
- /sap/bc/error
- /sap/bc/webrfc
- /sap/bc/soap/rfc
- /sap/bc/bsp/sap/certreq
- /sap/bc/bsp/sap/certmap
- /sap/bc/gui/sap/its/CERTREQ
- /sap/bc/gui/sap/its/CERTMAP
- /sap/bc/bsp/sap/bsp_veri
- /sap/bc/bsp/sap/icf
- /sap/bc/IDoc_XML
- /sap/bc/srt/IDoc
Inconsistencies in the ICF Tree and How to Fix It
When creating or deleting an ICF service’s node from the SICF tree, it should be changed in the source system and then transported to every system in the same landscape. This should keep the consistency in the ICF service hierarchy.
Some actions that should not be done to avoid inconsistencies are, for example, transporting a node from outside the landscape or manually create an ICF node in a system that is not the source one. Such actions could create inconsistencies in the ICF structure, which could lead to malfunction of transaction SICF, unexpected behavior of an ICF service, or even missing an ICF service. The following is an example of a corrupted system where ICFSERVLOC table has one more register of an ICF service called “ICF” with its Node Parent ID being “0N4PS1S4RGLHN7IW9R54I61RZ”. This will cause inconsistencies in the ICF tree because both main tables have different quantity of entries:
In case you need to check for any inconsistencies, SAP provides a report called ICFTREE_CONSISTENCY. Afterward, to fix the inconsistencies found, the function module REPAIR_HTTPTREE will reorder the “lost nodes” and delete the services that do not appear in the two tables we have mentioned before in this blog. If you need any of the deleted services in that system, you should transport them from the source system again.
Conclusion
At Onapsis, we are committed to providing our customers with the best recommendations and solutions for the security of their SAP systems. Good use of ICF services is important to avoid inconsistencies, and it assures integrity between the affected tables. As mentioned before, SAP recommends not only in its Security Baseline, but also in related security notes, the importance of maintaining those services.
Learn more about how The Onapsis Platform can protect your business-critical applications.
Frequently Asked Questions (FAQs)
What is the difference between ICM and ICF in SAP?
The Internet Communication Manager (ICM) communicates directly with the internet via HTTP/HTTPS protocols. The Internet Communication Framework (ICF) sits between the ICM and the ABAP stack, acting as the processing layer (or entry point) for those HTTP requests into the ABAP applications.Which SAP transaction is used to manage ICF services?
Transaction SICF is used to create, configure, and activate/deactivate ICF services. In this transaction, services are organized in a hierarchical tree structure, where the path in the tree determines the URL used to access the service (e.g., /sap/bc/bsp/).
Which ICF services should be deactivated for security?
As a general rule, all ICF services should remain inactive unless specifically required for business operations to reduce the attack surface. Specific services that are often recommended for deactivation include test and demo nodes like /sap/bc/echo, /sap/bc/xrfc, /sap/bc/error, and /sap/bc/soap/rfc. Regular vulnerability assessments can help identify enabled services that should be closed.
How do I check for inconsistencies in the ICF tree?
Inconsistencies between the ICF tables (ICFSERVICE and ICFSERVLOC) can occur due to improper transports or manual creation of nodes. SAP provides the report ICFTREE_CONSISTENCY to check for these errors. To fix them, administrators can use the function module REPAIR_HTTPTREE to reorder lost nodes or delete invalid entries.
What are the risks of active ICF services?
Active ICF services can be accessed directly from the internet via HTTP. If services do not require authentication (Anonymous Logon) or contain stored logon data, they can be exploited by attackers to bypass authentication controls. These configurations should be reviewed regularly as part of your SAP vulnerability management strategy.