ERP platform integration security guide: scoping the machine identities that move money and data

An ERP platform's integrations carry real financial authority: the account a bank interface, procurement feed or AI agent uses can create suppliers, change bank details or post payments, often with fewer controls than any human user. ERP systems connect to an identity provider for sign-in, an identity governance platform for role assignment, a SIEM for audit logs, an ITSM platform for change and emergency access, middleware and APIs for business data, banks for payments, and data platforms for reporting. Each connection runs under a technical account, certificate or token. This guide covers how to choose between technical and propagated identities, scope each integration, apply segregation of duties to machines, and monitor them. It is vendor-neutral and written for ERP security and Basis teams, integration architects, identity engineers and auditors. Securing the platform core is covered in Securing the enterprise resource planning (ERP) platform itself; this page goes deeper on the connections.

Key takeaways

• Segregation of duties applies to machines. An interface account that can both create a supplier and release a payment breaks the same rule a human with both rights would, and it is rarely in the SoD ruleset.
• Prefer propagated user identity for user-driven calls. When a person acts through a front end, pass their identity to the ERP so their own authorisations apply, instead of a shared technical account with the union of everyone's rights.
• The governance connector is the most powerful integration. The account that provisions roles into the ERP can make anyone an administrator; it deserves privileged access controls.
• Trusted system links are credentials. Stored connections between systems, especially from development or test into production, give everyone with access to the source system a path into the target.
• Bulk read is a breach, not a report. Data extraction accounts with wide table access turn one stolen secret into a full copy of finance, HR and customer data.

The ERP integration map

Technical account or propagated user identity

The first design choice for every integration is whose identity the ERP sees.

Propagation keeps audit trails accurate and lets user-level SoD rules apply. Technical accounts are unavoidable for unattended processes, but each one should be documented with the business process it serves, the authorisations it holds and the reason propagation is not possible. See the OAuth Token Exchange and Delegation Guide.

Identity provider and governance connections

• SSO mapping: map assertions to ERP users on an immutable identifier (employee number or directory object ID), not on an email address that can be reassigned. Require signed assertions and track the signing certificate's expiry. See the Identity provider (IdP) and SSO platform integration security guide.
• Keep administrators on SSO: where local password logon must remain for emergency use, limit it to break-glass accounts that are vaulted and alerted on. See the Break-Glass Account Guide.
• Governance connector scope: the provisioning account needs to create and lock users and assign roles in scope. It should not be able to change authorisation profiles or roles themselves, change its own account, or administer system settings. Protect its credential as a privileged secret (NIST SP 800-53 AC-6 and IA-5).
• Reconciliation: compare ERP role assignments against the governance platform daily. A role assigned directly in the ERP, bypassing the connector, is either an emergency change or an attacker. See the Segregation of Duties Guide.

SIEM and audit log extraction

• Enable the logs first: ERP security audit logging is often partly off by default or filtered. Confirm logon events, failed authorisations, user and role changes, changes to critical tables (supplier bank details, payment terms) and remote function or API calls by technical accounts are recorded (AU-12).
• Read-only collector: the SIEM connector needs read access to audit logs, not to business tables. A collector account that can read every table is a data extraction channel.
• Detect technical accounts acting like people: interactive logon, user-interface transactions or logon from a new host by an interface account are high-signal alerts. See the SIEM integration security guide.

Change management, ITSM and emergency access

• Ticket links, not ticket authority: ITSM integrations that create change records or link transports to tickets are useful. The ERP side should check that a ticket is approved before it imports a transport; the integration token must not be able to set the approval itself.
• Emergency (firefighter) access: where emergency access is requested through the ITSM, the ERP or governance tool should grant time-bound access, log all activity in that session and send the log to a reviewer. See the ITSM platform integration security guide.
• Keep secrets out of tickets: initial passwords and interface credentials pasted into tickets outlive the change by years.

APIs, middleware and bank connectivity

APIs and middleware

• Object and function level checks: ERP web services must check that the caller may act on this company code, this supplier and this document, and may call this function at all. These are OWASP API Security Top 10 2023 risks API1 Broken Object Level Authorization and API5 Broken Function Level Authorization.
• Sensitive business flows: supplier creation, bank detail change and payment release are flows an attacker wants to automate (OWASP API6 Unrestricted Access to Sensitive Business Flows). Rate-limit them and require a second control for changes to bank details.
• Token hygiene: use OAuth client credentials with scopes per integration, audience-restricted and short-lived tokens, and asymmetric client authentication, as RFC 9700 recommends. Never use the password grant, which RFC 9700 says must not be used. See the Machine-to-Machine OAuth (Client Credentials) Guide.
• One account per connected system: the middleware platform should hold a separate ERP credential for each connected system and direction, so one compromised flow does not post into every company code.
• API inventory: ERP platforms ship with many services that can be activated. Keep a list of active services with an owner, and deactivate what is unused (OWASP API9 Improper Inventory Management).

Bank connectivity

Payment files are the highest-value output of an ERP. Sign payment files with keys held in a protected key store, not in a file on the interface server. Make the account that creates the payment file different from the one that approves the payment run, check file totals between ERP and bank channel, and alert on any change to the bank channel's endpoint, certificate or account. Supplier bank detail changes followed by a payment to that supplier within days are a classic fraud pattern. See the Payment Fraud Guide and the EDI and B2B Integration Security Guide.

