Every integration is a place where your data flow diagram runs off the edge of the page. On the other side is a process you cannot inspect, operated by people you have never met, secured to a standard you are taking on faith and a questionnaire. It is genuinely uncomfortable to model, and the usual response is to hand the problem to procurement, who send the vendor a security questionnaire, receive a completed security questionnaire, and file it.
That artifact is worth having, but it is not a threat model, and it answers a question you cannot verify anyway. What the vendor claims about their controls is a statement about their system. What matters in your model is a statement about yours: how much of your system is reachable if those claims turn out to be false. And that half is entirely under your control. Every field you send, every scope you granted, every callback you trust, every script you embedded — all of it was decided on your side, and all of it can be changed without a single conversation with the vendor. You cannot threat model the vendor. You can threat model the integration, and that is where the findings live.
The short version: Start from a real inventory, because the vendor register and the OAuth grant list disagree. Classify each integration by what it actually holds — data you push, access you granted, data you trust coming back, code it runs in your users' browsers — since each of those fails differently. Then work the boundary questions, and finish by assuming the vendor is compromised and asking what has already gone, what stays valid, how you would find out, and whether you can cut them off without an outage.
The integrations you actually have
The vendor register lists the integrations that went through procurement. The system contains those plus the ones a team wired up in an afternoon because the feature shipped on Thursday, and those are rarely the least privileged. As with an API endpoint inventory, the discovery step comes before the modelling and routinely produces the first finding on its own.
| Source | What it reveals |
|---|---|
| Vendor / procurement register | What was formally approved. The baseline you compare everything else against. |
| Identity provider: OAuth grants and SSO apps | Which third parties hold a live grant into your workspace, and at what scope. Frequently the most surprising list in the room. |
| Egress logs and outbound firewall rules | Who your systems actually talk to, as opposed to who you think they talk to. |
| Frontend script tags and the tag manager container | Whose code executes in your users' browsers. The container is its own deploy pipeline, usually with its own governance. |
| Issued API keys and service accounts | Credentials you gave out. Note the ones with no expiry and no owner still listed in your directory. |
| Inbound webhook routes | Endpoints that exist solely so a vendor can call you. Every one is an unauthenticated route until proven otherwise. |
| SPF records and mail configuration | Who is authorised to send email as your domain — an integration nobody thinks of as one. |
Classify by what the integration holds
Vendors are not a single category of risk, because integrations are not a single kind of thing. Most vendors hold more than one of the following, and each fails in a different direction, so it is worth naming them separately on the diagram rather than drawing one arrow labelled with the company's name.
| Kind of access | Examples | What dominates the threat model |
|---|---|---|
| Data you push | Analytics, error tracking, CRM sync, email delivery, data warehouse feeds | Scope of the payload. The exposure is everything you have ever sent, and it does not come back when the contract ends. |
| Access you granted | OAuth apps, API keys, service accounts, vendor support access to your admin console | Permission scope and lifetime. A compromise of the vendor becomes an authenticated session in your system. |
| Data you accept back | Webhooks, callbacks, enrichment responses, imported files, status feeds | Verification. Whatever you treat as fact on the vendor's word is a thing an attacker would like to be able to say. |
| Code you execute | Analytics tags, support widgets, session replay, payment scripts, embedded SDKs | Full compromise of the page it loads on. This is the one people consistently under-rate. |
That last row deserves saying plainly, because it is easy to file a marketing tag under "marketing" rather than under "arbitrary code with same-origin access to every session it loads in." A third-party script reads the DOM, reads anything in local storage, sees form fields before submission, and can call home — and it ships on the vendor's release schedule, not yours, from a URL you do not control. It is a second deploy path into your product with none of the review you built around the first one. Web-skimming attacks work precisely this way: nothing about the merchant's own code is compromised, only the script it politely loads on the checkout page. If you have just finished modelling your CI/CD pipeline, the tag manager is the same problem wearing a different hat, and it usually has weaker controls than the pipeline it bypasses.
Four questions at the boundary
What do they actually receive? Work at field level, not dataset level. "Customer records" is not an answer; a list of fields is. The interesting exposure is almost always incidental rather than intended — nobody decided to send personal data to the analytics vendor, it simply arrived in a URL that contained an email address, or in an error report that captured the whole request body including the authorization header, or in a session replay that recorded a form field the masking rules did not know about. Ask what the vendor's SDK captures by default, because the default is usually "everything, for your convenience."
What can they reach? Compare the scopes actually granted against the feature that justified them. Integrations are commonly installed at the permission level the vendor's documentation suggests, which is the level that makes every one of their features work, not the level yours needs. Then ask about shape as well as size: is the access standing or requested per use, is it restricted by IP or by nothing, does the vendor's support team have a path into your production console, and is that path logged in your system or only in theirs.
What do you trust coming back? Webhooks are the quiet one. The endpoint exists to be called by someone else, so it is exposed by design, and the question is what authenticates the call — a verified signature over the raw body with a timestamp that prevents replay, or knowledge of a URL that has appeared in a dozen configuration screens and at least one support ticket. Then the second half, which matters more: what does your system do with the payload? A webhook that says a payment succeeded, a subscription upgraded, a document was signed, or an identity check passed is an assertion of fact that changes state. If it is accepted without verification, you have not built an integration, you have built an unauthenticated endpoint that grants entitlements.
What runs in your context? For every embedded script: is it pinned by integrity hash or loaded from a mutable URL, is there a content security policy that would actually constrain where it can send data, does it load on pages that handle credentials or payment details, and is there a review step when the vendor changes what that script does — which they can do at any time, without telling you.
The STRIDE sweep, at integration altitude
| Category | What to ask of an integration |
|---|---|
| Spoofing | What proves an inbound call is really from the vendor — a verified signature, or a source IP and an unguessable path? What proves an outbound call reaches the real vendor: certificate validation, or a hostname that expired and was re-registered by someone else? |
| Tampering | Can a vendor payload alter records it should never touch? Does an imported file or enrichment response get written straight into your data store, and is it validated the way user input would be? |
| Repudiation | When the vendor's identity acts in your system, is the log entry distinguishable from a user's? Could you reconstruct, after a breach notice, everything that identity did in the preceding six months? |
| Information disclosure | What leaves in each payload beyond what the feature requires? What is in their retention policy, in their sub-processors, in their support tooling, and in their logs — which are now also your logs. |
| Denial of service | What happens to your product when the vendor is slow or down? A synchronous call to a third party inside your critical path makes their availability your availability — and a blocking script tag makes their outage your blank page. |
| Elevation of privilege | Can the integration's identity do anything a person could not — bypass approval, act across tenants, create further credentials? Does the OAuth grant carry admin scopes for a feature that only reads calendars? |
Assume they are breached
The unanswerable question is whether a vendor will be compromised. The useful question is what happens when one is, and it is answerable this afternoon. This is the section that turns a vendor review into a threat model, and it produces the findings that actually get funded.
- What has already left. Data sent cannot be un-sent. Your exposure is not what you send today, it is the accumulated set plus their retention period — which is why "we only send them what they need" and "we have sent them everything since 2022" are both true and only one is on the register.
- What stays valid. Standing credentials keep working until revoked. Can you enumerate every key, token, and grant this vendor holds, and revoke them in minutes rather than days? If nobody can produce that list under calm conditions, nobody will produce it during an incident.
- What they can push. A compromised vendor is a trusted source that can now send you forged webhooks, poisoned data, or modified JavaScript. Every trust you extended outbound is a capability the attacker inherits inbound.
- How you would find out. Most organisations learn from the vendor's disclosure email, weeks later. Ask what detection you own: would unusual volume or an unusual operation from the vendor's identity look different from normal traffic in your logs, and is anyone looking?
- Whether you can cut them off. The revocation path is a control, and like any control it either exists and has been exercised or it is a hope. If disabling the integration takes down checkout, you will not disable it, and the decision will be made under pressure by someone weighing a breach against an outage.
For the two or three vendors that sit closest to the crown jewels, build the attack tree under a goal like "read our customer data without touching our systems." The branches are the integrations, and what the tree exposes is how many of them terminate in the same place — because a vendor breach is one of the few scenarios where defense in depth genuinely may not apply. The attacker arrives holding valid credentials, through a channel you built, from a source your controls are configured to trust.
The compliance overlay
Most of this doubles as regulatory work, which is worth knowing because it changes who will pay for the fixes. Under GDPR the vendors processing personal data on your behalf are processors, their vendors are sub-processors, and the accountability for choosing them stays with you. SOC 2 asks how you assess and monitor vendors; ISO 27001 has a whole control set for supplier relationships. A per-integration model that names the data, the scope, the retention, and the revocation path answers those questions with the same artifact, rather than maintaining a separate spreadsheet that says roughly the same thing less precisely. The mechanics of using a model as evidence are covered in closing the SOC 2 evidence gap and in speaking ISO 27001 with a risk register.
What to record
Put the vendor on the diagram as an external entity and the integration as the flow, then record findings against the flow rather than the company. "This vendor is high risk" is not actionable; "this integration holds a write-scoped grant into the customer directory for a feature that only reads names, and its inbound webhook is unsigned" is two risk register entries with two owners and two fixes. Where the finding is systemic across vendors — no signature verification anywhere, no inventory of issued keys, no CSP on the pages that load third-party scripts — record it once at that level, because the fix is one piece of work rather than fifteen.
Then write down the assumptions, which for vendor integrations decay in a specific and predictable way: the scope you believed was read-only, the fields you believed the SDK excluded, the sub-processor list you believed was current, the script you believed only loaded on marketing pages. None of those are under your change control. The vendor can alter every one of them without a deployment on your side, which makes their renewal date, their sub-processor notification, and their SDK upgrade the natural triggers for revisiting the model — and makes attack surface here something that can grow while your own codebase sits perfectly still.
Where vendor threat models go wrong
- Reviewing the vendor instead of the integration. The questionnaire describes their controls. The model has to describe your exposure, which is a different document with different owners.
- Reviewing once, at purchase. The scope granted at signature, the data sent three years later, and the SDK version shipping today are three different risks, and only the first one was ever assessed.
- Treating the browser script as marketing's problem. It is code execution in your users' sessions on your origin, and it deserves the review your own code gets.
- Trusting inbound because it is outbound-initiated. A webhook endpoint is a public endpoint. The vendor's name in the payload is not authentication.
- Modelling the vendor and skipping their vendors. The sub-processor list is part of your attack surface, and it changes without your involvement.
- No revocation drill. A control nobody has ever exercised is a plan, and incidents are where plans go to be discovered.
The through-line is the same one that runs through every model in this series: trust is not a property of a company, it is a set of specific permissions you granted, written down somewhere, revocable in principle. The work is making sure they are written down somewhere you can find them, and revocable in practice.
Healthcare raises the stakes on all of it, since a vendor touching patient data is a business associate with contractual obligations attached and a breach notification clock that starts running on your side too. See threat modeling for healthcare, or start from the pre-labelled DFD in the free threat modeling templates.