CIO Playbook: Mitigating Indirect Access Risks in SAP ECC & S/4HANA

CIO Playbook: Mitigating Indirect Access Risks in SAP ECC & S/4HANA

Indirect Access Defined: Indirect (or “digital”) access refers to any scenario where SAP’s core (ECC or S/4HANA) is used by people or processes through a non-SAP application or interface.

In practice, this covers CRM/portal users, bots, IoT devices, and other devices that trigger SAP transactions without logging into SAP directly.

Under SAP’s licensing rules, any such use still counts as “use” of SAP software​. In audits, SAP looks at interfaces (RFC/API accounts, middleware, web services, etc.) and holds that if an external process causes the ERP to “activate processing capabilities” (for example, creating or updating SAP documents), a license is required.

(One narrow exception is a true “static read”: e.g., a scheduled data export by a licensed user where no updates or triggers occur – SAP’s policy is that such strictly one-way reads do not require extra licenses​.)

Real-World Examples: SAP considers many modern integrations as indirect access. Common scenarios include:

• CRM/Portal to ERP: A sales team enters orders in Salesforce (or another CRM) that are automatically sent to SAP as sales orders. End users never interact with the SAP GUI, but SAP processes their orders.
• E-Commerce and B2B Portals: An online store or partner portal retrieves inventory and prices from SAP and posts new orders back into SAP. Shoppers or service reps drive SAP data indirectly.
• Warehouse & Logistics Systems: A WMS or barcode-scanning system queries SAP for stock levels or posts goods movements. For example, mobile barcode scanners update SAP inventory via middleware.
• HR/Payroll Systems: A cloud HR/payroll system updates employee or cost data in SAP’s HR module or vice versa. Changes flow through interfaces rather than SAP screens.
• Mobile/IoT/Partner Apps: Custom mobile apps or IoT devices (e.g., maintenance sensors, facility monitors) that use SAP APIs to create notifications or update asset data. RPA bots are a special case: if an RPA robot reads from or writes into SAP, SAP treats the bot user as an indirect user​.
• Finance Integrations: Third-party billing or treasury systems push invoices, payments, or journal entries into SAP. For instance, a bank integration that sends payment confirmations into SAP triggers the creation of new financial documents.

In each case, SAP’s position is that the external system is leveraging SAP’s intellectual property – the ERP is doing work on behalf of end users – and thus, licenses are due.

The infamous SAP vs. Diageo case (2017) reinforced this: a court held that Diageo’s Salesforce-driven orders constituted unauthorized use of SAP, exposing Diageo to significant fees.

Afterwards, SAP introduced the Digital Access model to clarify billing, but even under that model, every indirect business document created by an external system still incurs a charge (see below).

Legacy vs. Digital Access Licensing

SAP now offers two parallel models for indirect usage. In the legacy (user-based) model, every person or system account that directly or indirectly drives SAP is supposed to have a named user license.

In practice, this means that each CRM user, portal user, service account, RPA bot, and so on that triggers a license, such as Professional, Limited Professional, or Employee Self-Service, must be covered by SAP.

This model gives each licensed user unlimited transactions, but it is hard to enforce: companies often undercount, assign generic or middleware licenses, or only discover gaps at audit time. If a user’s license type is unknown, SAP typically assumes the most expensive (e.g., Professional)​.

By contrast, SAP’s Digital Access (document-based) model (introduced in 2018) charges only for business documents created in SAP by external systems. There are nine core document categories, such as sales orders, purchase orders, invoices, deliveries, and service/maintenance orders​.

Each time an external system creates one of these documents in SAP, it counts against the Digital Access license pool. Updates or reads of existing documents do not incur additional charges.

Bundles of documents are sold (e.g., blocks of 1,000) with volume discounts. This model eliminates the need to track every external user; instead, you focus on volumes of output.

Table 1. Licensing Models: Legacy vs. Digital Access

