They should define which gaps belong in the standard layer and which belong in extension points, then enforce that boundary through review. Custom sections, buttons, fragments, and controllers should be treated as exceptions with ownership and maintenance obligations, not as the default response to every business request.
Set the extension boundary before anyone starts coding
The first decision is architectural, not cosmetic: identify which requirement belongs in the standard Fiori elements layer and which truly needs an extension point. That boundary should be agreed by security, platform, and application owners before custom sections, buttons, fragments, or controllers are approved. Without that split, teams quietly turn one-off exceptions into the default delivery pattern.
In practice, the standard layer should absorb anything that can be met with configuration, supported annotations, or the existing app template. Extension points are for cases where the business requirement cannot be satisfied without altering the user interaction or adding verified logic. The more precisely that line is drawn, the easier it is to keep the app maintainable, supportable, and upgrade-friendly.
A useful way to validate the boundary is to ask whether the request changes only presentation and orchestration, or whether it introduces new business logic, approval steps, data handling, or privileged actions. If the answer is the latter, the team should treat it as a controlled change with explicit ownership rather than a quick UI tweak.
How to decide whether an extension is justified
Extension points should be used only when the standard app cannot meet a requirement without creating a workaround that is harder to support than the original gap. That means the team should test the request against three questions: can the standard template handle it, can the platform already expose it in a supported way, and does the change add behaviour that must be reviewed as part of the app’s security and lifecycle model?
This matters because custom UI elements often carry hidden operational cost. A fragment or controller may look small, but it can introduce data access paths, event handling logic, and error states that the standard app would otherwise manage for you. The decision is therefore less about code volume and more about whether the extension changes the trust, support, or maintenance model of the app.
For extension governance to work, the team needs a simple rule: if a request can be satisfied in the standard layer, do not create a custom artifact. If a custom artifact is unavoidable, document why it is needed, who owns it, what it depends on, and how it will be reviewed when the base app is upgraded.
Why ownership and maintenance obligations matter
Once an app leaves the standard path, someone must own the custom logic for the full lifecycle of the system. That includes regression testing after upgrades, verifying that the extension still behaves correctly after metadata or API changes, and confirming that the extension does not bypass intended controls or create inconsistent behaviour across roles and devices. This is where platform teams and security teams need a common approval standard, not just a development ticket.
Custom sections and buttons should be treated as exceptions with a maintenance contract attached. The contract should make clear who reviews the code, who approves changes, and who decides when the extension must be retired in favour of a supported standard feature. If nobody owns the exception, the organization eventually inherits an undocumented branch of the app that is hard to secure and harder to support.
That is why review is part of the control, not an afterthought. A good review asks whether the extension preserves the app’s intended boundary, whether it changes access to data or actions, and whether it remains supportable after the next platform update. Hard-coded secrets in custom code are one example of how a small extension can create disproportionate operational exposure if teams treat it as harmless UI work.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.32 — Change management | Custom Fiori extensions require controlled changes to avoid unsupported drift. |
| A.8.9 — Configuration management | The standard-versus-extension boundary is a configuration and supportability decision. | |
| Recommendation — Require approval and testing before releasing any custom extension to the app. Document the approved app baseline and restrict deviations to reviewed exceptions. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Extension points introduce controlled changes that need formal review and authorization. |
| SA-10 — Developer Configuration Management | Teams need ownership and lifecycle control for custom app artifacts. | |
| Recommendation — Authorize and track each extension as a controlled configuration change. Manage custom sections and controllers under a defined development lifecycle. | ||
Practitioner Guidance
What to prioritise: Put the extension decision gate in front of development intake, not after implementation starts. The most useful early outcome is a documented split between standard-layer gaps and true extension-point requirements, with an owner assigned to every approved exception.
What to verify: Check that each proposed custom section, button, fragment, or controller has a specific business justification, an identified support owner, and a review path for upgrades and regression testing. If those elements are missing, the request is not ready for approval.
Common mistake: Teams often approve extensions because they are faster than revisiting the business requirement. That shortcut creates long-lived custom behaviour that is expensive to test, easy to forget, and difficult to retire when the standard app evolves.
Practitioner takeaway: The first control is not code review, it is scope control. If the requirement can live in the standard layer, keep it there; if it cannot, treat the extension as a governed exception with explicit ownership from day one.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams evaluate authentication for a server-first React app?
- How can security teams reduce risk from first-party OAuth app abuse?
- How should teams decide between standard Fiori elements and custom UI code?