How should security teams implement ERP access governance before go-live?

Why This Matters for Security Teams

ERP access governance has to be decided before go-live because the first production access model becomes the default operating model. If ownership, approval paths, and provisioning rules are still informal at cutover, business users inherit entitlements that are hard to unwind and even harder to audit. That creates preventable segregation-of-duties conflicts, emergency access sprawl, and manual exceptions that outlive the project.

This is especially important in complex ERP estates where finance, procurement, manufacturing, and HR processes overlap. Current guidance suggests treating access design as part of control design, not a post-implementation cleanup task, and aligning it with NIST Cybersecurity Framework 2.0 and the role governance patterns discussed in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. For broader identity risk context, the Top 10 NHI Issues article is also useful because ERP governance failures often mirror the same ownership and lifecycle gaps seen in other identity programs. In practice, many security teams encounter the true entitlement model only after auditors, operations, or finance have already been forced to clean up the mess.

How It Works in Practice

Effective pre-go-live governance starts with defining who owns each ERP role, who approves it, and which business process justifies it. That means mapping roles to process steps, not to job titles alone, then validating those mappings during UAT so toxic combinations can be identified before production access exists. The access model should also distinguish between standard access, privileged access, and temporary exceptions, because each needs a different approval route and review cadence.

For security teams, the practical sequence is usually: inventory business processes, translate them into least-privilege roles, test those roles against real scenarios, and document any unavoidable conflicts with compensating controls. A mature program also includes periodic recertification, evidence capture for auditors, and a clear path for emergency access that expires automatically. That approach aligns with the control themes in OWASP Non-Human Identity Top 10 and the audit expectations covered in Ultimate Guide to NHIs — Regulatory and Audit Perspectives, because both emphasise traceability, ownership, and control over standing access.

• Define role owners and approvers before configuration is frozen.
• Validate every business-critical role in UAT with real transactions and exception scenarios.
• Require documented SoD conflicts, time limits, and compensating controls for every exception.
• Separate privileged access workflows from standard user access workflows.
• Build recertification into the operating cadence, not as a one-time post-launch task.

This guidance tends to break down when ERP roles are cloned from legacy systems without process redesign, because hidden access habits get reintroduced under a new platform name.

Common Variations and Edge Cases

Tighter access governance often increases project overhead, so organisations have to balance launch speed against control confidence. That tradeoff becomes sharper when the ERP program spans multiple legal entities, shared service centres, or country-specific finance rules, because a single role model may not fit every operating unit.

There is no universal standard for every exception scenario yet, but best practice is evolving toward stronger lifecycle controls and more explicit audit trails. Some environments will need temporary elevated access for cutover, data migration, or hypercare, while others can keep access fully pre-approved through tightly scoped role bundles. For deeper lifecycle and risk context, the Ultimate Guide to NHIs and 52 NHI Breaches Analysis show how unmanaged identity exceptions tend to compound once systems go live. The same lesson applies here: if the business cannot explain why an entitlement exists, neither auditors nor security teams should accept it as permanent. These controls work best when the ERP design is still flexible and break down when cutover deadlines force access decisions to be made after users are already live.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• What is the difference between role-based access and API key governance for NHI security?
• How should security teams use IAST and RASP in NHI governance?