ERP access control debt can turn old roles into current risk
ERP access control can drift far from the business roles and responsibilities it was designed to reflect. CIOs need to treat authorization as an ongoing governance discipline.
ERP access control refers to the system's gatekeeping mechanisms that determine what information people or AI agents can see and which actions they can perform. Think of this access control as a three-legged stool. The first leg is authentication, which verifies user identity. The second leg is identity management, which governs digital identities throughout the employment cycle. The third leg is authorization, which defines what verified users are allowed to do.
Combined, these functions provide the means to enforce rules that secure business responsibilities, workflows and decision rights. However, when done well, ERP access control shifts from a mere security safeguard to a core governance mechanism that protects data, supports regulatory compliance and prevents inappropriate or conflicting actions.
For CIOs, that distinction is becoming more important as ERP access expands beyond employees and contractors to nonhuman identities such as AI agents. The issue is no longer simply whether the right person or system has the right permission but whether the authorization model still reflects the business's actual decision rights -- and whether the ERP system is enforcing that model as roles, processes and technologies change.
"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," explained Mudita Khurana, staff security engineer at Airbnb.
Ideally, ERP access control should be managed proactively as a strategic governance discipline rather than as a technical security or compliance exercise. The challenge is to establish a manageable authorization model and prevent it from deteriorating as roles, processes, technologies and organizational structures 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," said Srinivas Chippagiri, a senior member of the technical staff at Tableau.
Addressing issues in authorization architecture
As counterintuitive as it seems, "a CIO can have an immaculate authorization design and a system that doesn't honor it," said Juan Perez-Etchegoyen, CTO and SAP and Oracle ERP security expert at Onapsis. "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."
Other factors can muddy the understanding between perceived and actual events. "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," said Perez-Etchegoyen. But that typically comes after a gap widens between what the business believes and what IT believes are the defining parameters for which identities can perform which tasks.
Ideally, ERP access control should be proactively managed as a strategic governance discipline rather than simply as a technical security or compliance exercise.
A sound authorization architecture begins with the business and not with IT or the ERP platform. Mapping job responsibilities, process steps and decision rights to system permissions requires a keen awareness of how the organization is set up and how it operates, not just pinning it on a map of the technical end of things.
The mistake most organizations make with ERP access control "starts at the very beginning, treating it as a technical setup task owned by IT rather than a governance decision owned by the business," said Arjun Jaggi, an applied AI researcher and industry executive.
"Someone in IT gets handed a list of roles to configure, builds a role-based model that maps reasonably well to the org chart at that moment and ships it. That model is correct on day one. It's wrong within about 18 months," Jaggi added.
How to design an authorization architecture
Clarity regarding the necessary components of an authorization model is essential to satisfy all governance requirements, now and in the future. This clarity will go far in guiding the design strategy.
"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," said Thiago Vieira, a cybersecurity lawyer, digital forensic expert and CEO at Cybertech Acceleration. "I've seen companies lose winnable fraud cases because change logs were nonexistent, [resulting in] a lack of evidence."
Vieira recommends the following guidelines for designing an organization's authorization architecture:
Revoke access permissions before granting new ones when an employee transfers to a different role.
Implement mandatory end dates for all non-employee identities.
Set time limits on privileged access by default, ensuring the sessions are recorded.
Address nonhuman identities, such as those for AI agents, which are often overlooked.
Role-based access control (RBAC) is typically the foundation of authorization. It groups permissions into understandable roles tied to real business functions. Exceptions and contextual controls can accommodate unusual duties, temporary assignments or conditions such as location and transaction value without creating a quagmire of excessive one-off roles. But be careful because RBACs can easily be used incorrectly.
"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," said Chippagiri.
Roles should be narrow enough to prevent unnecessary access but simple enough for business managers to understand and maintain. Privileged authority, including the ability to change configurations, manage users or override controls, requires stricter approval, monitoring and time limits. Otherwise, excessive customization and unmanaged exceptions can quickly produce permission sprawl.
"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," said Chippagiri.
But even a well-designed model deteriorates as employees and non-human identities join, transfer or leave; contractors come and go; AI agents fail, change or are replaced, and business processes change. Access that is not promptly revised accumulates into entitlement drift. A transferred employee, for example, might retain old permissions while receiving new ones, eventually gaining authority far beyond current responsibilities.
"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," said Yulia Plugatyreva, senior IT auditor at financial services company Chime.
This drift can also undermine segregation of duties by allowing one person to initiate, approve and complete incompatible parts of a transaction. The resulting buildup of outdated roles, excess permissions and poorly documented exceptions creates authorization debt.
Plugatyreva contends that the most effective programs monitor the points at which access becomes risky. She cited the following examples: an ERP account remains active after Workday records a termination; an employee changes jobs but keeps access to their prior role; a direct permission is granted outside an approved role; a temporary privileged account does not expire; or workflow delegation creates a self-approval path.
"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," said Plugatyreva.
Pam Baker is a freelance journalist and the author of books including ChatGPT For Dummies and Generative AI For Dummies. Baker is also an instructor on AI topics for LinkedIn Learning and a member of the National Press Club, the Society of Professional Journalists and the Internet Press Guild.
