An enterprise resource planning (ERP) platform holds the general ledger, payroll, supplier master data and payment runs, so whoever controls its administration, its integration accounts or its transport of changes can move money and alter the books. Most ERP security work focuses on business roles and segregation of duties for end users. This guide looks at the platform underneath: technical administrator roles, interface and batch service accounts, keys and stored credentials, custom code and change transport, logging, and the platform's own lifecycle. It is vendor-neutral and based on NCSC, NIST SP 800-53, OWASP and CIS Controls v8.1 guidance. It is written for ERP platform teams, identity architects and security teams who assure finance systems. For choosing ERP security tooling, see ERP Security Buyer's Guide.
Key takeaways
- Technical administration is a separate risk from business access. A technical platform administrator can often bypass every business segregation of duties rule by changing roles, running code or editing tables directly. Govern these roles as privileged access.
- Interface accounts are the quiet privileged population. Banking, payroll, procurement, warehouse and reporting interfaces run under service accounts that frequently hold broad rights and passwords that never change.
- Change transport is a privileged path. Whoever can move code or configuration into production can change system behaviour; separate who develops, who approves and who imports.
- Protect payment and master data flows. Bank file outputs, supplier bank detail changes and payroll exports need integrity controls and alerts, not just access controls.
- Govern the platform's own identities. Review administrator, interface, batch and emergency accounts from outside the ERP team, on a fixed cycle.
What makes up the ERP platform's attack surface
An ERP estate is usually several tiers: application servers, a database, a presentation layer or portal, integration middleware, batch scheduling and a transport or deployment path between development, test and production. Cloud ERP services move some tiers to the provider, but the customer still owns the configuration, identities and integrations. The table below sets out the components to secure.
The component table reflects a common architecture and is NHI Mgmt Group's view, not a sourced description of any one product; your platform may name, merge or split these components differently.
| Component | What it can do | What an attacker gains |
|---|---|---|
| Technical administrator roles | Change users, roles, system parameters, security settings and logging | Grant any business access, switch off audit, run arbitrary programs |
| Interface and integration accounts | Post documents, read and write master data, exchange files with banks and partners | Create or alter transactions through a trusted channel |
| Batch and job scheduler accounts | Run scheduled programs such as payment runs and period close | Run high-impact programs under a non-personal identity |
| Change and transport path | Move code and configuration into production | Persistent logic that changes postings, approvals or authorisation checks |
| Database and operating system layer | Hold all ERP data and, often, credential stores | Read or change data with no application-level checks or logs |
| Payment and bank file outputs | Produce files the bank will act on | Redirect payments by altering a file between generation and transfer |
| Standard and default accounts | Ship with the platform for installation and support | Known account names, sometimes with known passwords |
The ATT&CK techniques this enables include T1078 Valid Accounts, T1098 Account Manipulation and T1213 Data from Information Repositories.
Administrative roles and separation of duties
- Split technical administration: separate user administration, role and authorisation maintenance, system configuration, transport import, database administration and audit log administration. No single person should be able to create a user, give it a role and delete the evidence (NIST SP 800-53 AC-5).
- Dedicated admin accounts with phishing-resistant MFA: technical administrators use accounts that do nothing else (CIS safeguard 5.4) and phishing-resistant MFA, usually through the identity provider (CIS safeguard 6.5). NCSC advises that full, system-wide access should be the exception, not the norm.
- No standing "all rights" profiles: most ERP platforms ship a profile or role that grants every authorisation. Keep it off all dialog users and release it only through an emergency access process with approval, time limit and after-the-fact review. See the Break-Glass Account Guide.
- Just-in-time technical access: release privileged technical roles through a privileged access management tool for a time window, with session recording for direct table maintenance and code execution. See the Privileged Access Management Guide.
- Restrict where administration comes from: administrative logon and database access only from privileged access workstations or a management network (see the Privileged Access Workstations Guide).
- Standard and default accounts: change every default password at installation, lock the accounts that are not needed and alert on any logon to them. Treat this as a recurring check after every upgrade or system copy, because copies can bring old account states back.
- Integrator and support access: implementation partners and vendor support get named, time-boxed accounts with recorded sessions, removed at the end of each engagement.
Business segregation of duties (who can create a supplier and pay it) is covered in the Segregation of Duties Guide. The point here is that technical roles sit above those rules and need their own separation.
Interface, batch and integration service accounts
ERP platforms exchange data with banks, payroll providers, procurement networks, tax engines, warehouses, reporting tools and, increasingly, AI agents. Each connection runs under a non-personal identity. The scoping below is our recommendation.
| Account type | What it should hold | What to avoid |
|---|---|---|
| Inbound interface (posting documents) | Authority to post the specific document types and company codes it handles | Wildcard authorisations across all transactions or organisational units |
| Outbound reporting or extraction | Read access to the tables or views the report needs | Write rights, or read access to payroll and bank data it does not use |
| Batch job owner | Rights to run the scheduled programs assigned to it | Dialog logon, or rights to change the programs it runs |
| Middleware or integration platform account | A separate account per connected system and direction | One shared technical account for every integration |
- Non-interactive account types: where the platform offers system or communication account types that cannot log on to the user interface, use them for interfaces and batch jobs.
- Inventory and ownership: record every interface account with its connected system, business owner, technical owner, authentication type and credential age (CIS safeguard 5.5). See the Service Account Security Guide.
- Stronger authentication than passwords: prefer certificates, mutual TLS or OAuth client credentials with short-lived tokens where the platform supports them. Where passwords remain, vault them and rotate on a schedule and whenever someone with access leaves (IA-5). See the Secrets Management Guide.
- Stored connection credentials: ERP platforms often store credentials for remote connections between systems inside the application. A connection with a stored high-privilege user from a development system into production gives every developer a path into production. Remove stored privileged logons from lower environments and review trusted system relationships.
- AI agents and automation: agents and robotic process automation acting in the ERP need their own identities, scoped like any interface account, never a shared administrator. See the RPA and Bot Identity Security Guide.
- API exposure: ERP web services and APIs need object and function level authorisation checks (OWASP API Security Top 10 2023: API1 Broken Object Level Authorization and API5 Broken Function Level Authorization). See the API Security Guide.
Change transport and custom code
Custom code and configuration changes run with platform privileges and can change how postings, approvals and authorisation checks behave.
- Separate develop, approve and import: developers should not hold transport import rights in production, and production should not allow direct changes except through a recorded emergency route (CM-3).
- Lock production against direct change: keep the production client or tenant closed to configuration and code changes, and alert whenever it is opened.
- Review code for authorisation checks: custom programs that skip authority checks, call operating system commands or write directly to tables are common sources of privilege escalation. Include these checks in code review and in automated scanning.
- Configuration baseline: export security-relevant parameters (password policy, logon rules, audit settings, gateway or remote call rules) and compare them with an approved baseline after every change and upgrade (CM-6). See the Change Management Security guide.
Keys, data protection and non-production copies
- Encryption keys: know where database and application encryption keys live, who can access them and how they are rotated, following NIST SP 800-57 practice. For self-hosted systems, keep keys outside the database they protect.
- Payment file integrity: protect bank files from generation to transfer: restrict the output directory, sign or hash files where the bank channel supports it, and use a dedicated, monitored transfer identity. Changes to supplier and employee bank details should require independent approval and raise an alert.
- Database layer: direct database access bypasses application authorisation and logging. Restrict it to named database administrators through the PAM tool and log it separately.
- System copies: production copies used for testing and training carry payroll, bank and personal data. Mask or scramble sensitive fields after each copy, reset copied interface credentials and point copied interfaces at test endpoints only. See Production Data in Non-Production.
Logging and detection
OWASP's Logging Cheat Sheet lists user administration, privilege changes, use of administrative and break-glass accounts, access to sensitive data and data export as higher-risk events to log. Send ERP security audit logs to a SIEM that ERP administrators cannot change (AU-9), and confirm the platform's own security audit log is switched on, because on many platforms it is configured separately from system logging.
| Event | Why it matters |
|---|---|
| Assignment of all-rights or technical admin roles | The fastest route around business controls |
| Logon by default, emergency or interface accounts in dialog mode | Non-personal accounts used by a person |
| Security audit log or parameter changes | Possible attempt to remove evidence |
| Production opened for direct change, or transports imported outside windows | Unreviewed code or configuration |
| Direct table maintenance or debugging with change in production | Data altered with no business document |
| Supplier or employee bank detail changes | Classic payment redirection step |
| Large data extracts or unusual report volumes | Payroll or customer data leaving the system |
| Remote connection definitions created or changed | New trust paths between systems |
Correlate with finance: a payment run that includes a supplier whose bank details changed in the same week should be visible to both security and accounts payable.
Lifecycle of the platform
- Certify the platform's own access: review technical administrator, interface, batch and emergency accounts at least quarterly (our recommendation), with the reviewer outside the ERP administration team (AC-6(7)).
- Patching: apply vendor security updates on a defined cadence tied to the system's criticality. For cloud ERP, the provider patches the service and the customer keeps add-ons, connectors, on-premises components and configuration current: a shared responsibility (SA-9).
- Backup and recovery: back up the database, configuration and transport history, protect backups as sensitive financial data and test restores. Plan how interfaces and payment runs are paused safely during an incident.
- Retiring interfaces and systems: when an interface or legacy system is retired, lock its account, delete stored credentials and remove remote connection definitions in both directions.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Technical admin accounts | AC-6(5) Privileged Accounts, IA-2(1) Multi-factor Authentication to Privileged Accounts | PR.AA-05, PR.AA-03 | 5.4, 6.5 |
| Separation of duties | AC-5 Separation of Duties | PR.AA-05 | 6.8 |
| Interface and batch accounts | AC-2 Account Management, IA-5 Authenticator Management | PR.AA-01 | 5.5 |
| Transport and configuration | CM-3 Configuration Change Control, CM-6 Configuration Settings | PR.PS-01 | 4.1 |
| Audit logging | AU-9 Protection of Audit Information, AC-6(9) Log Use of Privileged Functions | PR.PS-04, DE.CM-03 | 8.2 |
| Provider responsibilities | SA-9 External System Services | GV.SC-07 | 15.4 |
Common failure patterns
- All-rights profile on a named user: granted during go-live or an upgrade and never removed.
- One interface account for everything: shared across integrations with broad authorisations and a password set years ago.
- Default accounts reactivated by a system copy: a refreshed test system brings back accounts and passwords from an old production state.
- Stored privileged logons between environments: a remote connection from development into production that runs as an administrator.
- Security audit log switched off or not forwarded: the platform records changes only in places its administrators can edit.
- Business SoD reviewed, technical roles excluded: access reviews cover finance users but not the platform team, batch owners or interface accounts.
Practitioner checklist
- Split technical administration into separate roles and keep all-rights access to an emergency process.
- Use dedicated admin accounts with phishing-resistant MFA, from privileged access workstations.
- Change and lock default accounts, and recheck after every upgrade and system copy.
- Give each interface and batch job its own non-interactive account, scoped and inventoried.
- Move interface authentication to certificates or short-lived tokens, or vault and rotate passwords.
- Remove stored privileged logons from lower environments into production.
- Separate develop, approve and import for transports; keep production closed to direct change.
- Protect bank files and alert on supplier and employee bank detail changes.
- Switch on the security audit log and forward it to a SIEM the ERP team cannot change.
- Certify technical, interface, batch and emergency accounts from outside the ERP team.
Standards and references
- NCSC: Secure system administration, risk manage administration using tiers
- NCSC: Secure system administration, use privileged access management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- OWASP: Logging Cheat Sheet
- OWASP: API Security Top 10 2023
- CIS: Controls v8.1 Assessment Specification, Control 4, Safeguard 4.1 Establish and Maintain a Secure Configuration Process
- CIS: Controls v8.1 Assessment Specification, Control 5 Account Management
- CIS: Controls v8.1 Assessment Specification, Control 6 Access Control Management
- CIS: Controls v8.1 Assessment Specification, Control 8 Audit Log Management
- CIS: Controls v8.1 Assessment Specification, Control 15, Safeguard 15.4 Ensure Service Provider Contracts Include Security Requirements
- MITRE ATT&CK: T1078 Valid Accounts
Related NHI Mgmt Group resources: Securing the PAM Vault Itself · Securing the identity governance and administration (IGA) platform itself · Segregation of Duties Guide · Service Account Security Guide