TL;DR: Rubicon said its security team protects 13 million service locations and more than 8,000 vendor and hauler partners, and that business email compromise drove a move away from outdated decision-tree tools toward AI-powered security, according to Abnormal AI. The lesson is that sprawling third-party ecosystems expose identity and email trust assumptions that static controls struggle to govern.
At a glance
What this is: This webinar case study shows how Rubicon's large partner ecosystem and BEC exposure pushed the team to rethink legacy email security and adopt AI-driven detection.
Why it matters: It matters to IAM and security teams because third-party access, email trust, and identity-led fraud all become harder to control as vendor ecosystems scale.
By the numbers:
- Rubicon's security team protects 13M+ service locations and 8,000+ vendor/hauler partners across the US.
👉 Watch Abnormal AI's webinar on Rubicon's AI-driven response to business email compromise
Context
Business email compromise is an identity-driven attack pattern that exploits trust in people, mail flows, and partner relationships rather than technical malware alone. In Rubicon's case, the scale of the partner ecosystem makes those trust paths materially harder to monitor with static, decision-tree controls.
For IAM and security practitioners, the important question is not whether BEC exists, but whether the organisation can detect anomalous message behaviour, privilege misuse, and vendor-targeted impersonation quickly enough to contain damage. That is where identity-aware detection and response start to matter more than legacy filtering alone.
Key questions
Q: How should security teams reduce business email compromise risk in partner-heavy organisations?
A: Start by identifying the email-driven business processes that can trigger money movement, access changes, or vendor updates. Then add out-of-band verification for those specific workflows, because BEC succeeds when trusted communication paths are treated as proof. The goal is to verify identity before action, not after damage has occurred.
Q: Why do large vendor ecosystems make business email compromise harder to stop?
A: Because every legitimate partner interaction gives attackers another believable story, sender pattern, or workflow to imitate. As the partner set grows, static rules generate more false confidence and more noise. Teams need behavioural detection and process verification to separate normal operational variation from fraud.
Q: What do organisations get wrong when they treat BEC as only an email security issue?
A: They miss the fact that the attacker is targeting a business process, not just an inbox. If finance, procurement, or access workflows will accept an email as sufficient authority, the control gap sits in governance and verification. Email filtering helps, but it cannot replace identity-aware approval design.
Q: How can security teams tell whether BEC controls are actually working?
A: Measure whether suspicious requests are caught before they change payment, vendor data, or access rights. If the only metric is blocked spam, the programme is blind to the attacks that matter. Effective control shows up in reduced fraud execution, faster verification, and fewer authorised changes from unverified email requests.
Background and context
Why business email compromise outgrows decision-tree controls
Decision-tree detection works by matching known patterns, such as sender anomalies, suspicious links, or domain lookalikes. That approach breaks down when attackers vary message content, timing, and conversation context to look legitimate. AI-assisted detection uses behavioural signals across message history, sender reputation, and interaction patterns to identify risk that fixed rules miss. In large partner ecosystems, the signal challenge is not only volume but also legitimate variation across vendors, haulers, and service locations.
Practical implication: security teams should assess whether their email controls can detect behavioural anomalies, not just signature-based phishing indicators.
How partner sprawl changes identity and email trust
A broad third-party network increases the number of identities, relationships, and approval paths that attackers can impersonate. Business email compromise often succeeds because recipients trust a known supplier, executive, or operational contact enough to act quickly. In that environment, identity assurance is not just about authentication at login. It also includes message provenance, domain hygiene, and risk scoring for unusual requests that arrive through otherwise trusted channels.
Practical implication: map external communication flows to the identities and business processes most likely to be abused in payment, invoicing, and vendor-change workflows.
AI-powered detection beyond traditional phishing controls
AI-powered security tools can correlate behavioural signals across users, inboxes, and external relationships to flag attacks that do not match known templates. That is especially relevant when the attack surface includes operational email, procurement, and vendor coordination rather than only employee inboxes. The value is not that AI replaces policy. It is that it can surface subtle changes in communication patterns quickly enough for triage, escalation, and containment in environments where manual review cannot keep up.
Practical implication: pair AI detection with clear response playbooks so suspicious partner communications can be verified before payment or access decisions are made.
NHI Mgmt Group analysis
Business email compromise is an identity problem before it is an email problem. The core weakness is not simply malicious messages, but the organisation's willingness to trust sender identity, domain familiarity, and partner context at face value. In a network with 8,000+ partners, that assumption becomes too weak to support safe operational decisions. Practitioners should treat BEC as a governance and verification failure, not just a phishing problem.
Partner ecosystem scale creates message-trust debt: every additional vendor, hauler, and service workflow increases the number of legitimate-looking requests that defenders must distinguish from fraud. That makes deterministic controls less effective because attackers hide inside normal business variation. The practical conclusion is that security programmes need stronger behavioural verification around communications that can trigger payment, access, or workflow change.
AI-assisted detection is now a control response to attacker adaptation, not a novelty feature. Decision-tree methods assume attacks are stable enough to match known patterns, but modern BEC campaigns adapt language, timing, and context to avoid simple rules. That means detection must become more contextual, and response must be tied to operational authority so suspicious requests can be paused before they become business actions.
Identity trust in email channels should be measured by actionability, not inbox volume: the real test is whether a team can verify an unusual request before it changes money movement, vendor records, or access paths. Organisations that still equate email security with blocking spam are measuring the wrong thing. Practitioners should use BEC as a proxy for whether identity-aware controls are embedded in business operations.
Rubicon's case shows why resilience depends on compressing verification time. When partner ecosystems are broad, fraud wins by moving faster than manual validation. That does not mean every message needs heavy process. It means the few messages that can trigger operational change need stronger identity checks, clearer escalation paths, and less trust in first-contact claims.
From our research:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
- For a broader governance lens, read the NHI Lifecycle Management Guide for practical coverage of provisioning, rotation, and offboarding.
What this signals
Message-trust debt is the accumulation of legitimate-looking external relationships that attackers can abuse to make fraudulent requests appear normal. As partner ecosystems grow, security teams need a control model that verifies context before action, not after approval. That aligns with broader identity governance thinking, where trust is something to be evidenced, not assumed.
Rubicon's scale is a reminder that email security, vendor governance, and identity operations now overlap in the same workflow. Teams that still separate phishing defence from access and process governance will miss the point of modern BEC. The next step is to integrate verification into business operations, especially where external requests can change money, records, or access paths.
With 44% of developers reportedly following secrets-management best practices, per The State of Secrets in AppSec, the broader pattern is clear: trust failures usually sit inside everyday workflows, not edge-case attacks. Security programmes that understand that pattern can build faster verification and tighter offboarding across human, NHI, and partner identities.
For practitioners
- Map high-risk email workflows Identify which messages can change payment instructions, vendor details, or access approvals, then require secondary verification for those paths. Focus first on procurement, finance, and partner onboarding flows where BEC produces the highest business impact.
- Shift detection from signatures to behaviour Evaluate whether email controls can correlate message timing, sender history, reply-chain changes, and unusual request patterns instead of relying only on static indicators. This is the difference between filtering known phishing and spotting a credible impersonation campaign.
- Add identity verification to partner change requests Require a callback or out-of-band confirmation before accepting bank, routing, or contact changes from external parties. Use the verified channel, not the email thread that requested the change, to confirm legitimacy.
- Tie BEC response to business process owners Make finance, procurement, and vendor management part of the containment path so suspicious requests can be paused before approval. Security teams should not own the decision alone when the fraud target is a business workflow rather than an endpoint.
- Use the NHI Lifecycle Management Guide for partner governance Apply lifecycle discipline to third-party access and partner communication paths so onboarding, change control, and offboarding do not leave stale trust in place. The NHI Lifecycle Management Guide is the right reference when partner identity sprawl becomes part of the fraud surface.
Key takeaways
- Business email compromise is really a trust-and-verification failure that exploits normal partner workflows.
- Large vendor ecosystems increase the number of believable attack paths, which makes static email controls less reliable.
- The strongest response is to verify high-impact requests before they change money, access, or vendor records.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | BEC exploits weak trust validation in operational communications. |
| NIST CSF 2.0 | DE.CM-1 | Behavioural detection is needed to spot abnormal message and request patterns. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit verification before acting on external requests. |
Add verification steps to high-impact workflows and reduce reliance on sender trust alone.
Key terms
- Business Email Compromise: Business email compromise is a fraud technique where attackers use deceptive email messages to trick people into changing payments, records, or access decisions. It succeeds by abusing trust in a sender, a relationship, or a routine business process rather than by breaking encryption or exploiting software flaws.
- Message Trust Debt: Message trust debt is the accumulated risk created when an organisation keeps adding trusted communication paths without adding stronger verification. Over time, legitimate-looking requests become easier for attackers to imitate, and defenders rely too heavily on familiarity instead of proof.
- Behavioural Email Detection: Behavioural email detection looks for abnormal communication patterns rather than only known malicious indicators. It correlates timing, reply behaviour, relationship history, and request context so defenders can catch impersonation attempts that are designed to look routine.
- Partner Workflow Verification: Partner workflow verification is the practice of confirming external requests through an independent path before a business action is taken. It matters when third-party messages can trigger payments, account changes, or vendor updates that would be costly to reverse after the fact.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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 Abnormal AI: Rubicon Sharpens Security While Reinventing Digital Waste and Recycling Industry. Read the original.
Published by the NHIMG editorial team on 2026-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org