Why Privilege Creep Kills SAP Migrations Before the First Production Transaction Runs
AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor
Top 10 Responsible AI and Risk Management by Thinkers360Your migration to SAP S/4HANA is six months out. The project team is focused on data migration, Fiori tile configuration, and cutover planning. Meanwhile, 847 user roles built across eight years of organizational changes, job transfers, emergency firefighter access, and M&A integrations are being lifted wholesale into the new system. Nobody has reviewed them. Nobody has mapped them against the new S/4HANA authorization model. And your external auditors are already asking for the SoD conflict report.
This is the standard failure mode. And it is expensive to fix after go-live.
Migrating unremediated ECC roles into S/4HANA production does not just inherit old access risk. It amplifies it. S/4HANA's simplified data model, new Fiori authorization objects, and transaction replacements create net-new SoD conflicts from role content that was previously clean.
This article gives you the technical remediation workflow to stop that from happening. It covers the SAP-native tools, the sequencing logic, the role design architecture that prevents re-accumulation, and the automated tooling that makes the process viable at enterprise scale.
Why S/4HANA Breaks Your Existing SoD Matrix
SAP S/4HANA fundamentally changes the authorization landscape. This is not an incremental upgrade. The SAP S/4HANA Simplification List documents thousands of transaction replacements, program removals, and process consolidations. Transactions you built roles around in ECC no longer exist, have merged into Business Partner (BP) transactions, or now trigger different authorization objects entirely.
The most visible examples: XD01 and XK01, the customer and vendor master maintenance transactions, are replaced by the SAP Business Partner transaction BP. Any role that controlled access through those old transactions now either fails to control the equivalent S/4HANA function or, worse, grants broader access than intended because the authorization check structure has changed.
SAP Community analysis of S/4HANA security landscape changes confirms that SoD matrices built for ECC become unreliable after conversion. The conflict rules reference transactions that no longer exist, miss new authorization objects introduced in S/4HANA, and fail to account for Fiori app authorizations that bypass the traditional transaction-based access model.
This is not a configuration problem. It is a design-time engineering problem.
What Privilege Creep Actually Looks Like at Migration Time
Privilege creep is the accumulation of access rights that users no longer need. It happens across three vectors in most enterprise SAP environments.
First, job transitions. When a user moves from accounts payable to controlling, they get new access. The old access rarely gets removed. After five years and three job changes, that user holds access spanning procurement, finance, and HR, a combination that violates SoD in ways no single access request ever triggered.
Second, project-based access. Implementation projects, year-end processes, and audit support cycles generate temporary elevated access. Firefighter IDs get reused. Temporary roles become permanent. Emergency access granted during a system outage in 2021 is still active in 2025.
Third, role sprawl. When role designers copy existing roles rather than build from a business capability model, each copy carries forward every transaction and authorization value from the original. Over years, roles accumulate dormant transactions that nobody uses but that still represent active access rights from a SoD perspective.
By the time an S/4HANA migration project starts, a mid-sized SAP environment typically carries hundreds of roles where 30 to 50 percent of assigned transactions have zero usage in the prior 12 months.
Migrating roles with unused transactions into S/4HANA does not just carry old risk forward. In some cases, S/4HANA's new authorization objects cause those dormant role contents to map to broader access than they did in ECC. A transaction that was harmless in ECC may activate a wider authorization check in S/4HANA.
The SAP-Native Remediation Workflow: SU24, SUIM, and PFCG in Sequence
You do not need a third-party tool to start. SAP provides three native transactions that, used in the right sequence, give you a complete picture of your current access exposure before you touch a single production role.
Step 1: Use SUIM to Inventory Current Access
The SAP User Information System, transaction SUIM, is your starting point for understanding who has what access across the landscape. SUIM lets you query users by role, by authorization object, by transaction, and by combinations of those dimensions.
Run four reports at minimum before remediation begins. Pull all users with access to posting transactions (FB01, VF01, MIGO) combined with approval transactions in the same process area. Pull all users with access to sensitive BASIS transactions such as SU01, SU10, and SE16N. Pull all roles that include more than 150 active transactions, which is a strong indicator of over-provisioned design. And pull all user-role assignments where the last logon date is more than 90 days ago, which surfaces dormant accounts that should be disabled before migration.
SUIM does not tell you whether combinations are SoD violations. It tells you the raw access landscape. That data feeds your SoD analysis.
Step 2: Identify SoD Conflicts Against a Current Ruleset
Your SoD ruleset must reflect S/4HANA transactions, not ECC transactions. If you are using a GRC Access Control ruleset that was last updated during your ECC 6.0 implementation, it will miss conflicts introduced by S/4HANA's process changes. Update the ruleset first, then run the conflict analysis against the SUIM output.
SAP GRC Access Control provides the standard enterprise framework for this analysis. It maintains business process rule libraries, maps conflicting function pairs, and generates conflict reports by user, role, and profile. For organizations without GRC, the same analysis can be run manually using SUIM data cross-referenced against a documented SoD matrix, but at enterprise scale that is not a sustainable approach.
Research from Gutesman et al. on real-time SoD conflict detection establishes the theoretical basis for pre-runtime SoD checking: identifying violations before they are committed to production is significantly less costly than detecting and remediating them after user provisioning is complete. The same principle applies to migration projects.
Step 3: Correct Authorization Defaults in SU24
Before you rebuild roles in PFCG, fix the authorization defaults that PFCG uses as its source of truth.
Transaction SU24 maintains the default authorization objects and their proposed values for each transaction code and each Fiori application. When a role designer adds a transaction to a role in PFCG, PFCG reads SU24 to know which authorization objects to include and what default values to propose.
If SU24 defaults are incorrect, every role built from them inherits the error. In S/4HANA migrations, SU24 defaults for replaced or new transactions may not reflect your security requirements. Review SU24 for every transaction in scope, particularly for Fiori apps that were not present in your ECC system. Set proposal indicators correctly. Mark authorization objects that should always be checked. Remove defaults for authorization objects that your policy excludes.
This step is frequently skipped in migration projects under time pressure. That decision consistently produces roles where authorization checks are either missing or over-permissive, because PFCG built them from uncorrected defaults.
Step 4: Rebuild Roles in PFCG from Business Capabilities
Do not copy roles from ECC. Build them from business function definitions.
SAP's role maintenance transaction PFCG is where roles are constructed, maintained, and generated. A role built correctly in PFCG contains only the transactions and authorization objects required for a defined business function, with org-level values appropriate to the user population.
Use a three-layer architecture. Single roles contain the smallest functional unit, such as "Create Purchase Order." Composite roles bundle single roles into job profiles, such as "Procurement Clerk for Plant 1000." Derived roles replicate the design of a master role across different organizational units without duplicating the permission structure.
This architecture limits role count, simplifies audit reporting, and makes future modifications predictable. When a business function changes, you modify one single role, and the change propagates to every composite and derived role that references it.
Step 5: Validate and Test Before Cutover
After rebuilding roles, run the full SoD conflict analysis again against the new role set. Confirm that all high-priority conflicts identified in Step 2 are resolved. Then run authorization trace analysis, using SAP transaction ST01 or the authorization check framework documented in SAP's authorization evaluation documentation, to confirm that users can complete their required business processes without hitting authorization failures.
SAPinsider's analysis of go-live security sequencing makes the cost case clearly: remediating SoD conflicts before cutover costs a fraction of the effort required after production users are live and dependent on incorrect access. Post-go-live remediation also introduces operational risk, because correcting over-permissive access in production can break business processes that users have already built workarounds around.
When to Start the Role Work: A Sequencing Framework
The timing question is not primarily a technical decision. It is a resource and risk decision.
Before the S/4HANA Project Starts
For organizations with large, complex role landscapes, start role remediation before the S/4HANA project formally begins. This phase focuses on ECC cleanup: removing unused transactions, resolving existing SoD conflicts, standardizing role naming and structure, and establishing the governance model that will govern the S/4HANA design.
Starting early means the S/4HANA project inherits a cleaner baseline. It also means the project team can focus on S/4HANA-specific changes rather than simultaneously debugging both legacy role problems and new S/4HANA authorization requirements.
The main cost argument against early start is that some role work done in ECC will need to be redone when S/4HANA-specific transaction changes are applied. That is true. It is still cheaper than the alternative.
During the S/4HANA Project
Once the S/4HANA development system is available, apply the migration-specific changes. Map ECC transactions to their S/4HANA equivalents using the Simplification List. Add Fiori app authorizations. Test role content in the S/4HANA environment, because authorization behavior can differ from ECC even for transactions that exist in both systems.
This phase should address only S/4HANA-specific changes if the pre-project cleanup was done correctly. If it was not, this phase will be significantly more complex and will compete for time with every other workstream in the project.
After Go-Live
Post-go-live role work should cover edge cases, fine-tuning based on actual user behavior, and deferred items that were explicitly scoped out. It should not be the primary remediation phase. Organizations that defer SoD remediation until after go-live consistently face audit findings within the first annual review cycle.
The Non-Human Identity Problem in SAP Authorization
Role design discussions in SAP environments almost exclusively focus on human users. This is increasingly the wrong frame.
Modern SAP landscapes run significant automated workloads: interface users for middleware connections, batch users for background job execution, RFC users for system-to-system communication, and service accounts for cloud integration platforms. These non-human identities frequently hold broad authorizations granted during implementation and never reviewed since.
Research by Poreddy on non-human identity governance frameworks establishes that traditional role-based access control and HR-driven lifecycle models are structurally inadequate for managing machine identities. These accounts do not have managers who receive access review requests. They do not appear in HR offboarding workflows. They accumulate permissions across system upgrades without anyone noticing.
In S/4HANA migration projects, interface and batch accounts are typically migrated without review because the migration team is focused on human user profiles. Those accounts then exist in production with ECC-era authorizations that may map to broader S/4HANA access than was intended.
A batch user account with S_TABU_DIS access to table maintenance in ECC may, in S/4HANA, gain access to new configuration tables that did not exist in the source system. The authorization object and its values are identical. The scope of access has expanded.
The remediation approach for non-human identities follows the same SUIM-SU24-PFCG sequence used for human users, with one addition: every non-human identity should have a documented owner, a defined technical purpose, and a review cycle independent of HR processes. That governance structure is absent in most SAP environments today.
Automated Role Design: Where Authorization Architect Fits
At enterprise scale, manual role redesign is not a viable path. A large SAP environment with 2,000 or more roles, multiple system landscapes, and a six-month migration timeline needs tooling that automates the mechanical steps while maintaining human control over design decisions.
Transaction Usage Analysis as the Design Evidence Base
Authorization Architect uses Transaction Archive tool to analyze actual SAP execution history across the landscape. The recommended observation window is 13 months, long enough to capture a full annual business cycle plus overlap for month-to-month variation. This matters because role cleanup based on shorter windows risks removing access that is genuinely needed but only exercised during annual processes such as year-end close or tax reporting.
The analysis outputs a fact-based view of which transactions in each role are actually used, which are dormant, and which appear only in role definitions but have never generated an authorization check in production. This replaces assumption-based role cleanup with evidence-based redesign.
Performance: the Transaction Archive analysis typically completes in under two minutes for standard role sets, often in seconds. Present this as an operational benchmark for interactive review sessions, not as a contracted service-level commitment.
SoD Screening Before Role Creation
Authorization Architect runs SoD analysis against the proposed role design before the role is built, not after it is assigned to users. This is the architecturally correct sequence. Detecting a conflict in a role proposal costs nothing. Detecting the same conflict in a production role assigned to 200 users costs weeks of remediation effort.
The SoD check uses a functionality against either the client's existing ruleset or the default library. It covers sensitive transaction checks as well as function-pair conflicts. The result is visible to role designers before they submit the role for approval.
Basin et al.'s foundational work on dynamic enforcement of separation of duty constraints established that workflow-independent SoD policy enforcement, applied at design time rather than runtime, provides the most effective compliance architecture. Authorization Architect's pre-creation SoD check applies this principle directly to SAP role engineering.
Workflow Approvals Embedded in the Role Build Process
Authorization Architect routes role proposals through a structured approval workflow. Role operators create proposals and submit them for review. Role owners, the business stakeholders responsible for role content, receive pre-populated approval requests showing the proposed transactions, org levels, and SoD analysis results. Role approvers authorize composite roles for production deployment.
This three-tier structure, operators, owners, approvers, enforces the separation of design and approval duties that most SAP security governance frameworks require but few organizations actually enforce technically.
Automated Role Build Beyond SU24 Recommendations
When a role proposal clears the approval workflow, Authorization Architect builds the role automatically. This includes naming and description, role long text, structured role menu, org level definitions, and the full authorization object set. It generates master and derived role pairs and creates standalone maintain, display, and composite job roles as appropriate for the design.
The automation goes beyond what SU24 recommends. It applies the organization's naming standards, incorporates the corrected SU24 defaults from the remediation workflow, and produces consistent role content regardless of which team member runs the build. That consistency is critical for audit purposes and for future maintenance.
Migration Provisioning for S/4HANA Transaction Replacements
For migrations specifically, Authorization Architect's Migration Provisioning feature maps ECC transactions in existing roles to their S/4HANA equivalents using the Simplification List. Where a transaction no longer exists in S/4HANA, the tool suggests the replacement. Where a transaction remains, it flags it for testing confirmation.
This is the systematic approach to the XD01-to-BP and XK01-to-BP problem described earlier. Instead of manually tracing each transaction through the Simplification List, the tool processes the full role inventory and produces a remediation plan showing every impacted transaction and its proposed resolution.
Authorization Governance After Go-Live: Sustaining What You Built
Role redesign before go-live solves the migration problem. It does not solve the ongoing governance problem.
Access accumulates again after go-live. New projects generate emergency access. Organizational changes produce new provisioning requests. Integrations add non-human identities without formal review. Within 18 to 24 months of a well-executed migration, many organizations are back to a state of meaningful privilege creep if they have not built the governance infrastructure to prevent it.
Bhatia's research on AI-driven compliance architecture in S/4HANA transformations identifies continuous surveillance and dynamic regulatory data feeds as the structural components that prevent post-go-live compliance drift. The point is sound: compliance-by-design at migration time creates the clean baseline, but sustaining it requires automated monitoring that catches new violations before they accumulate into systemic risk.
The practical controls to build into your post-go-live governance model are direct:
Connect provisioning workflows to HR triggers. Every hire, job change, and termination should automatically generate an access review or modification request. Access that does not get reviewed on a triggered basis will not get reviewed.
Run quarterly access reviews for critical roles and high-risk users, not annual reviews. Annual reviews are too slow to catch the accumulation patterns that create material audit exposure.
Use transaction usage data from the production system, the same data that Authorization Architect analyzes at design time, as your ongoing evidence base for access review decisions. Roles with significant unused transaction populations after six months of production operation should be flagged for cleanup.
Set automated deprovisioning rules for dormant accounts. Accounts that have not logged in for 90 days should be flagged. Accounts inactive for 180 days should be disabled, pending review.
Treat non-human identity governance as a separate program, not a subset of human user access management. Document every interface user, batch user, and RFC user with an owner, a technical purpose, and a review schedule. Review those accounts on the same quarterly cycle used for privileged human users.
A Concrete Example
Procurement SoD Remediation Before Cutover
A North American manufacturing company with 4,200 SAP users and 1,800 roles began its S/4HANA migration with a SUIM-based access inventory. The analysis identified 23 users in the procurement organization who held simultaneous access to purchase requisition creation (ME51N), purchase order approval (ME29N), and goods receipt posting (MIGO). All three functions in one user profile is a textbook SoD violation covering the full procure-to-pay cycle without any compensating control.
Further analysis showed that 14 of the 23 users had accumulated this combination over time through separate access requests, each individually approved, none evaluated against the combined access picture. The remaining 9 held roles that had been copied from a prior template without SoD review.
The remediation sequence: SUIM identified the population. SoD analysis confirmed the conflict severity. Role redesign in PFCG split the three functions into separate single roles, assigned to different user populations with clear functional separation. Authorization Architect ran SoD screening against each redesigned role before build. The three composite roles were approved through the workflow process and built automatically.
Total elapsed time from analysis to production-ready roles: four weeks. The same remediation started post-go-live, with 4,200 live users dependent on their current access, would have required business sign-off on access removal for active users, parallel testing to prevent process disruption, and a change management effort to explain why users were losing access they had held for years. The post-go-live version of the same work typically takes three to five months.
Key Failure Modes to Avoid
Copying ECC roles into S/4HANA without transaction mapping. Copied roles carry every legacy transaction, including those that no longer exist or have changed authorization behavior. This produces both access gaps (missing S/4HANA functions) and access excess (dormant ECC transactions that now trigger different authorization checks).
Running SoD analysis after user provisioning, not before role creation. Post-provisioning SoD analysis identifies conflicts but requires user-level remediation, which is operationally disruptive and business-politically difficult. Pre-creation SoD analysis stops conflicts from entering the design.
Treating non-human identities as out of scope for migration role review. Interface, batch, and RFC users carry real access risk. Their authorizations should be reviewed against the S/4HANA authorization model with the same rigor applied to human user roles.
Deferring SoD remediation to post-go-live. The cost differential between pre-go-live and post-go-live remediation is not linear. Post-go-live remediation competes with operational support, requires business process testing to avoid disruption, and generates audit findings in the first review cycle if not completed quickly.
Using Authorization Architect as a role-copy factory. Automated role build accelerates execution. It does not replace design judgment. Automation run against an uncorrected business function model or a flawed SoD ruleset produces wrong roles faster.
What to Do Next
If your S/4HANA project is in planning, start the SUIM inventory now. Pull the four reports described in Step 1 of the remediation workflow. That data will tell you the scope of your remediation problem before the project schedule is locked and the role work gets compressed into the final two months before cutover.
If your project is already underway, the same analysis applies with more urgency. Get SUIM data, run SoD conflict analysis against a current ruleset, and prioritize the highest-severity conflicts for resolution before the transport to production.
If you have already gone live and the role work was deferred, build the quarterly review cadence and the non-human identity inventory program now. The clean-up will take longer than pre-go-live remediation would have. Starting immediately limits the accumulation.
The technical workflow is not complicated. The governance discipline required to execute it consistently, across teams, landscapes, and project timelines, is where most organizations struggle. That discipline starts with a clear decision that SoD is a design-time engineering responsibility, not a post-go-live audit finding.
Subscribe to Continue This Work
This publication covers SAP authorization engineering, identity governance, and the technical architecture of secure enterprise systems. Future articles will go deeper on Fiori authorization design, SAP GRC Access Control ruleset maintenance, and non-human identity governance frameworks for cloud-integrated SAP landscapes.
If you are building or fixing authorization governance in an SAP environment, subscribe now so these articles reach you directly. No generalist technology news, no vendor marketing. Just the technical depth that the people actually doing this work need.