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.
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.
Across SAP security engagements, the same failure patterns appear again and again. Here are the eight most common.
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.
"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?
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.
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.
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.
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.
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.
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.
Watch for these early indicators:
If you see two or more of these, it is worth pausing to reset scope, ownership or timeline before go-live rather than after.
Projects that succeed tend to share a few characteristics:
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:
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.
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.
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.
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.
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.
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.
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.
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.