Teams should start with the standard floorplans and only move to custom UI code when a requirement cannot be expressed cleanly through annotations or extension points. The decision should weigh process fit, upgrade resilience, and long-term maintenance. If the customisation changes navigation, draft handling, or message behaviour, the case for staying within Fiori elements is usually stronger.
Why This Matters for Security Teams
The standard-versus-custom decision is not just a UI preference. In enterprise SAP design, Fiori elements gives teams faster delivery, more predictable upgrade paths, and less code to secure, while custom UI code can satisfy edge-case workflows that annotations and extension points cannot express. The real risk is choosing custom too early and inheriting brittle behaviour that breaks with each system change. NHI Mgmt Group’s Ultimate Guide to NHIs — Standards notes that 97% of NHIs carry excessive privileges, which is a useful reminder that unnecessary complexity tends to widen the attack surface.
Security teams should care because UI architecture influences authorization checks, auditability, and the speed of remediation when business rules change. Standard floorplans keep behaviour closer to the platform model, which usually reduces regression risk and preserves upgrade resilience. Custom code may be justified, but it also shifts more responsibility onto the development team for message handling, draft logic, accessibility, and regression testing. NIST’s NIST Cybersecurity Framework 2.0 is relevant here because maintainability and change control are part of operational resilience, not just engineering preference. In practice, many teams discover the cost of custom UI only after an upgrade or workflow change has already exposed the gap.
How It Works in Practice
The decision usually starts with fit analysis. If the requirement can be modelled through annotations, floorplan variants, or supported extension points, Fiori elements is the safer default. That keeps the app aligned to SAP standards and reduces rework when backend services evolve. Custom UI code becomes appropriate when the process truly needs behaviour that the standard framework cannot express, such as a non-standard interaction sequence, specialised validation flow, or a layout that materially changes how the user completes the task.
A practical review often includes these questions:
- Can the business outcome be achieved through metadata, not bespoke screen logic?
- Will the change affect navigation, draft handling, or message behaviour?
- Does the requirement introduce new state management or client-side orchestration?
- How much testing and regression effort will be needed for each future release?
Fiori design guidance and extension patterns matter here, and the SAP team should treat custom code as a deliberate exception rather than a convenience. For broader identity and application-risk context, the JetBrains GitHub plugin token exposure case shows how quickly avoidable complexity can become an operational problem when sensitive flows are embedded in code paths that are hard to govern. The lesson is not to avoid customisation entirely, but to justify it with clear functional necessity and an explicit maintenance plan. These controls tend to break down when a project mixes standard and bespoke patterns without a single owner for lifecycle testing, because upgrade impact becomes difficult to predict.
Common Variations and Edge Cases
Tighter adherence to standard floorplans often increases upfront constraint, requiring organisations to balance delivery speed against long-term supportability. That tradeoff is real: some processes are genuinely too specialised for pure Fiori elements, and forcing the standard can create awkward workarounds that frustrate users and business owners. Current guidance suggests using custom UI only where the business value is clear and the requirement cannot be represented cleanly through supported metadata or extension hooks.
Edge cases often appear in highly regulated workflows, exception-heavy approval chains, or screens with complex, conditional interactions. In those environments, custom code may be necessary, but the team should document exactly which standard assumptions are being replaced and how regression will be tested after upgrades. Where possible, preserve the standard framework for navigation, draft lifecycle, and messaging, then isolate custom logic to the smallest feasible surface area. That approach limits rework and makes the next enhancement cheaper.
The key exception is when the UX itself is the control boundary. If the design changes how users are warned, how errors are resolved, or how records move through approval, the risk profile is no longer just visual. In those cases, the team should treat the decision as an application-governance issue, not a front-end styling choice. The practical test is simple: if the requirement can be met without breaking standard behaviour, keep the standard pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, 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.IP-1 | Covers maintenance of systems through change control and resilience. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege thinking applies to limiting unnecessary custom logic and access paths. |
| NIST AI RMF | Governance and manage functions support decision-making on risk, maintainability, and accountability. |
Use AI RMF-style governance to document why custom UI is needed and how it will be controlled.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- What is the difference between code scanning and runtime identity monitoring?
- How should teams decide whether to build or buy passkeys infrastructure?
- How should security teams decide whether to build or buy JIT access control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
