SAP security needs preemptive defense beyond patching and segmentation

At a glance

What this is: The article argues that SAP security must move beyond patching and segmentation toward preemptive deception with decoys and honeytokens to catch attackers earlier.

Why it matters: That matters because SAP environments blend high-value data, complex patching, and limited detection coverage, so IAM and security teams need controls that expose abuse paths before production systems are reached.

By the numbers:

• With an average of 10 to 15 patches and security notes published each month, security teams struggle to ensure systems are properly patched.
• CVE-2025-31324 had a CVSS score of 10.0, the highest possible severity ranking.

👉 Read Acalvio's blog on preemptive defense for SAP security

Context

SAP security is no longer just a patching problem. When business-critical systems hold logistics, inventory, and financial data, the real issue is how quickly attackers can move from initial access to sensitive data exposure, especially when identity pathways and trusted connections bypass perimeter controls.

The article’s core claim is that prevention alone is not enough for SAP environments. Patching and segmentation still matter, but they do not reliably stop phishing-led footholds, identity abuse, or SAP-specific exploits from reaching high-value data stores.

For teams running SAP in production, the governance question is whether detection and deception are placed close enough to attacker pathways to surface abuse before operational disruption or exfiltration occurs.

Key questions

Q: How should security teams detect SAP compromise before data exfiltration starts?

A: Use decoys, honeytokens, and identity-aware monitoring to trigger on attacker interaction rather than waiting for log-based confirmation. In SAP environments, that means placing believable traps along likely paths into service accounts, public-facing portals, and data stores. The goal is to catch enumeration or misuse early enough to isolate the session before sensitive data is reached.

Q: Why do SAP service accounts create a governance gap for defenders?

A: SAP service accounts can become the shortest path from initial foothold to sensitive business data if they are over-trusted, poorly inventoried, or not monitored as identities. That makes them a governance issue, not just an operations detail. Teams need to know which accounts can pivot into databases, integrations, or production workflows.

Q: What breaks when EDR cannot be fully deployed on SAP systems?

A: When EDR coverage is limited on SAP hosts, defenders lose a major endpoint telemetry source and must rely on logs that may be incomplete or proprietary. That creates blind spots for stealthy exploitation, web shell activity, and lateral movement. Deception controls can partially compensate by creating signals where telemetry is weak.

Q: Who is accountable when a SAP deception control triggers an incident response?

A: The response chain should be owned jointly by SAP operations, SOC, and identity teams because the trigger may expose both technical compromise and identity misuse. Governance should define who isolates systems, who validates the identity involved, and who preserves evidence. Clear ownership matters because deception only helps if containment is immediate.

Technical breakdown

Why SAP NetWeaver exposure becomes an entry point

SAP NetWeaver and similar public-facing components create an exposed control plane where attackers can probe for known CVEs, weak interfaces, and internet-accessible paths into enterprise data. The article highlights exploits against /developmentserver/metadatauploader and the deployment of web shells such as helper.jsp and cache.jsp, which turns a simple HTTP-facing weakness into a persistence foothold. In practice, the mechanism is not just vulnerability exploitation. It is the combination of exposed service surfaces, predictable product architecture, and a large installed base that lets attackers tailor initial access to SAP environments.

Practical implication: reduce exposed SAP surfaces and treat public-facing SAP endpoints as high-risk entry points for active monitoring and deception.

How attacker identity abuse bypasses segmentation

Once inside the enterprise, attackers enumerate Active Directory for SAP service accounts because identity often provides a more reliable path than network movement alone. The article shows how a discovered service account can become the pivot into the SAP database, especially when trusted connections and standing access reduce friction. Segmentation may still isolate networks, but it does not automatically stop misuse of legitimate identity pathways. That is why identity must be treated as part of the attack surface, not just a directory issue.

Practical implication: map SAP service accounts, trusted relationships, and identity pathways with the same rigor used for network segmentation.

Why honeytokens and decoys change the detection model

Cyber deception works by creating believable assets that are safe to touch but costly for the attacker to use. Honeytokens, such as fabricated SAP service accounts in Active Directory, and decoys, such as realistic SAP database targets, are designed to trigger on first interaction rather than after damage is visible. This shifts detection from log review to attacker intent exposure. It is especially useful where EDR coverage is limited, application logs are incomplete, or product-specific telemetry cannot be relied on to catch stealthy activity.

Practical implication: place decoys and honeytokens along known attacker paths so suspicious use triggers immediate containment signals.

Threat narrative

Attacker objective: The attacker wants to reach SAP-held business data and exfiltrate it while preserving access long enough to continue offensive activity.

