SAP clean core certification sharpens governance for S/4HANA migration

At a glance

What this is: This is a vendor announcement about SAP clean core certification, with the key finding that migration governance depends on keeping access control, auditability, and extensibility aligned as organisations move to S/4HANA.

Why it matters: It matters because IAM, IGA, and GRC teams cannot treat ERP migration as a pure technical upgrade; governance controls have to survive the transition without breaking the digital core.

Context

SAP clean core means keeping the ERP digital core as standard as possible, with customisation pushed to controlled extension points rather than embedded directly in the core. In migration programmes, that design choice changes the governance problem from “can we move the workload?” to “can we preserve control without modifying the system in ways that weaken auditability or upgrade paths?”

Pathlock’s announcement sits in that governance gap. The article argues that S/4HANA migration can import legacy technical debt, custom code, and fragmented access controls if teams do not enforce clean-core discipline across the transformation. For identity and access governance teams, the real question is whether controls remain measurable and enforceable once the environment is rebuilt around modern SAP extensibility rules.

Key questions

Q: How should security teams govern SAP access during an S/4HANA migration?

A: Security teams should treat migration as a governance redesign exercise, not a lift-and-shift. Revalidate SoD rules, privileged access paths, and audit evidence against the target architecture, then remove any control that only works because of legacy customisation. If a control cannot survive upgrade cycles, it is not ready for clean core operations.

Q: What breaks when custom SAP controls are left inside the digital core?

A: Embedded custom controls often become brittle during upgrade and audit cycles. They create undocumented dependencies, complicate change management, and make it harder to prove that access rules, SoD checks, and logging still work after migration. Once the core changes, those controls can lose both technical compatibility and governance clarity.

Q: How can IAM teams tell whether their SAP governance is migration-ready?

A: Migration-ready governance is visible when access rules, approvals, and audit trails are defined in standard extension points and can be tested against the target-state environment. If control logic only works because of custom ECC behaviour, the programme is not ready for S/4HANA. Readiness depends on enforceability after the architecture shift.

Q: Why do clean core and auditability need to be designed together in SAP programmes?

A: Clean core reduces the risk of hidden customisation, while auditability depends on controls remaining traceable and testable through change. If those two goals are separated, teams can end up with a cleaner architecture that is harder to evidence, or a more evidentiable system that is harder to upgrade. Governance only holds when both are aligned.

How it works in practice

What clean core changes in SAP governance

Clean core is an architectural constraint, not just a branding term. It separates core ERP logic from custom extensions so that upgrades, security fixes, and new SAP capabilities can be applied without reworking brittle custom code. From a governance perspective, this shifts control design away from embedded modifications and toward controlled integration, documented extensibility, and audit-friendly enforcement points. That matters because many legacy SAP environments accumulated business logic, access exceptions, and control workarounds inside the core itself. In S/4HANA migrations, those hidden dependencies can become operational blockers and audit liabilities if they are carried forward unchanged.

Practical implication: map which controls depend on core modifications and re-home them into governed extension patterns before migration.

Why access governance must survive the migration boundary

Access governance in SAP is not only about who can log in. It also covers segregation of duties, privileged transactions, and whether access rules remain enforceable across new architecture layers. During migration, teams often focus on functional parity and overlook whether old roles, custom transactions, and compensating controls still behave the same in S/4HANA. That creates a governance gap where entitlement logic survives in name but not in enforcement. In a clean core model, controls must be expressed in a way that survives upgrade cycles and extension changes without losing traceability or breaking audit evidence.

Practical implication: validate SoD, privileged access, and audit evidence at the target-state architecture, not only in the source ECC system.

How clean core reduces technical debt in identity control design

Technical debt in SAP migrations often includes custom approvals, one-off role fixes, and manual exceptions that make the control environment hard to maintain. Clean core reduces that debt by forcing organisations to standardise extension points and avoid core modifications that later become untestable. The security value is not abstract. Fewer embedded customisations usually means fewer places where access logic, logs, and compliance checks can drift apart. For IAM and GRC teams, that means control design should be treated as part of the migration architecture rather than as a post-migration remediation task.

