Who is accountable when a public SAP exploit leads to lateral movement into identity systems?

Why This Matters for Security Teams

When a public SAP exploit is used to move laterally into identity systems, the issue is not just an application patch backlog. It becomes a trust-chain failure across SAP owners, platform operations, and identity defenders. That is why NHI governance matters: a compromised service account, API key, or integration token often becomes the bridge from an exposed business application into privileged directories, SSO, and admin tooling. NHI Mgmt Group notes that Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

The accountable party is usually not a single team. Security leaders should expect shared responsibility across application ownership, infrastructure hardening, IAM, and incident recovery, with clear handoffs before an exploit is public. The operating model also needs to reflect the blast radius of long-lived secrets and over-scoped trust paths, which align poorly with the least-privilege expectations in the NIST Cybersecurity Framework 2.0. In practice, many security teams encounter lateral movement only after identity systems have already been touched, rather than through intentional trust-chain review.

How It Works in Practice

Accountability should be assigned by control domain, not by who discovered the CVE first. SAP platform owners are responsible for patching, exposure reduction, and hardening. Application owners are responsible for the service accounts, embedded credentials, and interfaces their workloads depend on. Identity teams are responsible for the downstream privileges, authentication paths, and recovery steps that determine whether an attacker can turn one foothold into broad access. Current guidance suggests treating these as one operational chain rather than separate tickets.

A practical response model usually includes:

• Inventory SAP-connected service identities, API keys, and integration accounts.
• Identify which identities can reach identity providers, directory services, PAM, or admin consoles.
• Rotate or revoke secrets that can be used from exposed SAP surfaces.
• Check whether privileged paths are protected by Zero Trust and session controls.
• Validate recovery steps so compromised credentials cannot be restored from unsafe backups or stale automation.

This is where NHI visibility becomes decisive. Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs, which explains why organisations often cannot prove which downstream identities were reachable from the exploited system. Mature teams pair that inventory with identity telemetry and the access-principles in NIST CSF 2.0 so incident response is based on actual trust paths, not assumptions. These controls tend to break down when SAP integrations rely on shared technical accounts with no owner, no TTL, and no revocation playbook.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster patching against cleaner ownership and stronger recovery discipline. That tradeoff matters because the real failure mode is not always the public exploit itself. It can also be a legacy connector, batch job, or middleware account that was never mapped to a business owner and was quietly trusted by identity systems.

Best practice is evolving, but current guidance suggests a few edge-case rules. If SAP is externally reachable, exposure management must be treated as an identity issue too, because an internet-facing foothold can become a credential-theft event. If the affected environment uses shared service accounts, accountability should extend to whoever approves those exceptions, not just the operations team. If privileged access is brokered through PAM, then the question becomes whether the attacker can bypass or abuse those controls through recovery workflows.

For broader NHI risk context, NHIMG’s 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce the same lesson: ownership gaps and secret sprawl turn one application incident into a multi-system identity event. There is no universal standard for assigning blame in this scenario, but there is a consistent operational standard for assigning responsibility for the controls that failed.

Related resources from NHI Mgmt Group

• Why do privileged SAP middleware services increase lateral movement risk?
• Who is accountable when credential compromise leads to lateral movement?
• Why do machine identities increase lateral movement risk in cloud and SaaS environments?
• Who is accountable when phishing leads to customer fraud and account takeover?