SAP access review workflows expose the limits of manual certification

At a glance

What this is: This is an analysis of SAP Access Control user access review workflows and how they automate certification, delegation, and remediation.

Why it matters: It matters because IAM teams often treat access review as a compliance exercise, but the real control problem is whether the process can actually identify and remove excess access across roles, systems, and approvers.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Pathlock's guide to SAP Access Control user access review workflows

Context

SAP access review is a governance process, not an access-control primitive. The system can automate review scheduling, route requests to managers or role owners, and trigger removals when access is marked unnecessary, but the quality of the outcome still depends on role definitions, reviewer assignment, and source data integrity.

For IAM and IGA teams, the important question is whether the review workflow is certifying actual business need or merely processing records on a schedule. That distinction matters across human accounts, service accounts, and broader lifecycle governance because stale entitlement data can make a compliant process produce an unsafe result.

Key questions

Q: How should security teams run access reviews without turning them into a compliance checkbox?

A: Security teams should run access reviews against current entitlement data, current approver assignments, and a clear remediation path. If the campaign ends with approvals but no actual removal, it is paperwork, not governance. The process should be measured by whether unnecessary access is removed and whether exceptions are justified with business context.

Q: Why do business-role reviews sometimes miss excessive access?

A: Business-role reviews can hide excessive technical permissions when the reviewer sees only a broad functional grouping. That makes certification faster, but it reduces visibility into nested, composite, or inherited access that may carry higher risk. Teams should use business roles for efficiency and drill down to technical roles where privilege is concentrated.

Q: What breaks when reviewer assignment is based on outdated org data?

A: When reviewer assignment is based on outdated org data, the wrong manager or role owner certifies access and the control loses business accountability. The workflow may still complete, but the decision no longer reflects the current operating structure. That weakens the evidentiary value of the review and increases the chance that stale access survives.

Q: How can organisations tell whether access review is actually reducing risk?

A: Organisations should look beyond campaign completion and measure downstream removal, reopened exceptions, and the number of high-risk roles still present after review. If rejected access does not disappear from the target system, or if repeated cycles keep certifying the same excess entitlements, the programme is not reducing risk effectively.

Technical breakdown

How SAP UAR generates review campaigns

SAP Access Control can generate User Access Review campaigns from scheduled jobs that pull user, role, and system data from connected repositories. The process can target technical roles, business roles, or both, which changes the level of review granularity and the burden placed on reviewers. When business roles are used, the workflow can compress complexity into a more understandable business function view while still allowing drill-down to underlying technical access. The technical challenge is that the campaign only reflects the data it is fed. If repository sync, role import, or assignment logic is stale, the review exercise can be accurate in form but incomplete in substance.

Practical implication: Validate source data refresh and role scope before every certification cycle.

Delegated review and workflow-driven remediation

The workflow is designed to delegate decisions away from a central security team to managers or role owners who understand job function. Reviewers can approve access, remove unnecessary roles, or forward items when they are not the right approver, and the system can route escalations and record the full audit trail. This is effectively a governance pipeline: decision, disposition, and remediation are connected. The control risk is reviewer drift, where the person assigned to certify access is no longer the right business authority, or where a workflow is complete on paper but remediation never reaches the underlying entitlement store.

Practical implication: Tie reviewer identity, approver authority, and removal execution to the same governed process.

Why audit trails matter in access certification

A UAR workflow becomes useful to auditors only when it preserves enough context to explain who reviewed what, why a role was kept or removed, and whether remediation actually occurred. Dashboards and history reports are not just reporting features. They are evidence that the organisation can reconstruct access decisions over time and show that review cycles were completed with traceable outcomes. However, auditability does not automatically equal risk reduction. A clean record set can still mask weak role design, duplicate requests, or review paths that are too coarse to catch privilege creep.

Practical implication: Use history reports to test control effectiveness, not just to satisfy audit requests.

NHI Mgmt Group analysis

Automated access review only works when the entitlement model is already trustworthy: SAP UAR can streamline certification, but it cannot correct bad source data, misaligned roles, or stale reviewer assignment by itself. The workflow simply scales whatever governance assumptions are already embedded in the repository and job logic. The practical implication is that organisations must treat UAR as a control surface that depends on upstream identity hygiene, not as a substitute for it.

