By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: PathlockPublished August 25, 2026

TL;DR: ERP and business application environments are facing repeated CVSS 9.9 exposures, direct exploitation of Oracle EBS and PeopleSoft, and attack paths that increasingly rely on valid access rather than classic vulnerability chaining, according to Pathlock’s review of H1 2026. The pattern shows that ERP defence now depends on continuous exposure management, application-layer monitoring, and tighter governance of both human and non-human identities.


At a glance

What this is: This is Pathlock’s analysis of why ERP and business applications became more attractive cyber targets in H1 2026, with repeated critical vulnerabilities and direct attacks on Oracle and Salesforce environments.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern not just authentication into ERP systems, but what legitimate identities and integrations can do inside them.

By the numbers:

👉 Read Pathlock's analysis of ERP vulnerabilities, Oracle exploitation, and business application risk


Context

ERP and critical business applications sit at the intersection of finance, HR, procurement, and supply-chain operations, which makes them high-value targets when attackers want durable business impact. In 2026, the risk was not limited to one vendor or one flaw class. It spanned repeated severe vulnerabilities, automated exploitation of enterprise application environments, and trusted access paths that bypassed traditional perimeter assumptions. For identity security teams, the important point is that authentication into an ERP system is not the same as authorization to perform sensitive business actions inside it.

The primary governance gap is not just patch latency. It is the lack of continuous visibility into what human and non-human identities, integrations, service accounts, and tokens can actually do once they reach business applications. That is where application-layer controls, least privilege, and transaction-level monitoring become relevant to IAM, PAM, and NHI programmes. The threat pattern described here is increasingly typical for large enterprise environments, not an edge case.


Key questions

Q: What breaks when ERP access is treated as safe after login?

A: The control model breaks because authentication does not prove that a payment, entitlement change, or data export is legitimate. In ERP environments, attackers can use valid credentials, tokens, or integrations to perform harmful actions that appear normal at the session layer. Security teams need to govern post-login business actions, not just identity proof at sign-in.

Q: Why do service accounts and trusted integrations increase ERP risk?

A: They increase risk because they create durable paths into business applications that often receive less review than human logins. If their permissions are broad, their tokens are long-lived, or their purpose is not revalidated, attackers can use them to move through ERP processes with legitimate-looking access. These are governed privileges, not background plumbing.

Q: How can teams tell whether ERP access controls are actually working?

A: Measure whether high-privilege accounts are forced through the IdP, whether sensitive actions are logged at a granular level, and whether masking prevents unnecessary data exposure. If investigators cannot reconstruct who viewed, queried, or exported records, the control stack is not delivering usable assurance. Telemetry depth is a governance signal, not just a logging metric.

Q: Which control matters most after an ERP breach or exploit?

A: Containment depends on limiting what the compromised identity or integration can do next. That means narrowing privileges, isolating sensitive functions, validating trusted connections, and checking whether the attacker used application logic rather than host-level malware. In practice, the right response is to protect the business process before the attacker completes the next transaction.


Technical breakdown

Why ERP vulnerabilities keep recurring across core business platforms

Large ERP stacks combine custom code, multiple integration layers, and long-lived business logic that cannot be replaced quickly. That creates a broad attack surface where even one SQL injection, code injection, or authentication flaw can affect financial records, master data, or administrative workflows. Patch cycles help, but they do not remove the underlying complexity that keeps producing high-severity flaws across different modules and deployment models. When the same ecosystem repeatedly discloses near-maximum-severity issues, the technical lesson is that patching alone is not a full control plane.

Practical implication: treat ERP exposure as continuous attack-surface management, not quarterly maintenance.

How legitimate access becomes the real attack path in business applications

Attackers often prefer valid access because it blends into expected activity. Stolen credentials, compromised tokens, trusted third-party integrations, and over-permissive guest roles can all pass authentication checks while still enabling sensitive actions. In practice, this means the control boundary has shifted from login to transaction. The security question is not only who authenticated, but what the identity, app connection, or token was allowed to change, query, export, or approve inside the application.

Practical implication: monitor business transactions and privilege use, not only successful logins.

Why application-layer monitoring matters more when attackers look like users

Once attackers enter ERP and SaaS environments with legitimate access, infrastructure logs may show nothing unusual. Identity telemetry may confirm a valid session, but it may not explain whether the user or workload altered payments, changed entitlements, or queried unusual data sets. Application-layer monitoring closes that gap by correlating action, object, and business context. For ERP security, that is the difference between knowing that an identity authenticated and knowing whether the activity was operationally normal.

Practical implication: feed ERP transaction context into detection and response workflows.


Threat narrative

Attacker objective: The attacker objective is to obtain scalable access to high-value business data and processes while avoiding obvious security alerts.

  1. Entry began with exploitation of internet-facing ERP vulnerabilities or with compromised legitimate access through tokens, credentials, or misconfigured guest profiles.
  2. Escalation occurred when attackers used automated tooling or trusted integrations to reach sensitive application functions and business records.
  3. Impact followed when the attackers accessed, changed, or exfiltrated financial and operational data while appearing to be normal users.

NHI Mgmt Group analysis

ERP security has become an identity problem as much as an application problem. The article shows that valid access, trusted integrations, and over-permissive accounts can be more dangerous than a headline vulnerability because they sit inside normal control assumptions. IAM and PAM teams need to extend governance from authentication into transaction authorisation and runtime monitoring. The practitioner conclusion is that application access must be evaluated by business action, not login success.

Standing trust in ERP integrations is a named governance failure, not a convenience feature. Once tokens, service accounts, or partner connections are allowed to persist without continuous review, attackers inherit the organisation’s own trust relationships. That is where NHI governance becomes directly relevant, because machine credentials and delegated access can outlive the business context that justified them. The practitioner conclusion is to treat every long-lived integration as a governed privilege, not a static technical dependency.