Practical implication: inventory custom access logic early and classify each item as retire, replace, or redesign for the target SAP model.

NHI Mgmt Group analysis

Clean core is now an identity governance problem as much as an ERP architecture problem. The article is not really about certification as an end state. It is about whether organisations can migrate to S/4HANA without carrying forward access exceptions, audit gaps, and brittle custom controls that were tolerated in legacy ECC environments. That makes the migration a governance redesign exercise, not a lift-and-shift technical project. The practitioner conclusion is straightforward: if the control model cannot survive the new architecture, the migration is not yet ready.

Technical debt becomes control debt when SAP customisation is left inside the digital core. Custom code and embedded workarounds are not neutral implementation choices. They usually create undocumented dependencies that weaken change control, complicate evidence collection, and make SoD enforcement harder to sustain. Clean core certification signals that the market is moving toward extension discipline as a governance requirement, not a preference. Practitioners should re-evaluate any migration plan that treats custom access logic as something to clean up after go-live.

Identity controls for SAP migrations must be measured at the target state, not inherited from the source system. A role model that worked in ECC can fail in S/4HANA if it assumes the same transaction paths, the same extension points, or the same audit trail structure. That means access governance needs target-state validation, not source-system replay. The implication is that certification, auditability, and upgradeability are now tightly linked, and teams cannot optimise one while ignoring the other.

Clean core will push SAP governance teams toward fewer exceptions and more explicit control boundaries. The direction of travel is clear: extension points, traceable integrations, and standardised controls will carry more weight than bespoke in-core tailoring. That will simplify some governance tasks while exposing weak control ownership in organisations that relied on custom fixes. The practitioner conclusion is to treat extension governance as a permanent part of IAM and GRC operating model design.

Pathlock’s certification illustrates a broader market signal: SAP governance is converging with modern identity control expectations. The market is moving toward architectures where security, auditability, and upgradeability are designed together rather than traded off against one another. For IAM and GRC leaders, the useful question is no longer whether customisation was convenient, but whether the resulting control environment can still be governed at scale. That is the standard migration programmes now have to meet.

What this signals

Control boundaries will matter more than custom convenience: SAP programmes that still rely on bespoke in-core logic should expect more friction as clean core expectations spread. The practical shift is toward extension governance, documented ownership, and evidence that survives upgrades.

IAM and GRC leaders should assume that migration success will be judged by whether controls remain enforceable in the target architecture, not by how closely the new environment resembles the old one. That changes planning, testing, and audit preparation from late-stage tasks into design requirements.

For practitioners

• Inventory embedded access logic Catalogue custom role logic, approval paths, compensating controls, and transaction-specific exceptions that currently live inside the SAP core. Classify each item by whether it should be retired, reimplemented through supported extension points, or redesigned for S/4HANA governance.
• Re-test SoD after architecture changes Validate segregation-of-duties rules in the target-state environment rather than assuming source-system controls will behave identically after migration. Re-run scenarios that involve privileged transactions, role combinations, and audit evidence capture across the new SAP model.
• Separate core modifications from governed extensions Move business-specific logic out of the SAP core and into controlled extension patterns with documented ownership, change controls, and audit trails. This reduces upgrade friction while making the control surface easier to review and certify.
• Build migration controls into the programme plan Treat access governance, auditability, and upgrade readiness as migration requirements from the start, not as post-migration remediation. Align IAM, GRC, and SAP architecture teams on the control boundaries that must survive go-live.

Key takeaways

• The main risk in S/4HANA migration is not the move itself but carrying forward custom access logic and audit gaps that no longer fit the target architecture.
• Clean core certification points to a broader governance requirement: controls must remain traceable, testable, and upgrade-safe after migration.
• Teams that design access governance around supported extension points are better positioned to preserve SoD, auditability, and change control in SAP.

Key terms

• Clean Core: 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.
• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• SAP Extension Governance: SAP extension governance is the management of custom logic, integrations, and controls through approved extension patterns instead of embedded core modifications. It helps preserve traceability, upgradeability, and auditability when organisations modernise from ECC to S/4HANA.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.