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

Why This Matters for Security Teams

An S/4HANA migration is the point where SAP access governance either becomes cleaner and more auditable, or exposes years of accumulated exceptions. The biggest mistake is treating the move as a technical conversion while leaving SoD rules, emergency access, and shared technical accounts untouched. That approach usually preserves legacy risk in a new stack, which defeats the purpose of clean core design and makes audit evidence harder to defend.

Security teams should use the migration to re-test access assumptions against the target process model, not the old one. SAP governance still has to answer basic questions: who can create, approve, and post; which privileged paths bypass normal approvals; and how temporary access is granted and removed. Those questions map closely to broader identity governance guidance in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10, because service accounts, integrations, and automation often become the hidden control gap during ERP change.

In practice, many security teams discover that access drift was embedded in business process exceptions only after cutover pressure has already reduced their options.

How It Works in Practice

The most effective pattern is to govern SAP access as part of migration workstreams, not as a post-go-live cleanup. Start by inventorying roles, technical users, RFC connections, batch jobs, interface accounts, and privileged troubleshooting paths. Then classify which access is business-required, which is compensating, and which only exists because of legacy customisation. That classification should drive the redesign of SoD rules, approval chains, and emergency access workflows.

For privileged access, current guidance suggests using time-bound elevation and strong approval evidence rather than standing entitlements. If a team cannot explain why a role must remain permanent, it should usually be converted to JIT access or split into narrower roles. Audit teams also need immutable evidence for who approved access, when it was activated, and when it was revoked. The governance model described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because SAP technical identities follow the same lifecycle discipline as other non-human identities.

• Rebuild SoD rules against S/4HANA processes, not ECC-era role names.
• Separate business approval from technical activation for privileged SAP access.
• Revalidate batch users, interface accounts, and service IDs as governed identities.
• Map audit evidence to control objectives in NIST Cybersecurity Framework 2.0, especially access management and logging.

For migration teams, the practical test is whether a role, approval, or technical account can survive upgrade cycles without manual exception handling; if not, the control is still coupled to legacy behaviour. These controls tend to break down when custom SAP transactions, shared firefighter access, and third-party connectors all depend on the same overbroad identity.

Common Variations and Edge Cases

Tighter SAP access governance often increases operational overhead, so organisations have to balance auditability against release speed and supportability. That tradeoff is real, especially in programmes with heavy custom code or multiple country rollouts. Best practice is evolving, but there is no universal standard for how much temporary access should be acceptable in a large migration.

One common edge case is shared technical ownership between SAP Basis, application teams, and system integrators. In those environments, role redesign can stall because nobody wants to own the access decision. Another is dual-run migration, where ECC and S/4HANA coexist long enough for role duplication and entitlement drift to creep back in. In those cases, security teams should treat the transition period as a high-risk state and tighten review frequency. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful reminders that over-privilege and weak lifecycle controls become more damaging when systems are in flux.

Another variation is third-party support access. Vendors may need urgent access during conversion testing, but that access should still be time-boxed, monitored, and revoked automatically. The control should not depend on manual follow-up after the migration team has disbanded. In larger programmes, the cleanest answer is to define a migration-specific access policy set, then retire it once the target-state roles, logs, and review cadence have stabilised.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?