Email Security Needs Its Periodic Table Moment
In January 2026, a mid-market financial services firm caught an active email attack operation at the credential-capture stage, before any payment was touched. Their legacy secure email gateway, running in parallel, generated no alert at all. The difference was not a better product. It was a different question. One system asked what technique the email used. The other asked what the attacker was trying to accomplish.
That distinction matters more right now than any feature comparison in the market.
The Label That Broke
For twenty-five years, the email security industry has classified attacks by technique. Phishing. Business email compromise. Malware delivery. Spam. These labels were reasonable when techniques were stable and BEC meant one specific thing: a spoofed CEO asking for a wire transfer. At enterprise scale, the problem compounds: thousands of daily emails classified by technique generate alert volumes that bury the signals that actually matter.
BEC is the clearest proof that technique-based classification has broken down.
In 2013, when the FBI’s IC3 started tracking it, BEC was a payloadless social engineering attack. No malware. No malicious link. One technique, one intent: get money to move to the wrong place.
Look at what that label covers now. Account takeover BEC, where the attacker compromises a real inbox through AITM phishing and waits days before inserting fraudulent payment instructions. Deepfake-augmented BEC, where a synthetic video call with a cloned CFO authorizes an eight-figure transfer. Supply chain pivot BEC, where one vendor compromise cascades into dozens of downstream targets. Thread hijacking. Gift card fraud, still over half of BEC by cash-out method as of December 2025. Payroll diversion. Real estate closing fraud.
These attacks share a label. They do not share a technique, a payload profile, or a detection approach. The FBI’s IC3 reports $55 billion in cumulative losses across “BEC.” That number tells you the category is expensive. It tells you nothing about which exposure is most dangerous to your organization.
AI made this worse. It collapsed the technique rotation cycle from quarters to days. In one Q4 2025 campaign, four structurally distinct variants of the same DocuSign impersonation attack deployed within 72 hours, each different enough to evade the signatures written for the last. Across all advanced attacks in that period, Jaccard similarity averaged 0.458, with 68% falling below 0.30, the threshold where pattern-matching detection loses statistical significance. The technique layer is fracturing. Any classification anchored there is fracturing with it.
The Structural Question
Before Dmitri Mendeleev published his periodic table in 1869, scientists organized elements by how they looked and what they did. Metals here, gases there. The categories were sensible, but they could not predict anything. Every new element forced a re-sorting.
Mendeleev changed the organizing principle. He grouped elements by atomic weight, and suddenly the table had gaps that told him what remained undiscovered and how those elements would behave. Observable properties could not do that.
The equivalent shift in email security: stop asking “what technique did the attacker use?” and start asking “what were they trying to accomplish?”
Intent does not rotate. The attacker who wanted to redirect a wire payment in 2015 wants exactly the same thing in 2026. Techniques changed completely. The objective did not move.
Three Intents, Thirty-Seven Subtypes
Organized by intent, the attack surface resolves into three categories based on the primary asset being targeted.
Economic intent attacks target money in motion, but that is not one problem. Payment redirection hijacks existing payments: vendor invoice fraud, payroll diversion. Fraudulent payment initiation creates obligations that did not exist: gift card schemes, callback BEC, advance fee fraud. Financial data theft extracts W-2s or banking details for downstream fraud. Those sub-intents require different controls. Detecting payment redirection means monitoring for banking detail changes in active invoice threads. Detecting fraudulent initiation means flagging novel payment requests from authority figures with urgency markers. Same economic intent, completely different detection logic. A CISO who knows their organization processes heavy vendor payments can focus on the first. The label “BEC” gives you none of that specificity.
Information intent attacks target data or access. This is where the connection to economic intent becomes critical. A credential harvesting email gets classified as phishing. Six days later, the compromised account redirects a vendor payment. That gets classified as BEC. The attacker executed one operation across two stages. Your detection stack generated two unrelated alerts. If it cannot connect them, the attacker’s operational logic is more coherent than your defenses.
Operational intent attacks target organizational continuity, and this is where the model earns its complexity. A ransomware operation may begin with information-intent credential theft, bundle data exfiltration as leverage, then make an economic demand for restoration. Intent categories are not rigid walls. They are the primary axis of an attack. Understanding the dominant intent tells you where to break the chain.
Three categories. Thirty-seven subtypes. Each one maps to a specific business exposure that your board already tracks, rather than an ephemeral delivery mechanism that changes before the next quarterly review.
What This Looks Like in Practice
Return to the financial services firm from January. A SharePoint notification arrived from a legitimate vendor domain. SPF, DKIM, and DMARC all passed. The vendor had an established communication history. The email body contained nothing suspicious.
Under technique classification, this generates no alert. It matched no known attack pattern.
Under intent classification, the question is different. The link routed through a redirect chain to an AITM proxy. The proxy captured session credentials. The detection system recognized this as the information-gathering stage of an economic-intent operation and flagged it before the attacker could insert a payment redirect into an active invoice thread. For the security team, this was one high-confidence alert with clear business context, not two disconnected events discovered after the money moved.
Where to Start Monday Morning
First, map your business exposure to specific sub-intents. If you process significant vendor payments, payment redirection is your primary economic risk, not “BEC.” When your CFO asks what the email security stack protects against, answer in financial exposure: “We reduced successful payment redirection incidents by 75% year-over-year, which at our average incident cost of $120,000 represents $360,000 in avoided losses.” That language closes budget conversations. Technique metrics never will. It also strengthens your SOC 2 audit narrative: you are measuring control effectiveness against specific financial exposures rather than technique categories that shift underneath you.
Second, ask whether your detection stack connects multi-stage operations. Pull the last three BEC incidents from your logs and trace them backward. Was there a credential harvest days or weeks before? A suspicious login? An inbox rule creation? If those generated separate, unresolved alerts, your tooling saw the pieces but not the operation.
Third, measure defense efficacy by intent. “We block 99% of phishing” is a technique metric. “We detect 73% of payment redirection attempts regardless of delivery method” is an intent metric. Only one tells your board whether the company’s money is actually protected.
This framework is not tied to any single architecture. It works whether you layer intent-aware detection on top of an existing Proofpoint or Mimecast deployment, build it into a dedicated platform, or assemble it from point solutions. The principle is portable because it describes how attackers think, not how any product works.
The email security industry does not need more signatures. It needs a better table.