Data extraction, RPA and AI agents

• Extraction accounts: replication and reporting accounts should read named views, not raw tables, with personal data masked where reporting does not need it. Alert on volumes well above the account's baseline (T1213 Data from Information Repositories). See the ETL and ELT Pipeline Security Guide.
• RPA bots: one identity per bot and process, never a shared super-user, credentials in a vault the bot retrieves at run time. See the RPA and Bot Identity Security Guide.
• AI agents: agents that read ERP data or draft postings need their own identities, scopes no wider than an interface account doing the same job, and human approval before any posting, supplier change or payment. Prompt-injected instructions in invoices or supplier emails are a realistic path to a fraudulent change. See the Agent Identity and Access Guide.

How to implement

1. Inventory technical identities: list every non-dialog account, stored remote connection, API client, certificate and bank channel credential. For each record the connected system, business process, owner, authentication type, credential age and last use.
2. Turn on logging and a baseline: enable audit logging for technical accounts and forward it to the SIEM before changing anything. Two to four weeks of data, including a month-end close, shows what each account really does.
3. Add machines to the SoD ruleset: run your SoD analysis over technical accounts as well as users. Fix conflicts by splitting accounts (one for supplier master data, one for payments) rather than by mitigation memos.
4. Remove dangerous trust: delete stored privileged logons and trust relationships from development and test into production first; they are the cheapest high-value fix.
5. Re-scope in a test system: derive least-privilege authorisations from the baseline, build them in a test or quality system, and run the integration's full regression including year-end and correction scenarios. Keep the old role assignable for rollback for one business cycle, then remove it.
6. Move to stronger authentication: replace passwords with certificates or OAuth clients with asymmetric authentication where the platform supports it, and vault what remains with scheduled rotation.
7. Review quarterly: technical accounts get an owner attestation each quarter, with automatic lock after 90 days without use (NHI Mgmt Group recommendation).

Decision guidance

• Technical account versus propagation: if a named person triggers the action and the ERP must enforce their rights, propagate. If no person is involved, use a technical account and scope it to the process.
• Middleware versus point-to-point: middleware centralises credentials, which concentrates risk but makes rotation and monitoring easier. Point-to-point spreads credentials across many systems. Large estates usually gain from central control, provided the middleware is treated as a privileged tier.
• Cloud ERP: the provider runs the platform, but you still own the communication users, API clients, trust settings and role design. Ask the provider which integration events appear in your audit logs.
• Small organisations: focus on four controls: SSO for administrators, one account per integration, no stored trust from non-production into production, and dual control on bank detail changes and payment runs.
• Large organisations: put technical accounts under identity governance with owners and attestation, include them in SoD analysis, and run a dedicated detection use case set for interface accounts.

Detection and measurement

• Interactive or user-interface logon by any technical account.
• A technical account used from a host other than its registered integration server.
• Role or authorisation changes to technical accounts outside the governance connector.
• Changes to supplier bank details by an interface account, especially followed by a payment to that supplier.
• New API clients, new trusted system connections or changed bank channel endpoints.
• Read volumes by extraction accounts well above baseline.

Framework mapping

Common failure patterns

• Interface accounts outside SoD: the ruleset covers users only, so a middleware account holds supplier maintenance and payment release together for years.
• Development trusted into production: a stored connection with a privileged production logon sits in a development system that dozens of contractors can use.
• Internet-facing ERP components left unpatched: attackers who reach the application through an exposed module get the same access as its technical accounts. The Oracle E-Business Suite exploitation in 2025 (CVE-2025-61882, added to the CISA KEV catalogue on 6 October 2025) ended in data theft and extortion across many customers.
• Connected-app tokens nobody reviews: an integration's OAuth token is stolen from the third party and used to read business data at scale, as in the Salesloft Drift breach.
• Service account credentials in personal places: an integration credential saved in a personal browser profile or notes file is lost with the endpoint, as the Okta support system breach showed.
• Governance connector as super-user: the provisioning account holds full administration because "it needs to manage users", so stealing its password gives complete control of the ERP.

Practitioner checklist

• Inventory every technical account, API client, stored connection and bank channel credential with an owner.
• Decide technical account or propagated identity for each integration and document why.
• Run SoD analysis over technical accounts and split conflicting ones.
• Remove stored privileged logons and trust from non-production into production.
• Limit the governance connector to user and role assignment in scope, with no self-administration.
• Give the SIEM collector read access to audit logs only and alert on interactive use of technical accounts.
• Use scoped OAuth clients or certificates for APIs and never the password grant.
• Sign payment files with protected keys and require dual control on bank detail changes.
• Give each RPA bot and AI agent its own identity with human approval for financial actions.
• Attest technical accounts quarterly and lock those unused for 90 days (NHI Mgmt Group recommendation).

Standards and references

• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• IETF: RFC 9700, Best Current Practice for OAuth 2.0 Security
• OWASP: API Security Top 10 2023
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: Data from Information Repositories

Related NHI Mgmt Group resources: Securing the enterprise resource planning (ERP) platform itself · SAP Identity and Access Security Guide · Service Account Security Guide · If your ERP platform is compromised · Managed file transfer (MFT) integration security guide