What should security teams do first when ERP access is poorly visible?

How to triage poorly visible ERP access

The first job is discovery, not cleanup. If you cannot see ERP access clearly, assume the risky part is the unknown path count, not just the known users. Build an inventory that includes direct human logins, shared accounts, background jobs, integrations, remote support paths, and any automation that can read or change ERP data or workflows.

That inventory should be structured enough to answer three questions: who or what can reach the ERP, through which interface, and under whose approval or ownership. For teams that already use Segregation of Duties (SoD) Guide, the practical value is that access discovery exposes whether toxic combinations are hidden inside ERP roles, delegated access, or service paths rather than only in named user accounts.

In practice, start by separating visible, partially visible, and invisible access paths. “Visible” means you can tie the path to an owner, an approval record, and a defined business purpose. “Partially visible” means some controls exist but the path is not fully governed. “Invisible” means the team cannot explain it confidently. That classification gives IAM and IGA teams a baseline that supports remediation sequencing instead of forcing them to guess where policy enforcement should begin.

What to classify once the inventory exists

Once the path list exists, classify each entry by governance state, not by technical convenience. A governed path should have an owner, a review cadence, a clear entitlement model, and a rotation or revocation process where credentials or tokens are involved. A partially governed path may be monitored or approved in some places, but still lacks one or more of those controls. An unmanaged path is the one that matters most, because it creates the highest likelihood of unauthorized ERP visibility, excess privilege, or hidden dependency.

That classification also helps distinguish business-critical access from inherited access. ERP environments often accumulate access through role sprawl, exception grants, legacy integrations, and one-off support arrangements. If you do not classify those patterns early, cleanup efforts usually focus on account counts instead of the actual control gaps. For access paths that depend on network entry points, the Remote Access Identity Guide is a useful companion because remote entry often becomes the hidden route into ERP workflows when direct application access looks controlled.

This is also where ownership becomes operational, not theoretical. If an ERP path has no accountable business owner, no technical owner, or no clear review evidence, treat it as a governance defect before you treat it as a tuning problem. The point of the classification is to make cleanup defensible: fix the worst exposure first, then tighten the control model around what remains.

Why this sequencing matters for cleanup and enforcement

Security teams should resist the urge to enforce policy before they know the real access surface. If enforcement starts too early, teams often break legitimate workflows, miss shadow integrations, or inherit false confidence from incomplete logs. Discovery first creates a defensible baseline for least privilege, entitlement review, and exception handling. It also gives the organisation a way to prove progress, because unmanaged paths can be counted down over time.

Where ERP access connects to financial controls, a strong reference point is NIST SP 800-53 Rev 5 Security and Privacy Controls because access control, identification and authentication, audit, and configuration management all depend on knowing the real population of ERP paths. CIS Controls v8 is also relevant when the team needs a practical sequence for inventory, account management, access control, and logging. For organisations aligning to formal governance, ISO/IEC 27001:2022 Information Security Management provides the broader control structure for access governance and review discipline.

The operational logic is simple: first expose the access surface, then decide which paths can stay, which need stronger controls, and which should be removed. That order prevents cleanup from becoming a documentation exercise and keeps the IAM and IGA work anchored to actual ERP risk.

Practitioner Guidance

What to verify: Do not trust directory data alone. Verify the ERP list against application logs, integration configurations, remote access records, privileged account inventories, and business owner attestations so hidden paths do not survive the first pass.

Implementation sequence: 1) inventory every ERP-reachable system, account, and integration; 2) classify each path as governed, partially governed, or unmanaged; 3) assign an owner and evidence source; 4) only then start cleanup, role redesign, or policy enforcement.

Common mistake: Teams often start by removing accounts they can see, while the real risk sits in service accounts, middleware, and exception-based access that never appears in the same report.

Practitioner takeaway: When ERP access is poorly visible, the first win is a defensible map of who can actually reach the system, because every later control decision depends on that baseline being real.

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?
• How should security teams govern API keys used for generative AI access?
• How should security teams prioritise NHI remediation in cloud environments?