A mid-sized South African financial services firm suffered a targeted account-takeover on a Tuesday afternoon. The attacker acquired a set of credentials through a phishing campaign the previous Friday. On Tuesday at 14:22 SAST they authenticated into the victim's mailbox, established persistence through an OAuth consent grant, and began observing the mailbox traffic quietly.
By Wednesday morning the attacker was ready to act. They drafted an outbound message to the finance director impersonating a supplier invoice revision. The message was well-written, contextually correct, and sent from a legitimate mailbox inside the tenant.
This is the class of attack where a traditional email security posture fails silently.
Why traditional defence missed it
Outbound messages from a tenant's own mailboxes are auto-trusted by almost every email security product in the market. The assumption is that a message from an authenticated user inside the organisation is legitimate. That assumption is correct 99.4% of the time. It is catastrophically wrong the other 0.6%.
Inside that 0.6% are the single most expensive incidents an organisation will face: business email compromise where the compromised account is the attacker's most valuable asset.
What changed
We shipped a bridge in v1.1.3. When a user's identity provider flags their active session at elevated risk, our email detection revokes the auto-trust on their outbound traffic in real time. Every outbound message from that user now runs through the full detection fan-out, as if they were an unknown external sender.
The identity risk signal is already produced by Microsoft Entra ID Protection and Google Workspace. It is rarely consumed by email security products. Connecting the two is mostly an integration problem, not a research problem.
Identity is not a silo. A user's trustworthiness in the email domain depends on their trustworthiness in the identity domain. Products that treat the two as separate concerns leave a seam open. Attackers target the seam.
The Wednesday that mattered
Our case study customer had the bridge active in shadow mode at the time of the incident. When the attacker's outbound message hit the detection stack on Wednesday morning, the identity risk signal was already elevated from the Tuesday authentication. The auto-trust was suppressed. The message went through full behavioural analysis.
Behavioural analysis flagged the message on three signals at once: the sender had never sent an invoice revision to this recipient before, the banking details in the attachment did not match any supplier record in the tenant's outbound history, and the timing was inconsistent with the sender's normal invoice cadence.
Consensus score: malicious. The message was held, the security team was paged, and the compromise was contained before the finance director saw the email.
What it costs to build
The honest answer: less than you would think. Microsoft and Google already publish identity risk signals through well-documented APIs. The work was not inventing a detector — it was plumbing the signal into our existing email consensus engine with the correct weight.
The expensive part was the governance. Auto-revoking trust on a user's outbound mail is a material decision. The feature ships with tenant-admin consent, a two-person bypass for safe-room scenarios, and a hash-chained audit trail on every action.
An attacker with valid credentials is not the same as a legitimate user. Building the distinction into the detection stack was the work of v1.1.3. The Wednesday customer is one of several who avoided a fraud incident because the bridge fired correctly.