Most SAP access management projects fail for the same handful of reasons: they are run as IT projects instead of business projects, they try to redesign everything at once, they migrate old problems into new roles, they underinvest in testing, and they have no plan to stop access drifting back to where it started. The technology is rarely the problem. The approach usually is.
Whether you are redesigning roles, cleaning up segregation of duties (SoD) conflicts, preparing for S/4HANA or tightening controls after an audit finding, this guide explains the most common reasons SAP access management projects fall short, the warning signs to watch for, and what successful projects do differently.
Key Takeaways: Why SAP Access Management Projects Fail
- SAP access management projects fail more often because of ownership, scope and change management than because of technology.
- Copying legacy roles into a new system, including during S/4HANA and RISE with SAP migrations, carries old SoD conflicts straight into the new landscape.
- Role designs that are too broad create risk; designs that are too granular create an administrative burden nobody can sustain.
- Poor testing leads to go-live access chaos, which is often "fixed" with broad emergency access that undoes the project's purpose.
- Without continuous monitoring, access drifts back into conflict within months of go-live.
- Successful projects are business-led, phased, tested with real users, and supported by tools such as CERPASS Software that simulate changes and monitor SoD continuously.
What Is an SAP Access Management Project?
An SAP access management project is any structured effort to change how users get, hold and lose access to SAP systems. That includes role redesigns, SoD remediation, implementing GRC software, introducing access request and review workflows, and rebuilding security for an S/4HANA or SAP cloud migration.
The goal is always the same: give people the access they need to do their jobs, and nothing that creates unmanaged risk, in a way that can be proven to auditors and sustained over time.
Why Do SAP Access Management Projects Fail?
Across SAP security engagements, the same failure patterns appear again and again. Here are the eight most common.
1. The Project Is Treated as an IT Exercise
SAP access decisions are business decisions. Who can create a vendor, release a payment or change a price is a question for finance, procurement and operations, not just the SAP security team. When a project is owned solely by IT, roles get designed around technical transactions rather than real jobs, business sign-off becomes a rubber stamp, and users push back at go-live because nobody asked them how they actually work.
What works instead: appoint business role owners for each process area, and make them accountable for approving role content and SoD risk acceptance.
2. Legacy Roles Are Migrated As-Is
"Lift and shift" is tempting, particularly under migration deadlines. But copying ECC roles into S/4HANA, or carrying them into a RISE with SAP landscape, simply moves existing SoD conflicts, excessive access and unused authorisations into the new system. Worse, it often adds new risk, because Fiori apps and new transactions are bolted on without anyone checking what they open up.
We cover this in more depth in RISE with SAP: Your Roles Are Migrated, But Are Your Risks?
3. The Scope Tries to Fix Everything at Once
Big-bang redesigns covering every module, every system and every user are the projects most likely to stall. They take longer than planned, lose business attention, and often get cut back halfway through, leaving a mix of old and new roles that is harder to manage than either.
What works instead: phase by risk. Start with the highest-risk processes, such as procure-to-pay, payroll and general ledger, prove the approach, then extend it.
4. The Role Design Is Too Broad or Too Granular
Role design is a balancing act. Broad, job-based "mega roles" are easy to assign but almost always contain internal SoD conflicts. Highly granular task roles are clean on paper but can multiply into thousands of roles that are impossible to administer, review or explain to auditors.
The right level depends on your organisation's size, processes and support capacity. A design your team cannot maintain will degrade quickly, no matter how good it looked at go-live.
5. The SoD Rule Set Doesn't Reflect the Business
An out-of-the-box rule set is a starting point, not an answer. Applied without tailoring, it can flag hundreds of conflicts that don't matter to your business while missing those that do, such as risks in custom transactions or industry-specific processes. Teams then lose confidence in the results and stop acting on them.
A good rule set is reviewed with the business, includes custom transactions and Fiori apps, and is maintained as SAP and your processes change. Our guide to managing SoD in SAP explains the fundamentals.
6. Testing Is Rushed or Skipped
Security testing is often squeezed at the end of a project timeline. The result is predictable: on day one, users can't post invoices, run month-end or approve orders. Under pressure, support teams hand out broad access or emergency IDs to keep the business running, and within a week the new design is compromised.
What works instead: test roles with real business users running real scenarios, check new roles against the SoD rule set before go-live, and plan hypercare with a controlled process for fixing access issues fast.
7. Data Clean-Up Is Left Until Last
Projects that skip user clean-up end up designing, mapping and testing access for people who shouldn't have it at all. Removing terminated, dormant and generic users before the project starts shrinks the scope, reduces mapping effort and gives a cleaner baseline to measure improvement against.
8. There Is No Plan to Sustain the Result
This is the most common and most expensive failure. A project delivers clean roles and a low conflict count at go-live, then the team moves on. Over the following months, ad hoc role changes, copied user access and urgent requests reintroduce conflicts. By the next audit, the organisation is close to where it started.
Sustaining the result needs continuous SoD monitoring, risk checks on every access request, regular user access reviews and clear ownership of each role.
What Are the Warning Signs an SAP Access Project Is in Trouble?
Watch for these early indicators:
- Business stakeholders stop attending design workshops or delegate sign-off
- The role count keeps growing with no clear rationale
- Testing windows shrink as the go-live date holds firm
- The SoD conflict count is reported but not acted on
- "Temporary" broad access is used to unblock users and never removed
- Nobody can say who will own role maintenance after go-live
If you see two or more of these, it is worth pausing to reset scope, ownership or timeline before go-live rather than after.
What Do Successful SAP Access Management Projects Do Differently?
Projects that succeed tend to share a few characteristics:
- Business-led ownership, with named role owners who approve content and accept risk
- A clean baseline, starting with user clean-up and an honest current-state risk analysis
- Phased scope, prioritised by risk rather than by module or org chart
- Design for maintainability, at a role granularity the support team can sustain
- Simulation before change, checking every new or changed role against the SoD rule set before it reaches production
- Thorough user testing and a planned hypercare period
- Continuous monitoring after go-live, so drift is caught as it happens
- A realistic pace, set by the business's capacity to engage, not just the project plan
How Do CERPASS and, the trusted global SAP Security and GRC specialists, CompliantERP Help SAP Access Projects Succeed?
CERPASS Software is a cloud-based GRC solution for SAP, built on SAP Business Technology Platform, listed on the SAP Store and certified Clean Core with SAP. It supports access projects at every stage:
- Before the project: baseline SoD and critical access analysis, so you know where the real risk is
- During design: simulation of new and changed roles against your rule set before they go live
- At go-live: controlled emergecny access, urgent fixes are logged and reviewed rather than handed out unchecked
- After go-live: continuous SoD monitoring, access reviews and audit-ready dashboards that stop drift
For organisations that want expert delivery alongside the software, CompliantERP uses CERPASS to run SAP security reviews and role redesigns, including security for S/4HANA, BTP and SAP cloud products. Read how other organisations have approached it in our customer success stories.
FAQs About Why SAP Access Management Projects Fail
What is the main reason SAP access management projects fail?
The main reason is treating access management as a technical IT project rather than a business one. Without business ownership of roles and risk decisions, designs don't reflect how people work, users resist at go-live, and nobody is accountable for keeping access clean afterwards.
Should we copy our existing roles when moving to S/4HANA?
Copying existing roles is the fastest option but carries every existing SoD conflict and excess authorisation into S/4HANA. A better approach is to analyse current roles for risk and usage first, then redesign or clean them up as part of the migration, including the Fiori apps they grant.
How do you stop SoD conflicts coming back after a role redesign?
Stop conflicts returning by running a risk check on every access request and role change, monitoring SoD continuously rather than annually, running regular user access reviews, and assigning a business owner to each role. Tools such as CERPASS Software automate these checks.
How granular should SAP roles be?
SAP roles should be granular enough to avoid built-in SoD conflicts but not so granular that the role count becomes unmanageable. The right level depends on your organisation's size, processes and support capacity, and should be agreed with the business before design starts.
Why do users lose access at go-live after a security redesign?
Users usually lose needed access at go-live because role testing was too limited, user-to-role mapping was incomplete, or real business scenarios such as month-end weren't tested. Testing with actual users and planning a hypercare period prevents most of these issues.
Do we need GRC software for an SAP role redesign?
GRC software isn't strictly required, but it makes a redesign far safer. Simulating roles against an SoD rule set before go-live prevents new conflicts, and continuous monitoring afterwards protects the investment. CERPASS Software provides both without a lengthy implementation.
Make Your Next SAP Access Project the One That Sticks
SAP access management projects don't fail because the problem is unsolvable. They fail because of ownership, scope, testing and sustainability. Get those right and the result lasts well beyond go-live. Talk to the CERPASS team about how simulation, continuous SoD monitoring and expert delivery from CompliantERP can help your next access project succeed.
