How should organisations govern identity security integrations when SAP moves to stricter Clean Core requirements?

Why This Matters for Security Teams

SAP Clean Core changes the identity security question from “can it work?” to “can it keep working across upgrades without creating hidden technical debt?” Integrations that depend on deep customisations, brittle transport steps, or undocumented hooks can become the first thing to fail when SAP tightens extension rules. That matters because identity controls sit on the path to privileged access, audit evidence, and offboarding.

The practical risk is not only broken connectivity. It is also the creation of shadow dependencies that no one owns when the platform evolves. NHI governance becomes part of ERP change governance, which means security teams must prove that controls remain supportable, removable, and observable. That is consistent with the NIST Cybersecurity Framework 2.0 emphasis on lifecycle management and resilience, and with NHIMG guidance in the Ultimate Guide to NHIs on visibility, rotation, and offboarding.

NHIMG research shows the problem is rarely abstract: 71% of NHIs are not rotated within recommended time frames, and 96% of organisations store secrets outside secrets managers in vulnerable locations. In practice, many security teams discover Clean Core incompatibilities only after an SAP upgrade or remediation project has already exposed the integration debt.

How It Works in Practice

Governance should start with an integration inventory that classifies every SAP-connected identity control by business purpose, technical dependency, and removal path. The key test is whether the integration can be upgraded, audited, and uninstalled without manual cleanup in core ERP code. If it cannot, it is not Clean Core ready, regardless of how well it functions today.

Security and architecture teams should insist on a few operating checks:

• Use standard APIs, supported extension points, and documented event hooks before custom code.
• Prefer short-lived secrets, workload identity, and token exchange over hard-coded credentials in SAP-adjacent scripts.
• Define ownership for credential issuance, rotation, logging, and revocation across both SAP and the identity platform.
• Confirm that all security events needed for audit can be retained outside the custom integration path.
• Test uninstallability in a non-production landscape so the integration can be removed cleanly during upgrade cycles.

This is where current best practice aligns with the NIST Cybersecurity Framework 2.0 and the NHIMG Lifecycle Processes for Managing NHIs guidance: identity controls should be treated as governed lifecycle assets, not one-time integrations. The strongest pattern is to move policy enforcement and identity proofing outside the ERP core, then connect SAP to those services through supported interfaces and auditable event flows.

That approach also helps contain privilege creep. When identity workflows depend on brittle custom objects, teams often keep overly broad service accounts alive just to avoid breaking downstream jobs. These controls tend to break down when integrations are embedded directly in core SAP customisations because upgrade testing cannot reliably expose every hidden dependency.

Common Variations and Edge Cases

Tighter Clean Core enforcement often increases change-control overhead, so organisations must balance upgrade safety against integration speed. That tradeoff is real, especially where SAP security workflows support payroll, procurement, or emergency access.

Not every identity integration needs the same treatment. Some high-risk workflows, such as privileged access approval or secrets rotation, may justify a dedicated external service with strict audit logging. Lower-risk read-only integrations may remain acceptable if they use supported APIs and can be retired without code changes. Where guidance is still evolving, the safest position is to treat unsupported extensions as temporary exceptions, not architectural precedent.

For regulated environments, the bar is higher. Audit teams will usually expect clear evidence of ownership, rollback, and control testing. NHIMG’s Regulatory and Audit Perspectives and the Top 10 NHI Issues both reinforce the same operational point: if an identity integration cannot be rotated, monitored, and removed cleanly, it should not be allowed to become critical-path infrastructure.

Related resources from NHI Mgmt Group

• How do organisations measure whether AI-assisted identity journeys are actually improving security?
• Why do organisations need unified data and identity security as cloud and SaaS adoption grows?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?