Business-role abstraction reduces reviewer burden, but it can also hide technical over-provisioning: When reviewers see a business role instead of the underlying transactions and objects, the process becomes easier to complete yet harder to inspect at depth. That trade-off is acceptable only if drill-down is routinely used for high-risk roles and exceptions. The practical implication is that teams should not confuse faster certification with better certification.

Delegated review exposes an accountability gap when approver and entitlement owner diverge: Managers and role owners are useful reviewers only when they still have operational knowledge of the account and authority over the access being certified. If the workflow assigns reviews based on legacy organisational data, the control is delegating decisions to the wrong business context. The practical implication is that access review governance must include reviewer validation, not just reviewer assignment.

Access review is a lifecycle control, not a point-in-time task: The value of UAR comes from closing the loop between certification, removal, and re-certification across changing business roles. If rejected access is not actually removed, or if new requests are regenerated without fixing the underlying role design, the organisation is only documenting privilege creep. The practical implication is that teams should evaluate UAR outcomes by remediation quality, not campaign completion rates.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that governance lag often outlasts discovery.
• For lifecycle control detail, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding should be tied together.

What this signals

Access review is becoming a data-quality test as much as a governance process: if reviewer assignment, role import, and repository synchronisation are not accurate, certification output will look orderly while still reflecting stale access. That is why the operating question is no longer whether the workflow exists, but whether it is connected to current identity state and current business ownership.

The broader signal is that lifecycle governance now spans human accounts, service accounts, and enterprise roles through the same operational discipline. Teams that treat certification as an annual checkpoint will keep missing drift, especially where business abstractions hide technical privilege.

For the next stage of maturity, use the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs as the reference point for how review, rotation, and offboarding fit together in one control loop.

For practitioners

• Revalidate reviewer assignments before each cycle Check that every manager and role owner still has current authority over the users and roles in scope. Where department moves or organisational changes have occurred, regenerate review routing before launch so the campaign does not go to a legacy approver.
• Separate business-role convenience from technical-role assurance Use business roles to simplify the review experience, but drill into the underlying technical roles for privileged or sensitive access. The same review should not rely on a high-level business grouping when the real risk sits in nested or composite authorisations.
• Test whether removals actually de-provision access Verify that a rejection or removal decision triggers the downstream entitlement change in the connected SAP system or integrated target system. A certification campaign is not effective if the workflow closes without changing the access record.
• Review repository sync and import jobs as control dependencies Confirm that the repository object sync job and role import jobs are running successfully before certification begins. Stale HR data, missing roles, or overwritten role attributes can produce a clean-looking review campaign that certifies the wrong access.
• Measure remediation outcomes after the campaign closes Track how many approved removals were executed, how many rejected items were reopened, and how many roles remained unchanged despite being flagged. Those measures tell you whether the process is reducing privilege or only generating evidence.

Key takeaways

• SAP UAR can automate review execution, but it cannot rescue poor entitlement data or misaligned reviewer ownership.
• Business-role convenience improves usability, yet it can also obscure technical over-provisioning if teams do not drill down where risk is concentrated.
• The real measure of access review maturity is whether rejected access is actually removed and stale permissions stay out of the next cycle.

Key terms

• User Access Review: A user access review is a governance process that checks whether assigned permissions still match job responsibilities. In SAP-style certification workflows, it combines reviewer assignment, approval decisions, and remediation so the organisation can remove access that is no longer justified.
• Business Role: A business role groups underlying technical permissions into a function that non-specialists can review more easily. It simplifies certification, but it can also hide granular privilege if teams do not drill into the technical roles behind the business wrapper.
• Composite Role: A composite role bundles multiple single roles into one assigned package of access. It can speed administration, but it also creates a risk that reviewers approve broad access without checking whether each component still has a current business need.
• Repository Synchronisation: Repository synchronisation keeps the access control system aligned with source identity, role, and HR data from connected systems. If it is stale or incomplete, downstream review campaigns can certify outdated access and lose control value even when the workflow itself functions correctly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Pathlock: SAP GRC Access Control user access review workflow guidance. Read the original.