Under either model, CIOs must stay vigilant. Even with Digital Access, SAP expects customers to purchase sufficient entitlements for expected document growth. (SAP’s adoption program has offered incentives to switch, but you must accurately forecast document counts or risk overages.)

Governance Strategies for Indirect Access

• Inventory All Integrations: Build and maintain a catalogue of every third-party system, interface, or API that connects to SAP​. Include middleware platforms, cloud services, batch feeds, EDI channels, mobile apps, etc. Record the purpose (e.g., “Order import from CRM”), the SAP technical users/accounts involved, and the business owners. This visibility is the foundation of control.
• Assign Ownership: Designate a license compliance owner, often part of IT/SAM or a CIO office, to oversee indirect access. That role should liaise with SAP Basis, security, and line‑of‑business leads. Maintain an Indirect Access Risk Register that lists each interface, its license risk (e.g., volume of use, unresolved license gaps), and mitigation status. Update it regularly as projects add or retire connections.
• Integrate into IT Governance: Make licensing impact a formal checkpoint for any new SAP integration or interface project. Require architects to assess license implications (named vs. document) during design reviews. For example, when adopting a new eCommerce platform or RPA solution, include a review of “SAP access licensing”. By baking indirect‑access checks into portfolio governance, you avoid surprises.
• Monitor Continuously: Don’t wait for SAP to audit you. Treat indirect access tracking as an ongoing internal audit/ITAM task​. Regularly run SAP’s usage reports (USMM/LAW) and new notes/scripts to see which interfaces and technical users are active. Map each interface’s system ID to the SAP logs: If your CRM uses an RFC user named “CRM_INTERFACE,” check which transactions or documents it generates. Look for anomalies, such as very high document counts from a few service accounts.
• Document and Report: Maintain clear documentation of indirect flows (“System A creates X orders per month in SAP”). Use dashboards or reports (SAP or third-party tools) to track volumes by interface. These data help in audits or negotiations. For example, if SAP audits your system and asks about “Salesforce orders,” you can show metrics and prove they were created under a block purchase. Also, ensure that all interface user accounts are properly classified in SAP (e.g., “Business” or “Application” types, not generic “human”) to make reports accurate.
• Establish Controls: Require formal change control for any new SAP integration. New interfaces should only go live after license review and account provisioning. Educate project teams: emphasize that indirect access isn’t an “automatic free ride.” Update internal policies to state that adding any automated SAP feed requires oversight of licensing. This institutionalizes awareness and prevents unauthorized growth​.

Technical Controls and Monitoring

• Use Middleware/Hubs: Where possible, funnel all external connections through a centralized integration platform, such as SAP PI/PO, CPI, or MuleSoft. This allows you to govern and throttle usage in one place. For each distinct interface, create a dedicated service user account in SAP, rather than using ad hoc IDs. That way, you know exactly which account corresponds to which upstream system.
• Segregate Accounts: Keep system or service accounts separate from human user IDs. In SAP, classify interface users as technical or “BI” users. Do not let multiple people share an SAP user account, and avoid allowing third-party apps to call SAP under individual named-user logins, as this defeats segmentation. Assign minimal roles to each service account: e.g., only the specific BAPI or OData calls needed. This reduces unnecessary document creation and makes auditing cleaner.
• Logging and Auditing: Enable extensive logging of interface activity. Many middleware tools let you log every call and response. In SAP, use the Audit Information System or solution manager to report on external RFC/API calls. SAP’s newer Passport technology (if available) can tag calls from non-SAP sources​. Log volumes and errors: A surge in API errors may indicate a misconfigured integration that is spamming SAP. Review these logs regularly for spikes in document creation or unauthorized access attempts.
• Monitor Performance: Use monitoring tools, such as SAP Cloud ALM for Integration Suite or third-party APM, to track integration flows. Unexpected increases in interface activity can signal a new indirect‑access hotspot. For example, if a batch job was mis-scheduled to run hourly instead of daily, you could be generating ten times the licensable documents.
• Technical Authorization Controls: Implement role-based security even on service accounts. For example, when using a barcode scanner for inventory updates, give the scanner account only “Goods Movement” authorization, not full sales-order access. This prevents an interface from inadvertently triggering unrelated transactions.

