Third-Party Breach Monitoring: Check Every Vendor Domain by API

A vendor's breach reaches your data long before it reaches their questionnaire. So check the vendor's domain against a breach index instead, by API, and keep checking.

Two questions per vendor. Has this company itself been breached? And are its staff logins sitting in someone else's breach right now?

Both come back as JSON. And it's the second one, the one almost nobody watches, that gives you the early warning.

(We're XposedOrNot. We run a public breach index, 787 breaches as of 6 October 2026, and the partner API on top of it, so this is the loop we watch our own customers build.)

The short version

• In the 2026 Verizon DBIR, 48% of breaches involved a third party in some form (the metric includes flaws in vendor software). The 2025 edition had 30%.
• Organisations assess about 36% of their third parties, and a single assessment routinely takes four months or more (ProcessUnity, January 2026).
• We added 129 breaches to our catalog in the first nine months of 2026. Call it three a week. A questionnaire sent in January knows about none of them.
• One call per vendor domain gets you the breach count, the newest breach date, the exposed address count and how each breached site stored its passwords. The passwords themselves? Never in the response.

Four terms, so we're reading the same page:

What does a vendor domain breach check tell you, and what doesn't it?

It tells you two things, and you should keep them apart.

First, whether the vendor's own company appears in the breach catalog as the breached party. That's a lookup against the public breach catalog by the vendor's domain. Ours holds 787 breaches (6 October 2026), and 776 of them carry the breached company's domain, so the call is a straight filter.

Second, how many of the vendor's staff addresses sit in breaches of other services. Somebody at the vendor signed up to a project tool, a conference, a forum, with their work email.

That service got breached. Now the address, and often a password, is circulating.

The first answer is history, and you'd probably have found it in the news. The second one moves. Every time we index a breach that touches the vendor's domain, the count ticks up, and in our experience that's the number that predicts trouble.

Now the other half, because people over-read this. A domain check isn't a security rating. It knows nothing about the vendor's firewalls or patching, and a hit doesn't mean the vendor's systems were broken into.

What you get is exposure facts (which breach, when, what kinds of data). Each one is a question for the vendor. None of them is a verdict.

Why isn't the questionnaire enough?

Because of the clock. Most full assessments are repeated once a year or less (Drata, State of TPRM 2026, 309 respondents). In the ProcessUnity survey of 1,465 third-party risk practitioners, 64% of large organisations said a single assessment takes four months or longer, and 63% said it takes more than 40 hours of team effort.

So a typical vendor gets one long look, then eleven quiet months. Breaches don't schedule themselves around that.

The coverage line is the quiet one. If you assess 36% of vendors once a year, two thirds of your supply chain is never looked at by anyone, and the third that is gets a snapshot.

A domain check doesn't replace the questionnaire. It fills the eleven months, and it covers the vendors that never made the assessment list.

And the numbers behind that gap are worse than they look. In the Ponemon Institute's 2025 survey of 1,942 IT and security practitioners (sponsored by Imprivata), respondents averaged 20 vendors with access to their network, only 50% had a comprehensive inventory of those third parties, and 55% said their organisation doesn't evaluate a third party's security practices before granting it access to sensitive data.

Half the teams reading this can't list the vendors with network access. A domain list is the easiest inventory you'll ever build, and the upload file in step 1 is that list.

What does the vendor's staff exposure actually predict?

Here's the case that made this concrete for a lot of security teams.

In 2024, a threat actor logged into customers' data-warehouse tenants with stolen logins and took what was inside. Not by breaching the warehouse vendor. By using the customers' own credentials, harvested by infostealer malware, some as far back as November 2020.

About 165 organisations were notified as potentially exposed.

Mandiant's write-up (June 2024) put a number on it: at least 79.7% of the accounts used in the campaign had prior credential exposure. The signal existed for years before anyone acted on it.

Flip the roles and that's your vendor. If a vendor's staff logins are in circulation, the account that holds your data has a known weak point, and the vendor may not know it yet. Our stealer logs guide for MSSPs covers why a fresh stealer-log hit is a different conversation from a 2012 forum dump.

The academic baseline is more cautious, and worth knowing. In Google's study with UC Berkeley (Thomas et al., ACM CCS 2017 ), 7% of passwords exposed in third-party breaches still matched the person's live Google account; for people caught by phishing in the same study it was 25%.

Not every exposed password works. Enough do.

(One more, because people ask. The student-information vendor breach identified on 28 December 2024 was carried out, by the vendor's own account, with a single compromised credential on a support portal. One login, and school districts across a continent downstream.)

How do you run it? Six steps, one afternoon

This is the part the guides skip. Here's the whole loop with the xonThreatIntel+ partner API , in the order you'd build it.

1. Turn the vendor register into domains

Export your vendor list. Keep one column: the email domain the vendor's staff use. Not the marketing site (those often differ), the domain on their invoices and support emails.

Drop consumer mail domains. Our platform denylists them anyway (gmail.com and friends come back as rejected), but a vendor whose staff work from personal email is its own finding. Write it down.

Two more wrinkles, both common. A vendor with subsidiaries may run three staff domains, so ask which one your contacts actually mail from.

And a small vendor on a shared agency domain? Their count includes everyone else on it. Write that on the record so nobody panics later.

The file itself is boring, which is the point. One domain a line, text or CSV, no more than 500 valid domains in it.

Bigger list? Split it.

(And check the quota endpoint first. It tells you how many slots your plan has left, so you don't find out from a 403.)

2. Upload the file, then wait for ready

curl -X POST "https://plus-api.xposedornot.com/v2/partner/upload-domains" \
  -H "X-API-Key: $XON_KEY" \
  -F "[email protected]"

The response is a 202 with a summary of what happened to each line: accepted, bounced as invalid or denylisted, or already on your account. It also carries a batch_id. Poll that every minute or so until it says done.

And key everything on ready_for_query, not on "approved". Approved only means the domain resolved. Ready means we've finished building its breach data.

How long? Approval, minutes. Building the breach data behind ready_for_query is slower, and a very large domain parks in pending_approval until one of us has had a look.

3. Pull the summary for each vendor

curl "https://plus-api.xposedornot.com/v2/partner/domain-summary?domain=vendor.example" \
  -H "X-API-Key: $XON_KEY"

Four fields do most of the work.

Nothing in the response is a password. It's breach names, dates, data classes and counts, which is what lets your legal team approve the whole exercise (what we store and never store).

There's a pattern you'll only ever spot across a whole portfolio. The same breach name, on a dozen vendor domains, the same week. Payroll, ticketing, a conference platform: some shared provider leaked, and you now know which fourth party half your supply chain quietly runs on. No questionnaire returns that.

Shape the output and one finding reads like this (vendor and counts invented):

vendor:        acme-logistics.example   (tier: critical, data: shipment PII)
new finding:   2026-09-18  breach "SampleTicketingTool"  (breached 2026-06-01)
addresses:     14 on this domain   (Domain_Summary 41 total across 3 breaches)
data classes:  Email addresses; Passwords; Names
password_risk: easytocrack
executives:    1 director
tier:          1  -> call the vendor this week

Read how to read a domain breach-health report already? Then you know these fields. It's the same report, pointed at a vendor instead of a client.

4. Tier the finding, don't score it

We'd push back on boiling this down to one 0-to-100 number, and we say that as people who publish one on the free side.

Take a 2019 breach with a readable password and a 2026 breach with emails only. Different problems, and a blended score hides which one you're looking at.

Four tiers on one page. Anyone on the team applies it the same way on a Friday afternoon, which, as it happens, is exactly what an auditor wants to see.

5. Switch on the loop

Two ways, and you want both.

Poll with since. A freshly computed response carries an as_of watermark, and you hand that back on the next call to get only what we ingested after your last look.

The filter runs on when we acquired the breach, not when it happened. So a 2019 breach that only surfaced yesterday counts as new. Which, for your purposes, it is.

Empty result? That's the normal answer on a good day.

Or register one webhook for the whole account. When a newly indexed breach touches any of your vendor domains, including ones you upload later, you get a signed notification with per-domain counts and an as_of to pull with. Never an email address in the payload.

For onboarded domains that notification arrives within 15 minutes of the breach landing in our index.

Verify the signature (HMAC over the timestamp plus the raw body, reject stale timestamps), answer with a 2xx fast, and do the work on a queue. Key your records on vendor domain plus breach name, so a redelivered notification or an overlapping poll never alerts twice. The webhook reference has the code.

6. Talk to the vendor like a colleague

Nobody enjoys the email that says "you've been breached". Especially when, most of the time, they haven't. Their staff signed up somewhere that got breached, which is a different sentence.

A note that works, in our experience:

As part of our third-party programme we check our vendors' email domains against a public breach index. Yours currently shows 14 addresses across 3 breaches; the newest was indexed in September 2026 and included passwords. Could someone on your security side confirm those accounts have been reset, and that MFA is on for the accounts that touch our environment? Happy to send the breach names over.

Facts, a date, a specific ask, an offer, and no verdict anywhere in it.

Then record the date you asked and the date they answered, because that record is the evidence your framework wants (more on that below).

What about your vendors' vendors?

Every TPRM guide names fourth parties. Almost nobody monitors them. With a domain check the mechanics don't change, so there's not much excuse left.

Start with your critical vendors' DPAs or trust pages, where most of them publish a sub-processor list. Take the domains off it. Add them to the next upload file, tagged with the vendor they sit behind.

A finding on a sub-processor's domain then lands on your vendor's record as well as the sub-processor's.

And keep ex-vendors in the set for a while after the contract ends. We've seen it enough times: the data a vendor held doesn't leave when the invoice stops, and the breach that exposes it can surface years later. Six to twelve months is a sensible hold, longer if they held regulated data.

What does our own catalog say about vendor breaches?

We index breaches, so we looked at our own data two ways.

The first is the breached party. Of the 787 breaches in the catalog on 6 October 2026, 132 are companies classed as Information Technology, and between them they hold 4,657,744,209 records, 40% of everything we index. Software and service companies keep other people's data, so when one goes, the count is large.

The second is the path in. We went through all 787 catalog descriptions looking for breaches that happened at a vendor, supplier or contractor rather than at the company whose name is on the entry. Sixteen say so in plain words, and between them they hold 148,468,861 records.

(That's a floor from a keyword pass over short descriptions, and plenty of entries never say how the breach happened.)

Every one of those companies could have answered a questionnaire about its own controls the week before and still ended up in this table. The questionnaire asked about them. The breach came through someone they'd hired.

There's a third number to keep in mind when a vendor finding looks alarming. Of the 129 breaches we added in 2026 up to 5 October, 35 had happened more than a year before they reached us.

About one new finding in four is an old breach. Keep both dates on the vendor record.

Where does the check go wrong?

Four places, and knowing them keeps the vendor conversation fair.

Old breaches. A 2012 hit on a vendor's domain tells you about password habits in 2012. It's a tier 4 note, not a call.

People who've left. Domain exposure counts addresses, and some belong to staff who moved on years ago. That's noise for you, though the vendor should still have closed the accounts.

Work email on personal signups. The breach name is the service that leaked, not the vendor's systems. A vendor with 40 addresses in a 2019 design-tool breach wasn't breached. Their staff liked a design tool.

The index isn't the world. Nobody's catalog holds every breach, ours included. A clean result means nothing indexed for that domain today, and the vendor record should say it in those words. The same honesty applies when you show breach exposure inside your own product: a date and a denominator, never "safe".

Is it legal to check someone else's domain?

The short answer is that you're reading exposure facts about public breach data, and the result contains no passwords and no stolen records. Our data page sets out the legal basis, what's stored and what never is, and the processing agreement that goes with a partner account.

Three habits make it cleaner still. Tell vendors in the contract that you monitor their domain's breach exposure (some will ask for the same clause in return). Keep the detail rows inside the security team, because a list of a vendor's exposed staff addresses is personal data about people who don't work for you.

And have counsel read your clause, since we're a data provider and can't give legal advice.

Which rules want this evidence?

The regulations don't name a domain check. They do ask for ongoing monitoring of third parties and a record of it, and a dated finding with a dated vendor response is exactly that record.

None of these is satisfied by a tool alone. All of them are easier to evidence when the monitoring runs daily and writes itself down.

What does it cost against the alternative?

Public numbers, because that's how we price.

xonThreatIntel+ runs $99 a month for 10 monitored domains, $243 for 25 (webhooks and JSON feeds come in at this tier) and $447 for 50, billed monthly with a 30-day money-back window. Above 50 domains it's custom pricing. Fifty vendors watched every day for $447 a month, alongside the 40-plus hours of analyst time most teams already spend per questionnaire.

The rate limits won't get in the way of a vendor programme: 25 domain-summary calls a second, 5,000 an hour, 30,000 a day per key, with the remaining budget in every response header.

Building a TPRM or GRC product rather than running a programme? Then the platform mode is this post with your logo on it. Each of your customers is a tenant with their own vendor list, alerting rules and reports, the lookups your product sends are processed in memory and not logged, and Detailed_Breach_Info is the per-breach object you'd render.

The 12 questions to ask any breach monitoring vendor apply to us too, and our answers are on the data page.

Want to see the data before any of that? Two free routes.

Your own company's domain is free on the community side, verified once at xposedornot.com/domain , with the same report by API and alerts. That's where to start, because you'll read the result the way a vendor would read theirs.

And one vendor at a time, the exposure check takes a domain name, nothing else, and gives you the snapshot with a PDF. Run your most critical vendor through it today. Then decide whether you want to know every day.

Your vendor-domain checklist

• Vendor register exported to one domain per vendor, consumer mail domains flagged.
• Domains uploaded in files of up to 500. Quota checked first.
• Integration keyed on ready_for_query, not on "approved".
• Tier rule agreed and written down before the first result arrives.
• since bookmark saved after every poll, or the account webhook verified and live.
• Critical vendors' sub-processor domains added, tagged to the vendor.
• Ex-vendor domains kept for six to twelve months after offboarding.
• Vendor contract says you monitor their domain's breach exposure.
• Detail rows restricted to the security team.
• Every finding and every vendor reply dated on the vendor record.
• Your own domain checked first, for free.

Quick answers

Where the numbers came from

• Our catalog numbers (787 breaches, 11,633,142,187 records, 776 carrying the breached company's domain, 132 Information Technology breaches holding 4,657,744,209 records, and the 129 breaches added in 2026 to 5 October, 35 of them over a year old on arrival) come from the public XposedOrNot catalog at api.xposedornot.com/v1/breaches. Fields used: domain, industry, breachedDate, addedDate, exposedRecords, exposureDescription. Pulled 5 October 2026, re-run 6 October. Records, not people.
• Vendor-path breaches (at least 16 of 787, 148,468,861 records): a keyword pass over the catalog's exposureDescription field for "third-party vendor", "service provider", "partner", "contractor" and similar, each hit read by hand. A floor, because many descriptions don't say how the breach happened.
• Verizon 2026 Data Breach Investigations Report , May 2026: third-party involvement in 48% of breaches, up 60% on the prior dataset's 30%. Verizon's metric counts three relationship types, including vulnerabilities in a vendor's software, so it's wider than "a vendor got breached". The 30% is from the 2025 DBIR .
• The 36% coverage figure, the four-months-or-longer assessments (64% of large organisations) and the 40-plus hours of effort (63%) are from ProcessUnity's State of Third-Party Risk Assessments 2026 , a Ponemon-fielded survey of 1,465 practitioners published in January 2026. A TPRM vendor paid for it, so we read it as a direction, not a census.
• "Most full assessments are repeated once a year or less" is from Drata's State of TPRM 2026 . Only 309 people answered it and a compliance vendor ran it, so it's a supporting line, nothing more.
• The 20 vendors with network access, the 50% with a full inventory and the 55% who don't evaluate before granting access come from the Ponemon Institute's State of Third-Party Access in Cybersecurity 2025 (sponsored by Imprivata), which surveyed 1,942 practitioners in the US, UK, Germany and Australia.
• The data-warehouse campaign is documented in Mandiant's June 2024 write-up : roughly 165 organisations notified, at least 79.7% of the abused accounts with prior credential exposure, and an infostealer infection as far back as November 2020.
• Thomas et al., "Data Breaches, Phishing, or Malware?" , ACM CCS 2017: 7% to 25% of exposed passwords matched the person's Google account.
• The single-credential case is the vendor's own account on its incident page : identified 28 December 2024, access gained "using a single compromised credential" on a support portal.
• For the rules table we read the official texts: DORA (Article 28, and Article 64 for the 17 January 2025 start), NIS2 (Article 21(2)(d) and 21(3)), NIST CSF 2.0 from February 2024 (GV.SC-04 and GV.SC-07), NIST SP 800-161r1 , and the SEC's 2023 press release on Regulation S-K Item 106.
• Everything we say about the partner API (500 domains a file, batch status and ready_for_query, the denylist, the domain-summary fields, since and as_of, the signed account webhook, and the limits of 25 a second, 5,000 an hour and 30,000 a day per key) is in three docs pages we read on 6 October 2026: Onboarding Domains , Checking Breaches and Webhook .
• Plan prices and the 15-minute alert figure for onboarded domains are as shown on xonThreatIntel+ for platforms on 6 October 2026.
• The vendor email, the tier table and the sample finding are ours. "acme-logistics.example", "SampleTicketingTool" and the "14 addresses in 3 breaches" counts are made up and match no vendor and no catalog entry.