They should check that the same business task has the same authorisation boundaries across device types. Responsive design changes presentation, not entitlement. If mobile and desktop paths differ in data visibility, action scope, or approval flow, the organisation has a governance inconsistency that needs to be resolved in the access model.
Why This Matters for Security Teams
When SAP Fiori is used on both mobile and desktop, identity teams should verify that the business task, not the screen size, drives authorisation. A responsive UI can hide or expose controls differently, but entitlement should remain consistent. That distinction matters because access drift often appears as a usability issue first and a governance issue later. NIST’s Cybersecurity Framework 2.0 treats access governance as a core control domain, while NHIMG’s Ultimate Guide to NHIs shows how privileged identities and weak visibility routinely create avoidable exposure. The same logic applies to Fiori: one approval path on desktop and a different one on mobile is not an interface preference, it is a policy decision.
Identity teams should also consider whether mobile access introduces alternate authentication, conditional access, or offline handling that changes the effective control boundary. If a user can approve, view, or export data on one device but not the other, the organisation needs to confirm whether that is intentional segmentation or inconsistent design. In practice, many security teams encounter privilege mismatches only after a mobile workflow has already bypassed the desktop control model, rather than through deliberate access design.
How It Works in Practice
The practical test is simple: map the SAP Fiori business role to the underlying authorisation objects and confirm that each device type invokes the same decision logic. Presentation changes are acceptable; entitlement changes are not. Identity teams should review the full path from login to action execution, including session controls, conditional access, approval routing, and any device-specific API or service calls.
A useful review pattern is to compare the following across mobile and desktop:
- Visible data sets, including whether sensitive fields are masked or omitted
- Executable actions, such as submit, approve, release, post, or export
- Workflow steps, especially if mobile shortcuts bypass a second approver
- Authentication strength, such as MFA, device posture checks, or reauthentication prompts
- Backend authorisation objects, not just UI permissions
Current guidance suggests treating Fiori as part of the identity boundary, not just the application boundary. That means access reviews should validate SAP roles, backend authorisations, and session policy together. If a mobile app uses a different integration layer, identity teams should confirm that the service identity and the user identity are both constrained correctly. NHIMG’s Top 10 NHI Issues is a useful reminder that inconsistent credential and privilege handling usually becomes visible only when the environment is already live. SAP’s own help documentation should be used to verify which authorisation checks are enforced natively versus inherited from the device or access gateway.
These controls tend to break down when mobile access is layered over custom OData services or legacy role design because the UI team, SAP basis team, and identity team often validate different parts of the same workflow in isolation.
Common Variations and Edge Cases
Tighter access parity often increases testing and change-management overhead, requiring organisations to balance consistency against release speed. That tradeoff is especially visible when executives expect mobile convenience but the underlying SAP process was built for desktop-only approval chains.
There is no universal standard for this yet, but best practice is evolving toward task-based authorisation and device-aware assurance, not device-based privilege. If mobile users are allowed to do less, that limitation should be explicit in policy and documented in the role model. If mobile users are allowed to do more, identity teams should treat that as a high-risk exception and require compensating controls.
Edge cases often appear in offline mobile access, shared kiosk devices, bring-your-own-device programmes, and app versions that lag behind the desktop client. Another common exception is delegated approval, where the mobile experience is technically valid but operationally broader than the desktop path. NHIMG’s 52 NHI Breaches Analysis shows the recurring pattern: once identity boundaries differ across channels, assurance breaks down faster than teams expect. Organisations should document any deliberate asymmetry, then re-test it after each role, app, or transport-layer change.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Access governance must stay consistent across mobile and desktop paths. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Inconsistent auth paths can create over-privileged identities and hidden exposure. |
| NIST AI RMF | Contextual, risk-aware decisions fit the need to evaluate device and task context. |
Use context-aware policy checks to confirm device type never changes the authorised business action.
