Yes, where expert workflows, custom transactions, or legacy dependencies still require it. The mistake is treating GUI as automatically obsolete and leaving it unmanaged. If it remains in production, it should be narrowly scoped, recertified, and linked to the same governance process as Fiori access.
Why This Matters for Security Teams
Moving to Fiori does not automatically eliminate the risk surface created by SAP GUI. Many organisations still have custom transactions, expert-user workflows, background jobs, and legacy integrations that depend on the classic client. The real decision is not whether GUI is modern enough, but whether its remaining use is intentionally governed. That means scoped access, explicit ownership, and review processes that match business criticality.
This is especially important because identity sprawl and privileged access creep tend to persist long after a platform migration. NHI Mgmt Group notes in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, which is a useful reminder that legacy access often lingers with more power than it needs. The same pattern applies when SAP GUI remains in production without tight controls. OWASP’s OWASP Non-Human Identity Top 10 also reinforces that unmanaged machine and privileged access is a recurring failure mode across enterprise environments.
In practice, many security teams discover SAP GUI is still operational only after a review, audit finding, or outage forces them to trace dependencies they had assumed were already retired.
How It Works in Practice
The practical approach is to treat SAP GUI as a controlled legacy access path, not a default fallback. That starts with inventory: identify which users, service accounts, and teams still need GUI, then map each use case to a specific business justification. If a workflow can run in Fiori, GUI should usually be removed. If it cannot, access should be narrowed to named roles, expert users, or break-glass scenarios with documented approval.
From there, apply the same governance discipline used for other sensitive identities. Review entitlements regularly, enforce segregation of duties, and verify that privileged transactions are not broadly assigned through old composite roles. This aligns well with the guidance in the Ultimate Guide to NHIs — Key Challenges and Risks, which highlights why hidden privilege and weak visibility are common control failures. It also fits the direction of OWASP Non-Human Identity Top 10, where lifecycle discipline and least privilege are central themes.
- Keep only the minimum SAP GUI users needed for unresolved dependencies.
- Pair access with recertification and business-owner sign-off.
- Use time-bound elevation for sensitive transactions where possible.
- Log and review GUI activity with the same scrutiny applied to Fiori.
- Retire GUI access when the last dependency is remediated.
Where organisations get this wrong is assuming the Fiori rollout itself is the control. These controls tend to break down in heavily customised SAP landscapes because old transactions, transports, and role designs survive the migration even when the user interface changes.
Common Variations and Edge Cases
Tighter SAP GUI restriction often increases operational overhead, requiring organisations to balance user convenience against auditability and change control. That tradeoff is unavoidable in environments with regulated processes, warehouse operations, finance close activities, or plant-floor dependencies where Fiori coverage is incomplete. Current guidance suggests using exception-based access rather than broad permanent permission, but there is no universal standard for exactly how much GUI access is acceptable.
The main edge case is when GUI is needed not for end users, but for administrators, developers, or support personnel who maintain custom ABAP objects, troubleshoot authorisations, or execute emergency fixes. In those cases, access should still be isolated, logged, and reviewed, not treated as exempt simply because the user is technical. Another edge case is third-party support, where vendor users may require temporary GUI access for break-fix work. That access should be time-limited and revoked immediately after use, consistent with lifecycle controls described in the Ultimate Guide to NHIs.
Industry consensus is clear on one point: if SAP GUI remains, it must be governed as an active production access path, not left as a convenience layer. Where business owners cannot explain a current dependency, removal is usually the safer default.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Legacy SAP GUI access behaves like privileged identity sprawl when not tightly scoped. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be reviewed and limited to current business need. |
| NIST AI RMF | Governance must account for runtime access decisions and changing operational context. |
Inventory every SAP GUI identity, remove unused access, and enforce least privilege for the remainder.
Related resources from NHI Mgmt Group
- Should organisations keep classic PAM if they are moving to dynamic access controls?
- Why do former employees still keep access after offboarding in many organisations?
- How should healthcare organisations replace password-only access without slowing clinical work?
- How should teams keep privileged access available during a major outage?
