Why ERP access control debt turns old roles into risk

A clean ERP role model can still accumulate authorization debt

An ERP authorization model can be correct at deployment and become unsafe as the business changes. ERP access determines what people and AI agents can see and which actions they can perform, so permissions must remain aligned with changing responsibilities. CIOs need to keep business decision rights, the authorization model and the controls the ERP enforces aligned over time. Gaps among those layers turn previously appropriate access into current risk.

Keeping those layers aligned depends on three mechanisms with different jobs. Authentication verifies identity, identity management governs digital identities through their lifecycle, and authorization determines what a verified identity may do. Together, they enforce business responsibilities, workflows and decision rights while protecting data, supporting regulatory compliance and preventing inappropriate or conflicting actions. As the organization changes, outdated roles, excessive permissions and poorly documented exceptions accumulate as authorization debt.

Authorization debt changes the standard for judging an access-control program because deployment establishes only the initial state. Srinivas Chippagiri, a senior member of the technical staff at Tableau, emphasizes how the organization handles inevitable change: “The measure of a good program isn’t how clean it is at go-live; it’s how slowly it decays and how quickly it self-corrects. Design for the drift, because the drift is guaranteed.” Meeting that standard requires defining correct business authority, then continuously checking the two places where actual access can diverge from it.

Start with business decision rights

Correct authority begins with the decisions and responsibilities people have in the business. Job responsibilities, process steps and decision rights must be mapped to permissions based on how the organization operates. Mudita Khurana, staff security engineer at Airbnb, gives a concrete example: “For example, an employee who is an accounts payable specialist may be allowed to create supplier records, but only for the U.S. legal entity. Although this is enforced via a security control, it is actually the governance model underlying it that decides which employee with which role can access what.”

Khurana’s distinction sets the order of work because an ERP control implements a decision that originates in the business. The business determines whether an accounts-payable specialist has supplier-creation authority and whether that authority stops at the U.S. legal entity; the security control then enforces those conditions. Authorization is a governance discipline for expressing who has which authority under which conditions. A proactive approach gives the organization a stable basis for controlling access as responsibilities change.

That governance basis can fail before anyone configures a role when business and IT have different assumptions about which identities should perform which tasks. Arjun Jaggi, an applied AI researcher and industry executive, says the failure “starts at the very beginning, treating it as a technical setup task owned by IT rather than a governance decision owned by the business.” IT can translate business requirements into ERP controls, while the business must determine the authority those requirements represent. Clear ownership gives technical teams a decision model they can encode.

Chippagiri makes the ownership problem more explicit: “ERP access control fails when IT owns it, because IT knows the system but not the risk. Access design is the codification of who is trusted to do what, and that’s a question of business governance. Treat it as a technical configuration, and you get roles that mirror the software’s menus instead of the company’s control structure.” A role organized around available ERP functions can be technically coherent while failing to represent how responsibility and risk are divided inside the company. Business ownership connects those technical roles to the decisions they are meant to control.

Role-based access control, or RBAC, provides a common way to encode that connection. RBAC groups permissions into roles that correspond to real business functions, letting managers reason about access in terms they understand. Those roles need enough scope limits to prevent excessive authority while staying simple enough for business managers to understand and maintain. Too much complexity makes the role catalog difficult to govern even when each underlying permission once had a technical justification.

Some responsibilities exceed a standard role’s boundaries, so contextual controls and exceptions can accommodate unusual duties, temporary assignments, locations or transaction values without creating large numbers of one-off roles. That flexibility adds a governance burden because RBAC can be misused, while excessive customization and unmanaged exceptions can produce permission sprawl. Privileged powers such as changing configurations, administering users or overriding controls have greater consequences because they can alter controls governing other identities. Those powers consequently need stricter approval, monitoring and time limits.

With those boundaries established, role design can follow a clear sequence: define the job, identify segregation-of-duties constraints and then map the required permissions. Segregation of duties, or SoD, prevents one identity from accumulating incompatible authority across a business process. Chippagiri captures the design test this way: “Build roles from business functions, not transaction codes. Define the job, define the segregation-of-duties constraints it must respect, then map permissions. If you can’t explain a role in one sentence without naming a transaction code, it’s built wrong.” A role designed in that sequence expresses a business decision that can later be checked as the organization changes.

Gap one: the business changes faster than the authorization model

That later check matters because even a sound role model begins aging as the organization around it changes. Employees join, transfer and leave; contractors enter and exit; business processes are revised; and nonhuman identities change over their lifecycles. AI agents can fail, change or be replaced, so their authority also needs revision when their purpose or status changes. Access that remains after any of these transitions turns an originally correct decision into entitlement drift.

Jaggi describes how quickly that mismatch can emerge in a conventional implementation: “Someone in IT gets handed a list of roles to configure, builds a role-based model that maps reasonably well to the organization chart at that moment and ships it. That model is correct on day one. It’s wrong within about 18 months.” The “within about 18 months” period is Jaggi’s estimate, and its operational significance lies in the transition between organizational states. A model representing one state needs active maintenance to represent the next.

