Last year, nation-state groups including UNC5221 and UNC5174 exploited CVE-2025-31324, a critical zero-day in SAP NetWeaver, to gain footholds inside hundreds of organizations, combining mass exploitation with abuse of webshells they had already planted, according to Onapsis's 2025 report on attacks against SAP, Salesforce, and Oracle. Separately, researchers tracking the group Earth Lamia documented the same NetWeaver flaw being exploited by attackers who used built-in Windows tooling to blend into normal system activity once inside. These were not opportunistic script kiddies. They were operators who had learned to speak SAP fluently, at the network layer and inside the application itself.
That fluency is the real story. A network-layer exploit gave these attackers a technical foothold inside the application. From there, the path to a manipulated business process (a fraudulent payment run, altered master data) sits only one step further. Three layers, one attack chain: network, application, business process. Each layer already produces signals. None of those signals reach the same team, let alone the same decision.
That gap is the problem worth solving.
Three Domains, One Blind Spot
The SAP case is one instance of a pattern that shows up in at least three places.
- Network to application to business process. A network-layer exploit becomes a technical foothold first. The business-process manipulation that follows, sometimes weeks later, is only catchable if the two earlier stages were already correlated.
- Identity to real-time communication to transaction. A convincing deepfake on a video call, a legitimate-looking corporate login, and a large, time-pressured wire transfer together form a fraud pattern spanning three platforms at once. Each system in isolation sees nothing wrong.
- Access to intellectual property and source code. A contractor persuaded or compromised into handing over proprietary code triggers no financial signal at all. The only trace is an unusual constellation of otherwise ordinary actions.
None of these can be caught by identity signals, network signals, or transaction monitoring alone. The second pattern, identity fused with a real-time channel and a transaction, is territory my colleague Jonathan Care mapped from the finance side in his whitepaper on preventing million-dollar ERP fraud. What's new here is pulling the network and business-application layers into the same picture.
The Second Step Nobody Has Built
Step one is identity signal standardization, and it is largely solved. Google first proposed continuous, real-time session evaluation in 2019, and the OpenID Foundation's Risk Incident Sharing and Coordination (RISC) work runs on a similar timeline. For most of the years since, both lived as implementer's drafts: promising, but not yet fixed standards. That changed in September 2025, when the Shared Signals Framework (SSF), the Continuous Access Evaluation Profile (CAEP), and RISC were approved as OpenID Final Specifications, closed to further revision. CAEP tells relying systems when a session or device changes state; RISC tells them when an account itself is compromised or disabled. Identity can now be treated as continuously evaluated, not asserted once at login and trusted for the rest of the day.
Step two is missing: correlating those identity signals with the network, communication, and business-application signals that sit alongside them. This is what Continuous Controls Monitoring (CCM) does. CCM watches business applications like SAP for control violations and process anomalies in near real time, which makes it the natural third leg alongside identity signals (CAEP, RISC) and network and endpoint signals (extended detection and response, or XDR). Without CCM, correlation stops at the application's front door and never reaches the business process behind it.
What Actually Makes Correlation Hard
Identity mapping across domains looks like the missing piece, but mostly it is not. When an organization already maps accounts, devices, and roles to a single identity graph, a mature Identity Fabric, that mapping is solved. At that point it is an engineering problem. What remains genuinely difficult is narrower:
- Ephemeral, session-level binding. The Identity Fabric tells you which person owns which account. It does not tell you that a specific call, a specific network flow, and a specific transaction reference all belong to the same live event thirty seconds ago. That binding has to be built fresh, on top of the static graph.
- Confidence, not just events. CAEP and RISC deliver discrete, binary events. Deepfake detection and CCM-style anomaly scoring deliver probabilities that shift as models and attackers both adapt. No standard yet defines how to fuse the two.
- External counterparties. The CFO on the call is a known identity. The counterparty triggering the fraud attempt often is not, and no internal governance extends automatically to accounts you never provisioned.
Response has to change, too. Correlation across domains is not a block-or-allow decision. A flagged transfer should trigger step-up verification or a delay for human review, not an automatic hold a CFO will simply route around next time. Differentiated response, matched to severity and reversibility, is what makes correlation usable in practice.
Three Gaps, and How to Close Them
The first gap is inventory. Signal availability is rarely the problem; what almost nobody has done is map which systems produce what, or where those signals currently dead-end, so start there before buying anything new. The second is identity resolution. A correlation program built on a weak Identity Fabric inherits every gap in that fabric, which makes identity resolution a precondition for everything downstream. Coverage is the third gap, and business-application signals are the layer most often left out, which is why CCM has to be a deliberate part of the correlation stack.
Once those gaps are closed, two decisions turn the capability into a program: design response tiers (step-up, containment, escalation) before a signal ever fires, not after; and start with one high-value scenario, such as executive-impersonation fraud on large transactions, rather than attempting to correlate everything at once.
A Governance Problem Wearing a Technology Costume
The main obstacle is not technical. SOC, IAM, DLP, fraud teams, and CCM each sit in different reporting lines with different budgets and KPIs, and in most enterprises that is also a Target Operating Model problem: the org chart was never drawn with cross-domain fraud correlation in mind. Building the correlation layer is the easier half of this change; getting those silos to agree on a shared signal bus and response playbook is the harder one.
That is why this cannot be delegated downward and left there. Business fraud is no longer confined to the systems and units that historically owned it, and the mandate to fix that has to come from the top: from the CEO to the CFO, and jointly to the CIO and CISO. A heterogeneous application environment that no single signal vendor covers end to end doesn't rule out a solution; it just means the solution must be a joint effort across the stages, disciplines, and teams described above, not a platform purchase.
Without that mandate, the correlation layer becomes another dashboard nobody owns, checked after an incident rather than acted on before one.
The Bottom Line
The standards that deliver real-time identity signals matured recently. The vendors that correlate signals within a single domain are mature too. XDR, identity threat detection and response (ITDR), CCM, and transaction monitoring all work well inside their own lane. What does not yet exist is a vendor, or a program, that correlates across all of them for business fraud specifically. I do not think that gap survives much longer. Organizations that start building the correlation capability, and the governance mandate behind it, now will be the ones that catch the next SAP-fluent attacker before the technical compromise becomes a business one.