Best Practices (Traditional/User Model)

For SAP customers still under a user‑license regime (not yet on Digital Access):

• Scope and Throttle Interfaces: Limit access to SAP data from external systems. For instance, configure the CRM so that only sales clerks can push orders, not all client-facing users. If a third-party system has multiple logins, consolidate or restrict them to only the ones needed. In practice, some customers license a small pool of “middleware” users to cover many indirect users – this can work, but must align with SAP’s terms.
• Favour Asynchronous/Static Reads: Where real-time access isn’t needed, use scheduled exports. SAP allows Indirect Static Read scenarios without extra license if all criteria are met​ (data is pre-fetched by a licensed user on schedule, and no updates or triggers occur). For example, instead of a portal querying SAP in real-time, have SAP dump needed data nightly to the portal database. Carefully document such processes to prove they meet the static-read rules.
• Appropriate License Types: Assign SAP licenses to interface users carefully. If an external user only views data (e.g., via a portal), an SAP Employee Self-Service license might suffice. For integration users (like an RPA or scanner), you may need a “Service” or a minimal Professional license. Avoid defaulting to giving a full Professional license to all interface accounts.
• Eliminate Duplication: If a real person has an SAP license, there’s no need to license them again via a connector. For example, if an internal user logs in to SAP Fiori and also uses a connected mobile app, only one license is required. Remove any duplicate accounts. Conversely, if multiple people share a single service account, that violates the terms – each indirect user should be covered by a license if using SAP data.
• Contractual Safeguards: Before renewing or expanding, negotiate clarity in contracts. Demand definitions of “indirect use” and carve-outs for static reads​. Ensure that old contracts don’t suddenly allow SAP to retroactively count documents. If you extend ECC or move to S/4HANA on-premises, lock in the terms for how indirect access will be measured or capped.
• Audit Readiness: Conduct regular internal license audits. Simulate SAP’s audit (run USMM/LAW plus any indirect-use notes) and review for “smoking guns” (e.g., a small number of interface users generating huge volumes). Correct issues on your terms before SAP asks. In audits, be prepared to explain your architecture and have data available (“System X generates Y records per period, covered by Z license bucket”).

Best Practices (Digital Access Adoption)

For organizations that have (or plan to) adopt SAP’s Digital Access model:

• Track Document Consumption: Establish regular reporting on digital document volumes. Use SAP tools (LICENSE ADMINISTRATION WORKBENCH/LAW, usage reports, or the SAP Passport trace) to count how many Sales Orders, Purchase Orders, Delivery documents, etc., are created by interfaces. Create dashboards or reports that show trends by document type and integration source. (Remember, only the creation event counts – editing or querying a document does not trigger a new charge​).
• Know What Triggers Licenses: Understand which interactions generate billable documents. There are nine categories (e.g., sales, purchases, invoices, manufacturing orders, service orders, quality notifications, time confirmations, financial postings, and material documents). For example, posting a new invoice via a non-SAP billing app will count, but simply reading an invoice does not. Configure interfaces to avoid unnecessary document creation (e.g., don’t create duplicate documents “just in case”).
• Use SAP’s tools: Run SAP’s Digital Access Estimation or Passport tools (Notes 2992090 for ECC and 2999672 for S/4HANA) to measure usage. SAP also offers a free Digital Access Evaluation Service to estimate counts. However, treat these as starting points – validate their outputs internally before purchasing licenses. Be aware of tool limitations: for instance, older tools may not distinguish SAP-driven vs external documents, so cross-check your logs.
• Align Purchase to Usage: Only license the volume you need. If possible, use SAP’s adoption programs (e.g., past DAAP options) to buy upfront blocks of documents, then track against that block. Maintain a buffer to allow for growth, but avoid over-provisioning excessively. Negotiate with SAP to define what counts as a “document” in your context (some contracts allow excluding minor doc types or use flat tiers for predictability).
• Optimize Integrations: Even with digital access, limit unnecessary document creation. For example, if a system needs to check stock levels, design it to not create a new Material Document or inquiry record unless necessary. Use custom code or middleware logic to aggregate transactions (e.g., batch creating one bulk purchase order instead of many small ones). Regularly review whether any interface is generating an unexpected document type.
• Regular Reviews and Audits: Just as in the legacy model, conduct quarterly or semi-annual audits of interface activity. Ensure that any new interface or process that could create SAP records is evaluated for its impact on your digital licenses. Update your documentation (interface catalogue) with any changes. If an unexpected spike in a document type occurs, investigate it immediately; it could signal a new integration or a bug.
• Educate Teams: Train developers and integrators about Digital Access. They should know which SAP APIs or BAPIs create billable documents. Encourage them to implement non-chargeable patterns when possible (e.g., read-only queries, static extracts) and to consult SAP licensing or architecture experts early in design.