Employee transfers show how such a transition creates debt. A person can acquire permissions for a new position while retaining access from the previous role, gradually accumulating authority beyond current responsibilities. The same buildup can undermine SoD until one person can initiate, approve and complete incompatible parts of a transaction. Each entitlement may have had a legitimate origin even though the later combination violates the company’s current governance model.

Because transitions create the mismatch, they become important control points. Yulia Plugatyreva, senior IT auditor at financial services company Chime, identifies several concrete states worth detecting: an ERP account can remain active after Workday records the person’s termination, or an employee can change jobs while retaining old-role access. A direct permission can also appear outside an approved role, and a temporary privileged account can remain active beyond its intended period. Workflow delegation creates another path when it lets an identity approve its own activity.

Those cases explain why approved roles and scheduled certifications provide only part of the control. Direct permissions and temporary access can change effective authority between review cycles, while an employment event in Workday can leave the corresponding ERP account active until another process detects and resolves the mismatch. Workflow delegation can likewise change a control outcome while leaving the underlying role catalog unchanged. Transition monitoring has to observe effective access as it changes.

Effective-access monitoring also changes what an organization should measure. Plugatyreva says: “A mature ERP access program is not measured by the number of policies published or access reviews completed. It is measured by how quickly it detects that appropriate access has become inappropriate and whether the organization can prove it acted.” Completed reviews establish that a governance process ran, while detection speed establishes how quickly that process identifies a newly risky state. The second measure matters especially when a transition creates immediate exposure.

Periodic access review remains useful within that operating model, but transitions can occur between reviews. A termination, job transfer, direct grant, expired temporary purpose or new delegation can change risk immediately, so waiting for a later certification allows authorization debt to persist during the interval. Continuous governance covers that interval by monitoring changes alongside periodic inspection of the resulting access state. Review and transition detection consequently operate at different timescales.

The first gap is between changing business decision rights and the authorization model built to express them. Outdated roles, excessive permissions and poorly documented exceptions accumulate when the model falls behind the business. Closing that gap keeps intended authority current. CIOs then face a second question: whether the ERP actually behaves according to that current model.

Gap two: the ERP may not enforce the model on paper

A current authorization design establishes intended authority, while effective control depends on the ERP enforcing it. Juan Perez-Etchegoyen, CTO and SAP and Oracle ERP security expert at Onapsis, states the problem directly: “a CIO can have an immaculate authorization design and a system that doesn’t honor it.” Onapsis sells ERP security technology and services, so the company benefits commercially when organizations invest in identifying and correcting ERP security weaknesses. That commercial interest makes clear attribution important when evaluating Perez-Etchegoyen’s account of the enforcement problem.

Perez-Etchegoyen divides that problem into two governance concerns: “Access control governance has two halves. The first is the model, including the role catalog, SoD [segregation of duties] ruleset and its review cadence, to name a few elements, and most organizations only govern that half. The second is whether the model is actually enforced by the system underneath it: the code, the configuration, the interfaces and the patch level.” Role and SoD reviews establish what the organization intends the system to enforce. Verifying code, configuration, interfaces and patch levels establishes how the system implements that intent.

Those implementation elements create a separate source of drift because each can change how restrictions work in practice. A governance team can keep its role catalog current, maintain an appropriate SoD ruleset and execute its review cadence while the underlying system permits something different. Changes confined to the role catalog cannot repair an enforcement discrepancy in code, configuration, an interface or patch state. The second gap needs evidence from the system itself.

Perez-Etchegoyen describes the resulting measurement problem: “The access model on paper and the access model the system actually enforces are two different things, and almost nobody measures the gap between them.” Measuring intended permissions can establish the governed design, while a CIO also needs evidence that implementation continues to produce the restrictions that design requires. The enforcement check connects authorization governance to actual ERP behavior.

Because the two gaps arise in different places, they require different corrective actions. Business-to-model drift asks whether current roles, exceptions and entitlements still represent present responsibilities and decision rights. Model-to-system enforcement drift asks whether the ERP’s code, configuration, interfaces and patch state actually impose those rules. RBAC can address the first problem when its roles accurately capture the business; enforcement testing addresses the second.

Together, the gaps explain why initial role design and periodic access reviews are components of a larger control system. Changes to identities and responsibilities can create risky authority between reviews, while implementation changes can separate effective access from the model being reviewed. Continuous governance has to observe both kinds of change. It then has to turn each detected discrepancy into corrective work with an accountable owner.

Continuous governance means detecting, correcting and proving the response

Once both gaps are treated as changing conditions, the operating goal becomes keeping authorization manageable as roles, processes, technologies and organizational structures evolve. Detection has to identify when a previously legitimate entitlement becomes risky or the ERP stops enforcing an intended restriction. Correction then has to follow according to the seriousness of the event. Evidence completes the response by showing what the organization did.

