Conditional Clean Core is a governed extension state that allows ABAP customisation only when strict technical and security criteria are met. It is not blanket permission for bespoke code. The model depends on modernisation readiness, auditability, upgrade safety, and clean uninstall behaviour before an extension is considered acceptable.
Expanded Definition
Conditional clean core is a governed extension model used in SAP-aligned modernisation programs where custom ABAP changes are allowed only when they preserve upgradeability, auditability, and operational control. It sits between a strict standard-only posture and unrestricted bespoke development, so the condition is not whether code is custom, but whether the extension can be justified, tested, reversed, and maintained without corrupting the core.
In practice, the term is still applied unevenly across enterprises, and no single public standard governs it yet. The closest governance logic comes from change control and resilience principles in frameworks such as the NIST Cybersecurity Framework 2.0, especially where secure change management and recovery planning must remain measurable. For NHI and agentic automation teams, the key question is whether the extension introduces hidden privilege, undocumented dependency, or opaque execution paths that weaken trust in the platform. NHIMG’s guidance is to treat Conditional Clean Core as an exception state that requires explicit controls, not as a development preference.
The most common misapplication is treating any business-requested enhancement as compliant, which occurs when teams approve code because it is urgent while skipping uninstall testing, dependency review, and security sign-off.
Examples and Use Cases
Implementing Conditional Clean Core rigorously often introduces slower delivery cycles, requiring organisations to weigh business agility against long-term upgrade safety and control.
- A finance team adds a narrow ABAP extension for tax logic, but only after confirming the change is isolated, logged, and removable without affecting the standard process.
- A platform team rejects a custom transport because it stores secrets in code, aligning with NHIMG research showing that Ultimate Guide to NHIs reports 30.9% of organisations still store long-term credentials directly in code.
- A migration program accepts a temporary enhancement because test evidence proves the extension will survive an upgrade cycle and can be cleanly uninstalled if the target design changes.
- An audit team allows a workflow hook only after role ownership, logging, and rollback steps are documented under the organisation’s change approval process, consistent with NIST Cybersecurity Framework 2.0 governance expectations.
This model is most useful where business processes cannot immediately move to standard configuration, but the enterprise still needs a measured path to reduce custom-code debt.
Why It Matters in NHI Security
Conditional Clean Core matters because custom code often becomes the place where NHI controls fail first. A bespoke extension can quietly introduce embedded API keys, over-privileged service accounts, or unmanaged integration logic that escapes normal review. That risk is not theoretical: NHIMG reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, including code, config files, and CI/CD tools, while 97% of NHIs carry excessive privileges. When customisation is justified, the security team must verify that it does not create a hidden identity path with broader access than intended.
In Zero Trust-aligned environments, the question is not whether an extension works, but whether it can be inspected, constrained, and revoked with the same discipline as any other privileged capability. That is why this term aligns well with Ultimate Guide to NHIs and the operational emphasis in NIST Cybersecurity Framework 2.0. Organisations typically encounter the impact only after an upgrade breaks, a secret is discovered in a transport, or an audit reveals an unreviewed custom path, at which point Conditional Clean Core becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Conditional extensions often fail through secret sprawl and unmanaged service identities. |
| NIST CSF 2.0 | PR.IP-3 | Secure change management and controlled maintenance underpin clean-core governance. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires every extension path to be explicitly trusted and continuously constrained. |
Treat custom ABAP as a verified trust boundary with least-privilege access and continuous review.
Related resources from NHI Mgmt Group
- Why does clean core matter for identity and access governance?
- How should security teams approach a Greenfield SAP S/4HANA implementation when they want a clean core without carrying legacy risk forward?
- How should organisations govern identity security integrations when SAP moves to stricter Clean Core requirements?
- Clean Core
