SAP on mobile: identity and offline before the screen

A request for SAP on mobile almost always arrives as a request for an app: “we want to approve from the phone”. And the project starts by picking a tool. Wrong order.

Approving from a phone is the easy part — SAP has shipped that for years. What stalls the project is not on the screen: it is how that phone proves who it is, and what happens when it loses signal mid-transaction.

In one sentence — SAP mobile is an identity and connectivity project, not an interface project. Start with the screen and you deliver a pretty pilot that fails the security review; start with identity and you deliver something plainer that reaches production.

The three routes, and what each one costs

There are three ways to put SAP on a phone, and they do not compete — they solve different problems.

Responsive Fiori in the browser. The cheapest route: the application you already have, opened in the phone’s browser. It works well for approvals and lookups. It does not work offline, does not use the camera or barcode scanner, and depends on the user remembering the address.

SAP Mobile Start. SAP’s own app acting as the front door: it delivers the launchpad on the phone, with notifications and biometrics. It is the honest middle ground — little effort, real adoption gain, and it solves the “remembering the address” problem.

A native or hybrid app, with SAP Mobile Services on BTP. The expensive route, and the only one that solves genuine offline — stock counts in a warehouse with no signal, work orders in the field, collection on the plant floor. If offline is not a requirement, it rarely pays for itself.

Identity is where the project stalls

Corporate phones are rarely domain-joined. That means the authentication that works on the desktop — integrated, silent — does not exist there. And the lazy alternative is a username and password, which no serious security review passes today.

The route that works has three parts, and none is optional.

An identity provider in the middle. SAP delegates authentication to Entra ID, SAP IAS or equivalent. That is what lets you require MFA without teaching SAP to do MFA.

Phishing-resistant MFA. Passkeys or security keys. An SMS code on a financial approval is an invitation — SIM swapping is a common and cheap attack.

Device management. Without an MDM or app protection layer, a lost phone takes the session with it. And the question nobody wants to answer in the steering committee is how long that token stays valid.

Worth watching — device biometrics is not a second factor for SAP. The face or fingerprint unlocks the phone, and the phone presents a token that was already stored there. If that token does not expire and cannot be revoked remotely, biometrics is convenience, not control. It is the most common confusion in these conversations.

Offline is a business decision, not a technical one

The word “offline” in a meeting usually means something different to each person at the table, and it is worth settling before estimating.

Offline lookup — seeing what was already downloaded, changing nothing. It is cheap and covers a good share of field cases.

Offline capture with later upload — record now, sync when there is signal. Here the first hard question appears: what if two technicians record against the same object?

Full offline transaction — with business rules validating on the device. The most expensive, and it forces an answer to what happens when local validation says yes and the server says no.

That third category is where projects stop. Not from technical difficulty: from having no decision about who wins when the two disagree. And that decision belongs to the process, not to IT.

Where AI genuinely helps

In triaging what deserves to go mobile. Cross-checking the transaction log against time and place of use quickly shows what is already being used outside the office — and that list is usually quite different from the one the committee imagined.

Where it does not belong is the sync conflict rule. That is policy, and policy has an owner.

The honest limit

Not everything should go to the phone. A transaction with many mandatory fields, on a small screen, produces bad data — and bad data costs more than the wait it saved.

The rule of thumb that holds up: a phone is good for deciding and for recording; it is bad for composing. Approve, look up, log, photograph — yes. Building a thirty-line purchase order — no.

At Inove this design sits where modern workplace and SAP practices meet: identity on one side, authorisation on the other.

Frequently asked questions

What does SAP on mobile mean in practice?

Three distinct routes: responsive Fiori in the phone browser, the SAP Mobile Start app as a front door, or a custom app with SAP Mobile Services on BTP. Only the third solves genuine offline work, and it only pays for itself when the requirement really is field work without signal.

Do I need BTP to use SAP on a phone?

Not for approvals and lookups — responsive Fiori and Mobile Start handle those without BTP. BTP comes in when there is an offline requirement with synchronisation, custom notifications, or integration with device features such as the camera and barcode scanning.

Does phone biometrics count as a second factor?

Not on its own. Biometrics unlocks the device, and the device presents a token that was already stored. Without short expiry and remote revocation of that token, biometrics is usability comfort rather than access control — and it is the most common confusion in these discussions.

What usually stalls the project?

Identity and sync conflict. Phones are rarely domain-joined, so the silent desktop authentication does not exist there; and once there is offline capture, someone has to decide who wins when device and server disagree. Both are business decisions, not IT ones.

Should every transaction go mobile?

No. A small screen with many mandatory fields produces bad data, and bad data costs more than the wait it saved. The practical rule: a phone is good for deciding and recording, and bad for composing.