Continuous patching is necessary, but it does not compensate for weak usage controls. The SAP trend in the article shows repeated critical disclosures, but the Oracle and Salesforce incidents show that exploitation is not the only path to harm. This is the application security equivalent of blast-radius control: reduce the impact of inevitable exposure by constraining what identities can do after access is obtained. The practitioner conclusion is to pair remediation speed with post-authentication containment.

ERP attack industrialisation will reward defenders who can reason in business context. The PeopleSoft campaign demonstrates that attackers can automate discovery and exploitation across many environments, while still blending into legitimate workflows once inside. That makes business-process telemetry, not just network or host telemetry, central to detection. The practitioner conclusion is that SOC and IAM programmes need shared visibility into what changed, who changed it, and whether the change fits normal business operations.

Application-layer context is now a core part of enterprise control design. The article’s most important signal is that identity, access, and vulnerability data are each incomplete on their own. Application-layer context links them into an operational view that can explain intent, misuse, and impact. The practitioner conclusion is to align ERP security with NIST-CSF detection and response expectations, and to map privileged usage controls to NIST-800-53 AC-6 and IA-5 where identity governance is in scope.

What this signals

ERP security programmes should now assume that valid access can be the attacker’s preferred route, not a reassuring control state. That shifts the operational emphasis toward transaction monitoring, entitlement hygiene, and review of every service account, API token, and third-party connection that can reach financial or supply-chain workflows. The governance question is no longer whether an identity can authenticate, but whether it should be allowed to act in that business context at all.

Integration trust debt: this is the accumulation of long-lived tokens, partner links, and guest permissions that are accepted as stable until they become incident pathways. The practical response is to inventory and periodically re-authorise every privileged connection that touches ERP data, then anchor that review in controls such as NIST-CSF and NIST-800-53 AC-6. Where machine identities are involved, OWASP-NHI provides the right governance lens for lifecycle and access scope.

For IAM and NHI teams, the next planning step is to bring ERP transaction telemetry into the same operational view as identity and vulnerability data. That gives SOC and identity teams a shared language for suspicious behaviour, especially when attackers use legitimate sessions. The more critical the application, the more the programme needs business-process context rather than infrastructure-only evidence.


For practitioners

  • Inventory internet-facing ERP and business application exposure Continuously map externally reachable ERP components, application gateways, and admin interfaces, then prioritise systems with known internet exposure for accelerated review and compensating controls.
  • Correlate identity events with application transactions Send ERP transaction data, privilege changes, payment actions, and master-data updates into detection workflows so security teams can distinguish valid logins from suspicious business activity.
  • Review trusted integrations as governed privileges Reassess service accounts, API tokens, partner connections, and guest-user configurations on a fixed schedule, with explicit ownership, purpose, and offboarding criteria for each connection.
  • Shorten the blast radius of successful authentication Limit what a human or non-human identity can do after entry by applying least privilege, separating high-impact functions, and adding approval or monitoring to sensitive ERP actions.

Key takeaways

  • ERP attacks are now driven by both critical vulnerabilities and legitimate access paths, which means authentication alone is no longer a sufficient control boundary.
  • The evidence in H1 2026 points to repeatable, scalable targeting of enterprise applications, including campaigns that affected more than 100 organisations.
  • Teams that combine patch discipline with transaction-level monitoring, least privilege, and integration governance will reduce the blast radius of the next ERP compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03The article highlights standing access, integrations, and credential governance gaps across business apps.
MITRE ATT&CKTA0006 , Credential Access; TA0008 , Lateral MovementThe article describes credential use, trusted access, and movement inside business applications.
NIST CSF 2.0PR.AC-4Least-privilege and access governance are central to limiting ERP blast radius.
NIST SP 800-53 Rev 5AC-6Least privilege directly addresses over-broad ERP entitlements and service account scope.

Map ERP abuse paths to credential access and lateral movement, then tighten detection around trusted sessions.


Key terms

  • Business Process Telemetry: Business process telemetry is the record of what an identity or application actually did inside a business system, not just whether it logged in. It helps defenders distinguish routine ERP activity from suspicious transactions by linking user, object, timing, and outcome.
  • Integration Trust Debt: The accumulated risk created by long-lived, over-scoped, or forgotten SaaS connections that remain active after their original purpose fades. The debt grows when teams treat integration setup as a one-time task instead of a lifecycle-managed identity relationship.
  • Post-Authentication Control Gap: The loss of visibility and enforcement quality after an identity has successfully signed in or obtained access. This gap is especially dangerous in hybrid and machine identity environments, because entitlement often persists even when the original business need has changed.
  • Application-layer monitoring: Monitoring that records what users and accounts do inside the application, not just whether they reached the host or network. In ERP systems, it captures actions such as record views, queries, exports, and privilege changes, which is often the only way to spot legitimate-looking abuse at scale.

What's in the full article

Pathlock's full analysis covers the operational detail this post intentionally leaves for the source:

  • Patch-cycle-by-patch-cycle breakdown of SAP’s H1 2026 critical disclosures and affected components
  • Attack-path detail from Oracle EBS and PeopleSoft exploitation, including how automation changed the threat model
  • Application-layer monitoring and transaction-context examples that help distinguish legitimate from malicious ERP activity
  • Guidance on how to harden guest access, tokens, and trusted integrations without relying on authentication alone

👉 Pathlock's full analysis covers the SAP patch trend, Oracle attack patterns, and the monitoring controls teams need next.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect application access, privileged identity, and lifecycle control across enterprise systems.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org