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

At a glance

What this is: This is a product certification announcement showing that Pathlock’s SAP governance tools are certified for clean core with RISE with SAP, with the key finding that security and compliance controls must fit upgrade-ready SAP architectures.

Why it matters: It matters because SAP migrations often expose identity, SoD, and audit gaps that cut across human access, service accounts, and application-level entitlements, so IAM teams need controls that survive modernization without custom-code dependency.

👉 Read Pathlock's clean core certification announcement for SAP governance teams

Context

SAP clean core is a migration and operating model that reduces customisation in the digital core so upgrades remain manageable and future releases stay compatible. For identity governance, that changes the problem from embedding controls inside bespoke code to enforcing access, segregation of duties, and auditability around a cleaner architecture.

The practical challenge is familiar: when organisations move from legacy ECC environments to S/4HANA, they can import technical debt, privileged access patterns, and weak review processes along with the workload. Clean core certification matters because it tests whether governance can remain continuous without turning every control into a custom integration layer.

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: Why does clean core matter for identity and access governance?

A: Clean core matters because it changes where controls can live. When the SAP digital core is kept minimal, identity governance must operate through supported integrations and policy layers instead of bespoke code. That improves upgrade resilience, but only if IAM and GRC teams redesign controls for portability rather than assuming legacy extensions will carry forward.

Q: What breaks when SoD controls are tied to legacy SAP customisations?

A: SoD controls become brittle, hard to evidence, and easy to lose during upgrades or refactoring. If access rules are embedded in custom logic, a migration can remove the enforcement point while leaving the business risk unchanged. The result is a governance gap that looks like modernization success but behaves like control erosion.

Q: How do compliance teams know whether SAP governance still works after migration?

A: They should test whether access approvals, entitlement reviews, and audit logs are still produced without modifying the core application. If evidence requires manual reconstruction or one-off code, governance is not operationally stable. The right signal is repeatable control evidence generated through supported interfaces across release cycles.

How it works in practice

Clean core governance in SAP migration

Clean core means the SAP digital core stays minimally customised while integrations and extensions are kept outside the core boundary. That matters for identity governance because access control, SoD analysis, and audit logging must work through supported interfaces rather than direct code changes. In practice, the control plane becomes the integration layer, and that layer has to preserve integrity across upgrades, transports, and release cycles. When governance depends on intrusive customisation, the organisation creates brittle controls that break during migration, delay upgrades, or disappear when environments change.

Practical implication: Practitioners should treat clean core as an architectural constraint on governance design, not just an application modernization preference.

Access governance and SoD controls across S/4HANA

Segregation of duties in SAP is about preventing a single identity from accumulating conflicting abilities such as creating vendors and approving payments. In S/4HANA, the challenge is to keep those controls active in near real time while identities, roles, and business processes are changing during migration. If access review, role mapping, and entitlement validation are not aligned to the new architecture, SoD risk simply relocates instead of shrinking. The governance model must therefore follow the process path, not the old system boundary.

Practical implication: IAM teams should verify that SoD rules remain enforceable after migration and do not rely on legacy ECC assumptions.

Auditability without intrusive customisation

Auditability in SAP depends on being able to explain who had access, what they could do, and whether controls were applied consistently over time. Clean core certification signals that this visibility should be maintained without inserting custom logic into the digital core itself. That is important because audit trails often fail when organisations patch control gaps with one-off code, manual spreadsheets, or disconnected review workflows. A compliant migration needs traceability that survives upgrades and can be inspected independently of the application customisation layer.

Practical implication: Security and compliance teams should map audit evidence collection to supported SAP interfaces before migration begins.

NHI Mgmt Group analysis

Clean core is really a governance boundary, not just an SAP architecture choice. Once organisations move from heavily customised ECC environments into S/4HANA, identity and compliance controls can no longer depend on embedded modifications inside the business core. That forces IAM, GRC, and application teams to decide whether control enforcement lives in supported integration layers or dissolves during upgrade cycles. The practitioner conclusion is straightforward: treat clean core as a control-design constraint.

