What breaks when SAP access controls are not revalidated before and after migration?

When access controls are not revalidated, organisations often carry forward stale roles, overbroad privileges, and untested integration paths. That can expose sensitive data, break audit evidence, and create separation of duties conflicts across SAP and connected systems. It also makes it harder to distinguish legitimate operational access from risky exceptions once the new environment goes live.

Why This Matters for Security Teams

When SAP access controls are not revalidated before and after migration, the organisation is not just moving users and roles. It is moving assumptions. Old firefighter roles, temporary exceptions, and inherited technical accounts can survive the cutover and suddenly operate in a new trust boundary. That creates silent privilege creep, broken segregation of duties, and audit evidence that no longer matches the real access model. Guidance from OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point to the same operational reality: access must be verified continuously, not assumed valid because it existed in the source system. In NHI terms, that matters because SAP migrations often preserve service accounts, interface credentials, and batch identities that outlive the business need that originally justified them. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition a migration can quietly entrench if revalidation is skipped. In practice, many security teams encounter access drift only after audit failure, production incidents, or SoD violations have already exposed the gap.

How It Works in Practice

Revalidation should happen in two passes: before migration, to remove obsolete access and map current business need; and after migration, to confirm that the target environment did not widen access through role redesign, connector changes, or fallback permissions. The first pass identifies what can be retired, reduced, or segmented. The second confirms what actually works in the new landscape, including RFC links, integration users, background jobs, and any emergency access paths that were temporarily enabled for cutover.

Practitioners usually need to test three layers together: user-to-role assignment, role-to-authorisation object mapping, and system-to-system access for interfaces and automation. The goal is not only to check whether a role exists, but whether it still reflects business function and least privilege. That is especially important where SAP is connected to identity platforms, ticketing, finance workflows, or external API consumers. Current guidance suggests using a formal recertification workflow, evidence capture, and exception approval trails aligned to CIS Controls v8 and ISO/IEC 27001:2022 Information Security Management, while also checking whether non-human access has been documented and rotated where appropriate. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because migration teams often overlook service identities that are not visible in standard user reviews. One practical signal is whether a role still has a named owner and a current business justification at go-live.

• Remove orphaned and duplicate SAP roles before cutover.
• Reconfirm separation of duties after target-role remapping.
• Review technical accounts, batch users, and interface credentials separately from human users.
• Validate that temporary migration access is revoked on schedule.
• Retest audit logging so evidence matches the new control environment.

These controls tend to break down when the migration is compressed into a single cutover window because there is no time to distinguish valid exceptions from inherited risk.

Common Variations and Edge Cases

Tighter access revalidation often increases delivery overhead, requiring organisations to balance migration speed against control accuracy. That tradeoff becomes sharper in greenfield SAP transformations, hybrid coexistence periods, and global rollouts where local process owners insist on keeping legacy access “just in case.” Best practice is evolving, but there is no universal standard for treating every temporary privilege the same way; some teams use time-bound emergency access, while others require full recertification before any privilege is reissued. The difference matters because legacy SAP landscapes often contain custom roles, bespoke authorisations, and embedded business logic that cannot be assessed with a simple compare-and-copy approach.

Edge cases also show up in shared service accounts, robotic process automation, and middleware identities. These are not normal end users, but they still create access risk if they are not revalidated against current task scope and ownership. NHIMG’s 52 NHI Breaches Analysis shows how often identity failures are the entry point, while SAP SQL Anywhere Monitor Hardcoded Credentials illustrates the danger of persistent secrets surviving inside SAP-adjacent operations. For teams that need to justify the work, the practical standard is simple: if a role, account, or connector cannot be owned, explained, and re-approved after migration, it should not be trusted as-is.

Related resources from NHI Mgmt Group

• What breaks when migration planning does not account for data mapping and access controls in SAP transformation projects?
• What breaks when SAP data is not classified before migration to S/4HANA?
• What breaks when access controls are designed too late in a cloud transformation programme?
• What breaks when SAP code is modified directly instead of using extensibility and transport controls?