A clean core is an SAP operating model that keeps the digital core minimally customised and pushes extensions into supported layers. For identity governance, that means access controls, SoD rules, and audit evidence must work through stable interfaces instead of embedded modifications that break during upgrades.
Expanded Definition
Clean core is an SAP operating model that preserves a minimally customised digital core and routes bespoke logic into supported extension layers. In NHI governance, that matters because access policy, auditability, and control enforcement must survive upgrades rather than being trapped inside brittle code paths.
The term is used most often when organisations are trying to reconcile ERP customisation with long-lived identity controls. A clean core does not mean “no change”; it means changes are intentional, isolated, and governed. For NHI and agentic workflows, that typically includes service account provisioning, access reviews, and secrets handling through interfaces that can be tested and versioned. Guidance varies across vendors, but the security principle is consistent: keep control logic outside the core when possible, then validate it against enterprise policy and a framework like NIST Cybersecurity Framework 2.0.
The most common misapplication is treating clean core as a purely technical upgrade strategy, which occurs when teams preserve ERP modularity but still hard-code identity exceptions in custom objects and transport layers.
Examples and Use Cases
Implementing clean core rigorously often introduces coordination overhead, requiring organisations to weigh faster upgrade compatibility against the cost of redesigning legacy access logic.
- An SAP team moves privileged access approvals into an external workflow layer so role changes can be audited without modifying the core authorization model.
- A platform team exposes identity checks through supported APIs, keeping service account provisioning outside the ERP database while still aligning with NIST Cybersecurity Framework 2.0 governance functions.
- A security group separates SoD rules from application code so audit evidence remains stable during patch cycles and can be traced back to documented control owners.
- An enterprise standardises extension logic for non-human identities after learning from the patterns discussed in Ultimate Guide to NHIs, where poor visibility and over-privilege are recurring risks.
- A modernization programme uses clean core boundaries to support JIT access and revocation without embedding secret lifecycle logic directly into the ERP core.
In practice, clean core works best when business exceptions are managed in controlled layers rather than hidden in transport requests or one-off developer fixes.
Why It Matters in NHI Security
Clean core becomes a security issue when the organisation needs evidence, revocation, or least-privilege enforcement and discovers those controls are buried in custom ERP logic. That is especially dangerous for service accounts, API keys, and integration identities, because their permissions often persist longer than business owners expect. NHIMG research shows that 97% of NHIs carry excessive privileges, and that problem is amplified when identity logic is embedded in the core instead of governed through stable interfaces; the broader risk landscape is outlined in the Ultimate Guide to NHIs. A clean core approach also supports control testing against zero trust principles, including NIST Cybersecurity Framework 2.0 and related identity governance expectations.
When clean core is ignored, upgrades can break approval chains, access reviews, and audit trails at exactly the moment an investigation is needed. Organisations typically encounter the cost after a failed upgrade, a SoD exception, or a secrets exposure, at which point 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 | Clean core limits custom logic that often hides NHI secret and access control failures. |
| NIST CSF 2.0 | PR.AC-4 | Clean core supports least-privilege enforcement and reviewable access decisions. |
| NIST Zero Trust (SP 800-207) | Clean core aligns with zero trust by separating policy enforcement from core application logic. |
Map SAP extension access to least-privilege controls and review entitlements on a fixed cadence.