1. Entry occurs when the attacker gains an initial foothold, such as through phishing, or probes a public-facing SAP surface for exploitable exposure.
2. Escalation follows when the attacker enumerates SAP-related identities, identifies a service account, and attempts to use it as a path toward the database.
3. Impact occurs when the attacker reaches sensitive SAP data, with the same path also supporting persistence through web shells and operational disruption.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SAP security fails when defenders assume patching speed is the main control variable. The article shows that SAP environments carry a high patch burden, yet attackers still find room to exploit exposed services, identity pathways, and product-specific weaknesses. That means the practical security problem is not only whether a patch exists, but whether defenders can detect and deflect abuse before production impact. Practitioners should treat preemptive defense as a parallel control plane, not a replacement for patching.

Identity is the bypass path in SAP environments, not just an access mechanism. Once an attacker can enumerate service accounts or leverage trusted connections, segmentation alone stops being decisive. This is a classic NHI governance problem because the account, not the host, becomes the pivot into data stores and business processes. Teams should re-evaluate whether SAP service identities are mapped, monitored, and instrumented as attack surfaces.

Preemptive deception creates an identity blast radius that is safer than waiting for a real one. Honeytokens and decoys move the defender’s first signal closer to attacker intent, which is especially valuable where EDR is impractical or logs are incomplete. The field implication is that visibility and containment now depend on controlled false assets as much as on prevention controls. Practitioners should fold deception into SAP governance where direct telemetry is weak.

AI-assisted attack development is compressing the time between discovery and exploit adaptation. The article points to GenAI being used to turn prompts into offensive tooling, which shortens the window in which patch-only strategies can keep pace. That does not make SAP security an AI problem alone. It makes it a governance problem where exposure management, identity control, and preemptive detection must operate as one security loop.

Cyber deception belongs in the same conversation as identity lifecycle governance. If attacker paths routinely involve service accounts, honeytokens, and trusted identities, then offboarding, review, and account validation are not administrative chores. They are active controls that determine whether deceptive assets remain believable and whether real identities can still be misused. Practitioners should align SAP deception with lifecycle discipline across human and non-human identities.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a broader control lens, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding discipline that also applies to deceptive identities.

What this signals

Identity-aware deception is becoming a practical control pattern for environments where telemetry is unreliable. SAP is a good example of a broader shift: defenders need signals from the identity layer because endpoint tooling and application logs are not always enough. With 19% of organisations already giving AI systems dramatically more access than human employees, according to the 2026 Infrastructure Identity Survey, access governance is clearly being stretched beyond traditional assumptions.

Identity blast radius: this is the control problem SAP defenders should now use to think about decoys, honeytokens, and trusted service accounts. If a false identity can trigger reliable containment faster than production telemetry, the programme has moved from passive monitoring to active exposure management. That same logic aligns with the broader lifecycle discipline in the NHI Lifecycle Management Guide.

Practitioners should expect attackers to keep moving toward identity-led paths whenever patching is slow and segmentation is predictable. That makes service account inventory, deceptive identity placement, and response ownership part of the operating model, not optional hardening.

For practitioners

• Instrument SAP service accounts as attack-surface identities Inventory SAP-related service accounts, privileged connectors, and trusted pathways, then monitor them for unexpected use patterns and lookup activity. Treat these identities as high-value assets rather than background technical objects.
• Deploy decoys on internet-facing SAP surfaces Place realistic SAP NetWeaver decoys on exposed entry points that attackers are likely to probe, so scanning and exploitation attempts generate early alerts before production systems are touched.
• Plant honeytokens in identity stores and endpoints Create convincing but controlled SAP service accounts in Active Directory and deceptive credentials on endpoints, then wire any usage attempt into SIEM and SOAR containment workflows.
• Run containment on deception triggers Define response playbooks that isolate the endpoint, suspend suspicious sessions, and preserve evidence as soon as a honeytoken or decoy is accessed, rather than waiting for broader incident confirmation.

Key takeaways

• SAP is exposed not just to vulnerability exploitation but to identity-led abuse that can bypass segmentation and reach business-critical data.
• The article links real-world SAP attacks to production outages, data exfiltration, and stealthy persistence, showing that the impact can be operational as well as informational.
• Preemptive deception changes the game by surfacing attacker intent early enough to isolate systems before compromise becomes a business event.

Key terms

• Cyber Deception: Cyber deception uses decoys, honeytokens, and believable false assets to make attacker interaction visible earlier in the attack chain. In identity-heavy environments, it turns misuse of accounts or services into a high-fidelity alert before real systems are touched.
• Honeytoken: A honeytoken is a controlled fake credential, account, or data object designed to look valuable to an attacker. When used, it signals suspicious activity immediately and can be wired into response workflows to isolate the source and preserve evidence.
• SAP Service Account: An SAP service account is a non-human identity used by systems, integrations, or background processes to access SAP resources. These accounts are often high-impact because they can bridge applications, databases, and trusted pathways if they are not tightly governed.
• Preemptive Security: Preemptive security is a defence model that aims to detect and deflect attackers before they reach high-value assets. For SAP, that means using traps, identity signals, and rapid containment to shorten the time between initial access and response.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Acalvio: Beyond patching, why preemptive defense is essential to secure SAP. Read the original.