How should organisations design access certification workflows for ERP and cross system reviews?

Why Access Certification Breaks Down in ERP and Shared Business Systems

access certification for ERP and cross-system reviews works best when reviewers can judge access against business ownership, not just a list of accounts. In ERP, the same user may hold roles that span finance, procurement, inventory, or HR workflows, so a simple “keep or remove” decision is rarely enough. The workflow has to surface application role meaning, downstream system reach, and who actually understands the business risk of each entitlement.

That is why certification design should begin with clean scoping, role mapping, and reviewer assignment before any approval window opens. If owners are asked to certify without that context, they tend to rubber-stamp access, especially where role names are technical, inherited, or detached from real business duties. Current guidance also suggests that access reviews are most defensible when they are tied to clear ownership and a documented entitlement model, rather than to a generic user export. The OWASP Non-Human Identity Top 10 is useful here because ERP ecosystems often include service accounts, integrations, and automation that sit alongside human access and still need governance.

In practice, many organisations discover that certification failure starts as a mapping problem long before it becomes a review problem.

How to Structure the Review so Approvers Can Make Safe Decisions

A workable ERP certification workflow translates technical access into business-readable review units. Instead of presenting every raw account, group entitlements by application, role, privilege tier, and owner. Then give reviewers the minimum context needed to answer three questions: what the access allows, whether the user still needs it, and whether the access creates segregation-of-duties or fraud risk. For cross-system reviews, include the upstream identity source and any downstream systems that inherit access, because the reviewer needs to understand the full blast radius of one entitlement decision.

• Start with an authoritative snapshot of active users, roles, privileged assignments, and dormant access.
• Map each entitlement to a business owner who can evaluate the access in operational terms.
• Separate standard access from elevated or exception-based access so reviewers do not treat both as equal.
• Show risk indicators such as last use, role conflicts, and system-to-system inheritance alongside the entitlement itself.
• Require a clear outcome for every item: certify, revoke, reduce, or defer with documented justification.

For ERP environments, this workflow should also account for how roles are built. A reviewer cannot fairly approve a composite role if they cannot see which underlying permissions it contains. That is where access reviews often become superficial: they are built around account ownership, but the real risk sits in the role design, inherited permissions, and cross-application propagation. NHIMG research on NHI governance is relevant because modern enterprises routinely have more machine and service identities than human ones, and ERP review programs increasingly have to handle both in the same certification cycle.

The OWASP Non-Human Identity Top 10 helps frame this governance layer, while NIST control families on access review and auditability reinforce the need for repeatable evidence, reviewer accountability, and traceable decisions. These workflows tend to break down when role hierarchies are opaque or when cross-system entitlements are reviewed as isolated records rather than as part of a connected access path.

Common Design Trade-offs and Edge Cases in Cross-System Certifications

Tighter certification often increases reviewer burden, so organisations have to balance precision against fatigue. If the workflow is too granular, business owners spend time on low-value confirmations and start approving by habit. If it is too coarse, risky access gets hidden inside broad role bundles. The best practice is evolving toward tiered review: high-risk privileges, SoD conflicts, and dormant access get full scrutiny, while low-risk standard access can be certified in smaller batches.

Cross-system reviews also create edge cases where ownership is unclear. A user may be provisioned in ERP by HR, consumed by finance reporting, and synchronized into another operational platform. In those cases, the certification workflow should not force one owner to guess across all systems. Instead, it should route each entitlement to the person who understands its business impact, while retaining a central record of the final decision. This is especially important when access is inherited through integration accounts or automation, because the apparent “user” may actually be a process identity with wider reach than the visible record suggests.

One NHIMG statistic is particularly relevant: only 5.7% of organisations have full visibility into their service accounts. That matters because hidden or poorly understood non-human access can make an ERP review look complete while leaving the highest-risk access paths untouched. The practical lesson is to design the certification process around ownership, impact, and inheritance, not around account lists alone.

Risk and Threat Considerations

ERP certification workflows create governance risk when they fail to expose inherited privilege, dormant access, or cross-system reach. They also create security risk when review evidence is too thin for approvers to distinguish routine access from access that can alter financial, operational, or administrative records. In mixed human and machine environments, the danger is that the review appears complete while high-impact non-human access remains effectively outside the control model.

Failure mechanism: Reviewers approve access they do not understand because the workflow presents technical entitlements without business context, or because composite roles and linked systems hide the true privilege path. Attackers and insiders can then abuse excessive or overlooked access, especially where service accounts, integration identities, or privileged ERP roles are exempt from meaningful scrutiny.

Impact: Unnecessary access persists, segregation-of-duties controls weaken, and compromised or misused accounts can alter transactions, approvals, or reporting across multiple systems before the issue is detected.

Practitioner Guidance

What to prioritise: Build the review around entitlement meaning, not account volume. If approvers cannot tell what a role changes in the business process, the certification is not ready for production use.

What to verify: Check that every reviewed item has a named owner, a current business purpose, and a visible path to downstream systems or inherited permissions. If those three elements are missing, treat the item as unreviewable until the mapping is fixed.

Common mistake: Treating cross-system certification as a periodic compliance exercise instead of a control over real privilege. The strongest programs remove access based on unresolved uncertainty, rather than asking reviewers to guess their way through ambiguity.

Practitioner takeaway: The workflow should make risky access easier to see than safe access is to approve; if it does not, the review will validate the directory, not the control.

Related resources from NHI Mgmt Group

• What happens when organisations try to manage access reviews and requests without automated identity workflows?
• How should security teams design access certification campaigns to keep reviews sustainable in large organisations?
• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?