Skip to content

Why Threat Modeling Your Third-Party Integrations Should Be Standard Practice

Jul 30, 2025

Secure the architecture, not just the contract

Most security teams wouldn’t dream of exposing an admin panel on a public login screen without multi-factor authentication, let alone using a password like “123456.”

But when it’s a third-party vendor? That kind of risk often slips through the cracks.

That’s precisely what happened when Paradox.ai, an AI hiring platform used by major enterprises including McDonald’s, left its backend open to the internet. As WIRED reported¹, a security researcher found the admin login embedded in the applicant page, logged in with a weak password, and gained access to sensitive candidate data across multiple customers.

McDonald’s didn’t build the platform. And like most companies, they likely didn’t apply the same threat modeling rigor to their vendor systems that they use internally. That’s not negligence, it’s the industry norm.

And that’s the problem.

Vendor Risk Isn’t Just About Compliance Anymore

In most enterprises, third-party risk management continues to rely on certifications, assessment forms, and contractual obligations. SOC 2? Check. ISO 27001? Check. Security questionnaire? Check.

But none of those things would have revealed what a basic architecture diagram could have:

  • An admin login exposed on a public page
  • No MFA on privileged access paths
  • Weak passwords in a production environment

This wasn’t a sophisticated breach. It was a visibility failure.

And it’s a case study in why architectural security needs to extend beyond your own systems, especially when sensitive workflows are outsourced.

We Don’t Threat Model the Things We Don’t Build

And that’s understandable.

When you license a SaaS product or integrate with a third-party API, your goal isn’t to reverse-engineer their architecture. It’s to trust that their security posture is sound. You expect due diligence. You rely on contracts. You check the boxes.

But here’s the flaw in that logic:

Threat modeling isn’t just about what you build. It’s about what your users and your data depend on.

In this case, McDonald’s was relying on a vendor to handle a high-volume hiring workflow. That vendor, Paradox.ai, made architectural decisions about access, authentication, and interface design that ultimately put McDonald’s brand in the headlines.

And that’s what makes this so frustrating. A security architect inside McDonald’s would have flagged these issues from a mile away: a public admin interface, no MFA, weak credential enforcement. However, because it was a third-party app, it likely never went through their internal threat modeling process. 

And that’s not a McDonald’s problem. It’s how most organizations operate today.

Model the Integration, Not the Vendor

If a system touches sensitive data, drives business-critical workflows, or connects to your environment, it should be modeled—even if you didn’t build it. That doesn’t mean you need source code or internal documentation. It means modeling from the outside in, based on how that system behaves in your environment.

The goal is to proactively model the parts of a third-party system your business relies on so you can understand where it intersects with your architecture and where it may introduce risk.

That starts by focusing on where the platform connects, what it processes, and how those pathways are secured.

In practice, this includes:

  • Identifying the assets at risk (e.g., data, access, functionality)
  • Mapping integration points (APIs, SSO flows, webhook callbacks)
  • Documenting user roles and access patterns (e.g., who logs in and what they can reach)
  • Identifying trust boundaries (where external platforms cross into internal infrastructure)
  • Flagging authentication assumptions (e.g., does login enforcement depend on the vendor?)

These are foundational questions that help you assess real-world risk before it becomes real-world impact.

Model What You Depend On

ThreatModeler helps security, architecture, and procurement teams move beyond checklists and gain real visibility into the systems they build, and the ones they buy. By modeling how third-party platforms interface with your systems, users, and data, you can identify architectural risks that compliance documentation may overlook.

Because even if you didn’t build the system, you’re still responsible for what it exposes.

Schedule a demo to see how ThreatModeler supports a secure-by-design approach at scale, across your organization and your vendor ecosystem.

Footnote:

¹ Andy Greenberg, “McDonald’s AI Hiring Chatbot Left the Door Open to Hackers,” WIRED, July 9, 2025.