Mobile apps and SAP indirect access

Mobile applications are an under-recognised source of SAP indirect access exposure. A field-service app that lets technicians close work orders. A sales app that creates quotes on a tablet. An expense app that posts receipts into Concur. An employee self-service app that updates HR records in SuccessFactors. Each of these mobile experiences sits on top of SAP records, and each user of the mobile experience is a user of SAP — whether or not they have a named user license in the SAP master agreement. The exposure rarely shows up in a USMM run because the USMM only counts users who have a named SAP account. The mobile users do not. They authenticate through a mobile identity provider, hit an API gateway, and consume SAP data through a middleware layer. The audit team sees them. The buyer often does not.

Why mobile apps create indirect access exposure

The licensing principle that governs mobile-app exposure is the same principle that governs all SAP indirect access: anyone who consumes the value of SAP data or functionality, directly or indirectly, requires a license. The mode of consumption — desktop client, browser, mobile app, API call — does not change the principle. What changes is the visibility. Desktop and browser users show up in the USMM. Mobile users do not. The exposure is in the gap.

The framing matters because SAP's audit team is increasingly skilled at identifying mobile-app populations during the audit cycle. The standard techniques are documented in the middleware risk article: connection logs, API gateway traffic analysis, mobile-identity-provider user counts, and the integration-topology questionnaire. Across our engagements, the mobile-app population is one of the three highest-exposure categories in the indirect access settlement.

The five mobile-app patterns

Mobile-app exposure breaks into five common architectural patterns. Each has a different exposure profile and a different defensive posture.

• Native mobile app with named SAP backend — every mobile user maps to a defined named-user license. Lowest exposure, highest control.
• Native mobile app with shared SAP service account — mobile users authenticate through a mobile identity provider; all SAP calls run under one service account. Highest exposure, no named-user mapping.
• Web-wrapped mobile app — a responsive web application served through a mobile wrapper, with each user having a defined SAP front-end account. Moderate exposure, depends on whether the SAP account is a Professional Use, Limited Professional, or Employee Self-Service license.
• Third-party mobile app consuming SAP via an integration platform — Salesforce mobile, Microsoft Dynamics mobile, ServiceNow mobile. Exposure depends on the read/write pattern.
• Custom mobile app on SAP Mobile Services or SAP BTP — depends on the licensed runtime and the underlying data access pattern.

The service-account pattern in detail

The highest-exposure pattern is the service-account architecture. The mobile app authenticates the user against an external identity provider (Azure AD, Okta, a corporate IdP), retrieves an SAP session through a shared service account, executes the user's transactions against SAP under that account, and returns the result. From SAP's perspective, all activity comes from one user. From the buyer's perspective, the mobile workforce is consuming SAP. The audit position SAP takes is that each mobile user is a separate SAP user requiring a separate license. The buyer's defensive position depends on whether the mobile users would qualify for one of the lower-cost license categories — Employee Self-Service, Limited Professional Use — rather than the full Professional Use category SAP defaults to in the opening claim.

The license-category argument is fact-specific. A mobile expense app with thousands of casual users typically qualifies for ESS. A mobile field-service app with hundreds of technicians closing work orders typically qualifies for Limited Professional Use. A mobile sales app where the user creates orders typically requires Professional Use. The named user buckets article covers the category definitions in detail.

The measurement methodology

The measurement of mobile-app populations runs through the mobile identity provider, not through SAP. The output is a defensible monthly active user count per mobile app, broken out by usage intensity (daily, weekly, monthly active). The SAM team then maps each user count to a candidate SAP license category. The combined deliverable is the mobile-app exposure schedule that the buyer presents in the position paper.

The schedule has three columns: the mobile-app name, the monthly active user count, and the recommended SAP license category with a justification note. The justification note is the substantive defence — it documents what the user does in the app, what SAP data the user touches, and which license category fits. Without the justification note, the opening claim is built on the raw user count at the highest license category. With it, the negotiation reframes around the categorisation. The pattern is documented in the indirect access audit defence white paper.

The third-party mobile question

Where the mobile app is a third-party product — Salesforce mobile, ServiceNow mobile, a Microsoft Power Apps experience — the exposure analysis depends on the read/write pattern. A Salesforce mobile user reading customer-master data from SAP through a daily sync is a different exposure than a Salesforce mobile user creating sales orders in SAP through a real-time API. The first is typically argued as an exempt static-read pattern. The second is typically counted. The Salesforce integration article covers the canonical case in detail.

The digital access overlap

For buyers who have adopted the digital access licensing model, the mobile-app question shifts. Instead of asking "what license category does each mobile user need," the question becomes "how many SAP documents does each mobile app create." The exposure is measured in document volume rather than user count. The shift is generally favourable to buyers with many low-intensity mobile users because the document count is typically lower than the user count would imply. The pattern is described in the indirect-to-digital migration article.

The defensive controls

Three controls reduce mobile-app exposure on an ongoing basis. The first is named-user mapping at the mobile identity provider — every mobile user has a defined identity that can be mapped to a defined SAP license type. The second is usage telemetry — the mobile app logs each transaction with enough metadata to support a license-category argument later. The third is an exemption inventory — read-only mobile patterns, static-data syncs, and exempt categories are documented before the audit, not during it. The controls are part of the broader governance model covered in the compliance governance article.

The settlement structure

In a settlement, mobile-app exposure is typically resolved through a defined population-by-category schedule with a per-year cap and a true-up cadence. The buyer commits to a named-user volume per category for the mobile populations. SAP commits to a defined unit price per category. The schedule includes a true-up procedure for new mobile apps added during the term. The structure is described in the indirect access advisory service page and on the SuccessFactors topic page where mobile ESS exposure is the most common scenario.

If your landscape includes mobile applications consuming SAP — including third-party mobile products like Salesforce or ServiceNow — the place to start is the mobile-app inventory. Each mobile app should appear in the integration-topology questionnaire with a defined exposure category and a defensible volume. The global manufacturer case file includes the mobile-app schedule from that engagement as a reference.