Plugatyreva ties those steps to explicit accountability: “Each risk should have a defined owner, response time and evidence of resolution. High-risk events, such as a terminated user retaining access to the financial system or a new toxic combination of duties, should trigger immediate alerts. Lower-risk exceptions can be reviewed through a daily queue or quarterly certification.” The daily queue and quarterly certification are her recommended cadences for lower-risk exceptions. The appropriate response speed follows the level of risk.

That risk tiering turns transition monitoring into an operating process. An ERP account still active after termination or a newly toxic combination of duties demands immediate attention because effective authority is already inappropriate. Lower-risk exceptions can enter managed review processes with different response times. Assigning an owner and retaining evidence closes the loop by showing that detection led to a decision and resolution.

Evidence matters especially when the organization later has to reconstruct who held authority at a particular time. Thiago Vieira, cybersecurity lawyer, digital forensic expert and CEO at Cybertech Acceleration, frames the requirement this way: “The governance test isn’t about whether we can stop the wrong person from doing this; it’s about whether we can prove, 12 months later and to a standard [that] a judge will accept, exactly who did it and under what authority.” The 12-month period is Vieira’s illustrative evidentiary horizon, emphasizing the need to preserve a defensible history of actions and authority. Cybertech Acceleration operates in cybersecurity, giving Vieira and the company a commercial interest in organizations investing in cybersecurity, forensic and evidentiary controls.

Vieira’s case experience illustrates the consequence of losing that history: “I‘ve seen companies lose winnable fraud cases because change logs were nonexistent, [resulting in] a lack of evidence.” A later investigation depends on records establishing who held authority, what changed and what happened. Those records connect the state of authorization at the time of an event to the people or systems that acted under it. Evidence retention consequently belongs in the authorization architecture itself.

That evidentiary requirement also strengthens the case for lifecycle controls because clear transitions reduce ambiguity about authority. Vieira recommends revoking an employee’s previous permissions before granting new ones during a role transfer, directly addressing the accumulation of old and new authority. Every non-employee identity should have a mandatory end date, while privileged access should be time-limited by default and its sessions recorded. These controls constrain the transition states that Plugatyreva identifies as frequent points where appropriate access becomes risky.

Once transition controls cover employees and external workers, the same lifecycle discipline has to cover nonhuman identities explicitly. Vieira calls out AI-agent identities as a category that can be overlooked, so their access needs lifecycle treatment alongside employees, contractors and other identities. An AI agent that changes or is replaced creates an authorization event because its former authority has to be revised. A human employment record cannot trigger that machine-identity transition.

The resulting process makes continuous governance a response system with several speeds. High-risk transitions such as terminated-user access or a new toxic combination of duties trigger immediate alerts, while lower-risk cases can move through Plugatyreva’s daily queue or quarterly certification. Owners and response expectations establish responsibility for correction, and change records plus evidence of resolution establish what followed. Together, those records preserve both the correction of the risky state and the authority under which relevant actions occurred.

Extend lifecycle governance to AI agents

The need for machine-identity triggers becomes more important as AI agents expand the population with ERP access beyond employees and contractors. These agents can fail, change or be replaced, and Vieira’s warning that nonhuman identities are often overlooked makes explicit lifecycle controls necessary. Business authority still supplies the governing rule: each agent’s permissions should correspond to what that identity may currently do under its assigned responsibilities and conditions. Changes to the agent’s purpose or status become governance events.

Those events require organizations to manage an AI agent as an identity with a changing lifecycle. When an agent changes or is replaced, its existing authority needs revision, and any resulting risky access needs detection and correction. The ERP must also continue enforcing the intended authorization, while retained evidence must show how the organization responded. Applying those controls to human and nonhuman identities keeps the governing unit consistent even as the identity population expands.

Key takeaways for leaders

• Anchor ERP access in business decision rights: Business owners define who has authority to perform specific actions and under what conditions, while IT translates those decisions into roles and controls. Build roles around business functions and segregation-of-duties constraints.
• Monitor business-to-authorization drift: Job changes, terminations, direct grants, temporary access and workflow delegation can make previously appropriate permissions risky. Track these transitions continuously and use periodic certifications to review the resulting access state.
• Verify ERP enforcement: A current role catalog does not guarantee that the ERP enforces it correctly. CIOs need evidence that code, configuration, interfaces and patch levels continue to implement the intended authorization model.
• Tie detection to correction and evidence: Assign each access risk an owner, response time and resolution record. Escalate high-risk events immediately while routing lower-risk exceptions through appropriate review cycles and preserving evidence of authority and remediation.
• Apply lifecycle governance to AI agents: AI agents need explicit identity lifecycles because their purpose, configuration and status can change. Reassess permissions when agents change or are replaced, verify enforcement and retain evidence of resulting access decisions.