Pathlock’s certification points to a broader market shift toward control planes that survive ERP modernization. SAP migrations are increasingly exposing the difference between controls that are portable and controls that only work inside legacy custom code. That matters for identity governance because access enforcement, SoD monitoring, and auditability have to remain stable while the underlying application estate changes. The practitioner conclusion is to re-evaluate whether existing governance tooling still functions outside the old system boundary.

Application-level identity governance becomes harder when business logic moves out of the core. Clean core architectures reduce customization, but they also remove the informal control hooks many teams used to manage privileged access and approvals. The result is not weaker governance by default, but a stricter requirement that policy, evidence, and enforcement be explicit. The practitioner conclusion is that governance must be designed for portability, not convenience.

ERP transformation is now an identity design problem as much as a platform migration problem. S/4HANA programmes that focus only on technical upgrade paths miss the governance question of how access, audit, and compliance survive the move. Clean core certification does not eliminate migration risk, but it highlights where that risk now sits. The practitioner conclusion is to align identity governance with the target operating model before cutover, not after.

Named concept: clean core control portability. This is the requirement that access governance, SoD checks, and audit evidence continue working when the application core no longer tolerates bespoke customisation. It matters because many enterprise controls were built to piggyback on legacy extensions that do not belong in the new architecture. The practitioner conclusion is to test every critical governance control for portability before migration timelines lock in.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, which is why lifecycle controls should be validated before and after SAP migration phases.
• Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs helps teams translate clean core principles into portable governance for service accounts and application identities.

What this signals

Clean core will force IAM teams to separate portable governance from embedded application logic. In migration programmes, the controls that survive are the ones that can be enforced through supported interfaces, not the ones that rely on legacy custom code. That makes access review design, SoD rule mapping, and evidence collection part of the target operating model rather than an afterthought.

Identity governance programmes should expect a wider review of privileged access during ERP modernization. When customizations are removed, temporary exceptions often appear in approval flows and administrative access. Teams should watch for those exceptions becoming the new standing control model, because that is usually where auditability and upgrade resilience begin to drift.

With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, clean core should be read as a supply-chain governance issue as much as an ERP one. The practical signal is whether your SAP integrations, service accounts, and downstream approvals can still be governed when the core stops tolerating bespoke logic.

For practitioners

• Map SoD rules to the S/4HANA target state Revalidate segregation of duties for the new business processes, not the legacy ECC role model. Confirm that privileged combinations, approval paths, and compensating controls still hold after custom code is removed.
• Inventory controls that depend on custom SAP extensions List every access review, approval, and audit step that currently relies on bespoke code or transport-specific logic. Replace fragile dependencies with supported interfaces wherever possible so the control survives upgrades.
• Align audit evidence collection to clean core boundaries Define which logs, reports, and attestation records will prove control operation in the target architecture. Ensure evidence can be retrieved without direct modification of the SAP digital core.
• Reassess privileged access during migration waves Track who can create, approve, and deploy changes while customisations are being retired. Migration periods often widen privilege scope temporarily, so review elevated access before and after each wave.

Key takeaways

• Clean core changes SAP governance from embedded customisation to portable control design.
• Migration risk is not only technical debt, but also the loss of reviewable access, SoD, and audit pathways.
• Teams should test every critical identity control for survival in the S/4HANA target architecture before cutover.

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 that prevents one identity from holding incompatible capabilities in the same business process. In SAP environments, it is used to reduce fraud and error by separating actions such as creating, approving, and paying, then proving that those separations still hold after migration.
• Control Portability: Control portability is the ability of a governance control to keep working when the application architecture changes. In clean core programmes, portable controls survive release cycles, integrations, and cleanup of custom code, which makes them more reliable than controls that only exist inside legacy extensions.
• Auditability: Auditability is the ability to reconstruct who had access, what they could do, and whether controls were enforced over time. In SAP transformation programmes, it depends on repeatable evidence collection and stable logging paths, not on manual reconstruction after the fact.

Deepen your knowledge

SAP clean core, SoD governance, and auditability are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping identity controls into a modern SAP architecture, it is worth exploring.

This post draws on content published by Pathlock: Pathlock Native Cyber Security and GRC Suite and Application Profiler certified for SAP clean core with RISE with SAP. Read the original.