Your Vendor Got Breached, Not You: What the ServiceNow and Klue Incidents Teach About Third-Party Risk

In June 2026, two names dominated the security newsletters: ServiceNow and Klue. Neither was a company most people at a 40-person Nottingham firm would recognise, and yet both incidents rippled outward into businesses that had never signed a contract with either. That is the uncomfortable shape of modern risk. You can run tidy patching, enforce multi-factor authentication, and train your staff to spot phishing, and still wake up to a data exposure notice because a supplier three steps removed from your invoicing left an OAuth token where it shouldn't have been.

The lesson from both breaches is blunt: your security posture is now defined by the weakest credential hygiene in your vendor chain. Not your own. Someone else's. And that changes what vendor management has to be — no longer a form you fill in at onboarding and file away, but an ongoing operational habit.

What actually happened

The ServiceNow incident centred on how third-party integrations authenticate. Many SaaS platforms let you connect other tools using OAuth, the mechanism that grants an app access to your data without you handing over a password. It is convenient and, when set up carefully, reasonably safe. The problem is that OAuth tokens are effectively long-lived keys. If an attacker gets one, they can often walk straight past MFA, because the token is the proof of identity. In the June 2026 case, exposed integration credentials meant attackers could reach data belonging to organisations that used connected apps — organisations that had done nothing wrong themselves.

Klue, a competitive-intelligence platform, showed the credential side of the same coin. A set of access credentials leaked, and because those credentials had broad permissions, the blast radius extended into customer environments. Again: the customers were not breached. Their vendor was. But the data that ended up exposed was theirs.

Strip away the branding and both stories tell you the same thing. The connections between your business and the software you rely on are themselves an attack surface. Every integration you have switched on is a door, and you are trusting the vendor on the other side to keep the key safe.

Why this hits SMEs harder

A large enterprise has a security team whose entire job is watching supplier risk. A 30-person accountancy practice in Beeston does not. It has an office manager who set up the CRM, an accountant who connected the payroll tool to the bank feed, and a director who signed off the contract because the demo looked good. Nobody wrote down which integrations were enabled, what data they could touch, or who to call if that vendor had a bad week.

That is not negligence. It is what happens when software is easy to adopt and nobody owns the aftermath. The average SME now runs dozens of SaaS tools, most connected to each other, and each connection was made by whoever needed it at the time. The result is a sprawl of trust relationships that no single person can describe.

When a vendor gets breached, the questions come fast. Which of our systems talk to them? What data did they hold? Were our credentials involved? If you cannot answer those in an afternoon, you are not managing third-party risk — you are hoping it never arrives.

OAuth and credential hygiene, in plain terms

Two ideas do most of the heavy lifting here, so it is worth being clear about them.

OAuth tokens are keys, and keys should expire and be limited. When you connect App A to App B, you often grant sweeping permissions — read everything, write everything — because that is the default and it is quicker than fiddling with scopes. A well-run vendor issues tokens that are narrow (access only what's needed) and short-lived (expire and refresh). A poorly run one issues broad, permanent tokens and never rotates them. You usually cannot see which you're dealing with from the outside, but you can ask.

Credential hygiene is the discipline of not leaving keys lying around. Hard-coding passwords into scripts, storing API keys in shared spreadsheets, reusing the same admin credential across services — these are the habits that turn a small mistake into a large breach. Your vendors have their own hygiene, and you inherit the consequences of it.

You cannot audit a vendor's internal engineering. But you can judge whether they take these things seriously by how they answer questions and how they behave when something goes wrong.

From procurement checkbox to continuous discipline

The old model treats vendor security as a moment: a questionnaire at onboarding, a tick, done. The ServiceNow and Klue incidents show why that fails. The vendor you assessed in 2024 is not the vendor you're using in 2026. They have changed staff, acquired companies, added integrations, and expanded permissions. Risk is not a snapshot; it is a moving picture.

Treating it as continuous does not mean hiring a compliance team. For an SME it means a handful of repeatable habits:

• Keep a live inventory of your vendors and what data each one holds.
• Review connected apps and their permissions on a regular cadence, not just when something breaks.
• Have a named person responsible for each critical vendor relationship.
• Know, in advance, what you'll do if a vendor announces a breach.

A practical vendor audit checklist

Use this quarterly. It is deliberately short enough that you'll actually do it.

1. List every vendor that touches your data. Not just the ones you pay directly — the integrations too. If your CRM connects to a marketing tool, both are on the list.

2. For each, record what data they can access. Customer contact details? Financial records? Employee information? Be specific. This is what determines how badly a breach would hurt.

3. Review OAuth and API connections. In each core platform, open the connected-apps or integrations settings. Look for connections you no longer use, permissions broader than needed, and tokens tied to people who have left. Revoke what you don't recognise.

4. Check credential practices on your side. Are shared logins in use? Are API keys sitting in spreadsheets or email? Are admin accounts protected with MFA and unique passwords? Fix your own hygiene before judging anyone else's.

5. Confirm each critical vendor has a breach-notification commitment. Their contract or terms should say they will tell you promptly if your data is exposed. If it doesn't, ask.

6. Assign an owner. Every vendor that could hurt you if breached needs a named person who tracks it. No owner, no oversight.

7. Write the response plan once. If Vendor X reports a breach tomorrow, who checks what data was involved, who rotates credentials, who tells affected customers? A half-page plan beats an hour of panic.

The takeaway

ServiceNow and Klue were not exotic. They were ordinary failures of key management, and their customers paid part of the bill. For a UK SME, the practical response is not fear, and it is not a bigger questionnaire. It is a shift in mindset: your suppliers' security is part of your security, and it needs the same steady attention as your own.

If you don't currently have a live vendor inventory or a plan for the morning a supplier gets breached, that's the place to start. We help Nottingham businesses map their integrations, tighten credential hygiene, and build the review habits that keep third-party risk from becoming your problem. It's a conversation worth having before the notice lands, not after.