When a legitimate vendor starts behaving differently
Learn how changes in a trusted vendor relationship can expose account compromise and guide a focused security investigation.
Consider a vendor that has emailed the same three finance contacts for 12 months. It sends invoices through an established process and has never requested a bank-detail change.
Then the same mailbox contacts a new employee. It attaches a revised invoice, asks the employee to update the payment beneficiary, and says the usual approval can wait. The domain is correct, authentication passes, and no malicious link is present.
This scenario is hypothetical, but the detection problem is real. When an attacker compromises a vendor mailbox, the identity remains legitimate while the account's behavior begins to change.
The FBI IC3 2025 Internet Crime Report recorded 24,768 business email compromise complaints and more than $3 billion in reported losses. Those figures cover the broader BEC category, but they show the stakes of fraud that exploits trusted business communication.
Authentication can pass while trust has changed
SPF, DKIM, and DMARC help confirm that a message was sent through systems authorized for a domain. They do not prove that the vendor intended the request or that the expected person still controls the mailbox.
A compromised account may send from the correct address, reply inside a real thread, and reference genuine invoices or projects. The message may contain no malware, suspicious attachment, or known-bad link for message-level checks to find.
This is one form of vendor email compromise. The attacker first gains access through account takeover, then uses the vendor's history and reputation to make a fraudulent request look routine.
Sender authentication remains essential, but it answers only one question: where did this message come from? Behavioral analysis asks a second question: does this request fit the relationship you already know?
Build a vendor relationship baseline
Recurring vendor relationships leave useful history. A behavioral baseline summarizes the people, requests, documents, and processes that normally appear in that relationship.
For a vendor, useful baseline signals may include the following. Choose signals tied to real workflows rather than a generic idea of normal:
- Usual participants: The vendor contacts and internal teams that normally communicate.
- Common subjects: Invoices, purchase orders, deliveries, contracts, or support requests.
- Document patterns: The file types, names, templates, and delivery methods normally used.
- Communication rhythm: Typical timing, frequency, and message volume.
- Established processes: The normal route for approvals, payments, and account changes.
- Known contact details: Expected sender,
Reply-To, billing, and escalation addresses.
A baseline is not a permanent rule. It gives you a reference point for deciding whether a new message is routine, explainable, or worth investigating.
The hypothetical relationship from the opening might look like this. The comparison makes each change explicit:
Previous 12 months
Recipients: 3 known finance contacts
Requests: invoices and delivery documents
Payment changes: 0
Approval route: procurement, then finance
New message
Recipient: first-time contact
Request: change payment beneficiary
Process: bypass procurement approval
Document: new invoice format
No row proves compromise. The value comes from seeing several changes appear in the same request instead of judging each one in isolation.
Look for combinations, not isolated changes
Businesses change constantly. Vendors hire people, update templates, start projects, and contact new teams. A useful detection process must allow normal change without treating every first-time event as malicious.
Combinations deserve more attention than isolated anomalies. Prioritize cases where a relationship change appears beside a sensitive action:
- New recipient plus sensitive request: A first-time contact receives a request for payment, credentials, or private data.
- Process change plus urgency: The vendor asks to skip approval and complete the action immediately.
- New document plus financial change: An unfamiliar invoice introduces a new beneficiary or bank account.
- New channel plus authentication request: The sender moves the recipient to an unfamiliar portal or messaging service.
- Wider activity change: The account starts contacting several departments or sending more messages than usual.
- Style change plus stronger evidence: Different wording supports other anomalies but should not decide the verdict alone.
None of these combinations guarantees that the account is compromised. They do raise the priority of the message and give you specific facts to verify.
How to investigate a vendor anomaly
Start with the relationship, not only the suspicious message. Your goal is to confirm whether the change belongs to the vendor's real business process.
- Preserve the evidence. Keep the original message, headers, attachments, thread identifiers, and delivery timestamps.
- Compare historical communication. Review previous recipients, requests, documents, timing, and approval routes.
- Identify the requested action. Determine whether the message changes money, access, data, or an established process.
- Search for related activity. Check whether the vendor contacted new recipients or made similar requests elsewhere.
- Verify through a trusted channel. Use a phone number, portal, or contact already stored in the vendor record.
- Pause the sensitive action. Hold payment, bank-detail, access, and data-sharing changes until verification finishes.
- Respond to confirmed compromise. Find related messages, contain pending actions, notify affected teams, and coordinate with the vendor.
Replying to the same thread is not independent verification because the attacker may control it. A phone number or address included in the suspicious message is not independent either.
High-risk process changes should require verification even when behavioral signals look normal. An attacker who understands the relationship may imitate its usual language, recipients, and timing.
What you should see in a behavioral alert
When an alert lands in your queue, it should tell you more than "unusual vendor activity." You need to see what changed, how it differs from the relationship's history, and why those changes matter together.
You should be able to inspect:
- The age and volume of the observed vendor relationship.
- Whether the recipient and request type have appeared before.
- Which normal participants or approval steps are missing.
- Whether payment, contact, or delivery details changed.
- Whether similar messages reached other people.
- Which signals increased the risk and which signals supported legitimacy.
An API-based email security platform can give you this context by comparing a new message with permitted mailbox history. That comparison helps you spot attacks that look valid when you view the email on its own.
Your verdict should feed back into future detection. Marking a change as legitimate can improve the baseline, while confirming an attack can strengthen future alerts and response.
Where behavioral detection has limits
Behavioral baselines are useful, but they are not complete security boundaries. Some relationships have little history, and legitimate business changes can make yesterday's pattern obsolete.
Common sources of false positives include the following. Account for them when you tune detection and review alerts:
- A new vendor or first-time project.
- A staff or responsibility change.
- Seasonal billing and year-end activity.
- A merger, acquisition, or supplier transition.
- Shared mailboxes and rotating contacts.
- A new portal, invoice format, or approval process.
An attacker may also study the mailbox and stay close to normal behavior. That is why behavioral evidence should support sender checks, content analysis, and business controls rather than replace them.
As relationships evolve, update your baselines and track how you resolve alerts. Most importantly, keep independent verification and dual approval in place for sensitive actions such as bank-detail changes and high-value payments.
Trust the relationship and verify the change
Authentication can show that an email came through the vendor's real systems. Behavioral context can show whether the request belongs to the relationship your organization has actually established.
When a legitimate vendor starts behaving differently, do not assume fraud and do not ignore the change. Review the evidence, pause the sensitive action, and verify the request through a channel the attacker does not control.