CIO-Level Recommendations

• Treat Indirect Access as Enterprise Risk: Elevate indirect access to a board-level IT compliance topic, not just a technical detail. Include it in enterprise risk registers and compliance dashboards. Make sure C-level and finance leadership understand the potential exposure (audits can lead to multi-million-dollar demands). This ensures budget and attention are allocated to compliance efforts.
• Integrate with License Governance: Fold indirect-use management into your overall SAP license governance framework (alongside direct user licenses and engine metrics). Assign a specific owner (or team) with resources to track and manage it. Use automated tools (SAM software), if available, to continuously monitor your SAP estate. Standardize the process: e.g., whenever a new SAP user or interface is provisioned, update the license governance registry.
• Leverage Contracts Strategically: Use contract negotiation to reduce risk. When buying new SAP licenses or renewing maintenance, insist on clauses that protect you (e.g., caps on indirect usage fees, clear definitions, static-read carve-outs)​. Secure rollback or exchange options (e.g., converting unused user licenses to document licenses)​. Do not agree to open-ended terms that allow SAP to charge heavily later. In short, negotiate with data: come prepared with usage reports and forecasts, not just faith.
• Collaborate Across IT and Business: Ensure tight coordination between SAP Basis, security, application teams, and the business units driving integrations. Form a steering committee or regular touchpoint that reviews upcoming integration projects, digital transformation initiatives (IoT, AI, B2B portals, etc.), and their licensing impact. Involve procurement and legal in vendor evaluations (e.g., if selecting a new CRM or SCADA system that connects to SAP, assess license implications in the RFP).
• Invest in Tools and Expertise: Consider third-party audit tools or consulting to supplement in-house capabilities. Many enterprises use SAP License Management tools or engage SAP license specialists to discover hidden interfaces and recommend optimizations. These investments often pay off by avoiding penalties.
• Continuous Education and Training: Keep your organization up to date on SAP’s licensing changes. For example, SAP may alter its definition of indirect access or its DA pricing. Provide refresher training to IT architects and managers so they don’t fall back into old assumptions. A well-informed team is your first line of defence.
• Maintain an Audit-Ready Stance: Before any SAP audit or license review, run your internal checks (“audit the auditor”)​. Have all documentation and usage data in order so that any issues can be explained and resolved collaboratively. If SAP sales or auditors initiate a discussion about indirect usage, enter negotiations with hard data and, if necessary, consult with legal or licensing counsel, rather than going on the defensive.

By treating indirect access as a managed compliance program – with clear inventory, policies, monitoring, and executive oversight – CIOs can turn a potential audit risk into a predictable governance process.

The goal is not only to avoid surprise license bills, but also to align SAP access rules with the company’s digital strategy, enabling innovation (e-commerce, IoT, automation) without incurring unexpected costs.