When Your IT Vendor Gets Breached: A Client's Playbook

In July, news broke that attackers had made off with a haul of technical assets tied to Accenture — Azure tokens, SSH keys, RSA private keys, and configuration files. If your reaction was to shrug because you don't buy anything from Accenture, hold on. The lesson here has almost nothing to do with the name on the front door and everything to do with what was stolen.

Azure tokens, SSH keys, config files. Read that list again and think about what it lets someone do. These aren't customer records that end up on a leak forum for the curious to gawp at. They're the keys and maps that let an attacker walk straight into connected environments — including, potentially, yours. When a supplier holds credentials that touch your systems, their breach becomes your problem the moment those credentials are stolen. The gap between 'they got breached' and 'we got breached' can be measured in hours.

So let's treat a supplier breach the way it deserves to be treated: as your incident. Here is the playbook we run through with Cloudworks clients, and one you can adapt whether the breached vendor is a big-name consultancy or a small SaaS tool you signed up for two years ago and half-forgot about.

First, work out whether you're actually exposed

Before you rotate a single credential, map the relationship. Not every supplier breach touches you, and burning a weekend rotating keys that were never shared helps nobody.

Ask three questions:

• Does this vendor hold credentials into our environment? Think API keys, service accounts, VPN access, admin logins to your Microsoft 365 or Azure tenant.
• Do we hold credentials into theirs? Integrations often run both ways. If you've got a stored token that authenticates to their platform, that token may now be at risk too.
• Is there a shared third party? Your vendor's suppliers can be your problem as well. This is where the chain gets long and uncomfortable.

Write down what you find. You'll want the list anyway when you brief the board or, if it comes to it, the ICO.

Rotate credentials — all of them, not the convenient ones

If there's any credential shared with or held by the breached vendor, assume it's compromised. Don't wait for confirmation that your specific key was in the stolen set. By the time that confirmation arrives, if it ever does, an attacker has had days to use it.

Rotate in this rough order of blast radius:

1. Standing admin and service accounts. These are the crown jewels. A service account with global admin over your Microsoft 365 tenant, shared with a supplier for management purposes, is the single most dangerous thing on your list.
2. API keys and integration secrets. Anything a vendor uses to pull or push data. Regenerate the key, update the integration, confirm it still works, then invalidate the old one.
3. SSH keys. If a vendor had SSH access to your servers, remove their public keys from authorized_keys and issue fresh ones. Don't just add new keys — take the old ones out.
4. Shared passwords. Yes, they still exist in the wild. Any credential stored in a shared vault or, worse, a spreadsheet, needs changing.

A note on process: rotating credentials in a panic breaks things. Sequence the work so a failed rotation doesn't lock you out of the system you're trying to protect. Test in a way that lets you roll back.

Revoke tokens, because rotation isn't enough

Here's the trap. You change a password, feel reassured, and miss the fact that an OAuth token or session token issued before the change is still valid. Tokens are the part everyone forgets, and the Accenture haul reportedly included Azure tokens specifically.

In a Microsoft environment, that means:

• Revoke refresh tokens for any account tied to the vendor. In Entra ID you can revoke sessions per user, which forces re-authentication everywhere.
• Review app registrations and enterprise applications the vendor may have consented to. Look for anything with broad permissions — mail read/write, directory access, file access — and pull consent for anything you can't justify.
• Check for lingering service principals the vendor created. These sit outside normal user accounts and are easy to overlook.

Do the equivalent in AWS, Google Workspace, or whatever else you run. The principle holds everywhere: a stolen token can outlive the password it was born from, so you have to kill both.

Review your SBOM and dependency chain

A breach that yields config files and source-related material is a reminder to know what's actually inside your software. This is where a Software Bill of Materials — an SBOM — earns its keep.

An SBOM is simply an inventory of the components, libraries, and dependencies your applications rely on. If you have one, now is the moment to check whether anything from or connected to the breached vendor appears in it. If you don't have one, this incident is your reason to start.

For a typical SME, you're not building this from scratch by hand. Tools that scan your codebases and container images will generate a component list for you. What matters is the habit: knowing your dependencies means that next time a supplier is compromised, you can answer 'are we affected?' in minutes rather than guessing for a week.

Watch for the pivot

Stolen credentials get used. After rotation and revocation, turn your attention to detection, because the window between the breach and your response is exactly when an attacker would have moved.

Go back through your logs:

• Sign-in logs for the affected accounts — unfamiliar locations, impossible-travel alerts, sign-ins at odd hours.
• New inbox rules, especially ones that auto-forward or delete. A classic sign someone's been in an email account.
• Unexpected admin actions: new users created, permissions granted, MFA methods added.
• Data egress that doesn't fit normal patterns.

If you spot something, you're no longer doing precautionary hygiene — you're running a live incident, and you should escalate accordingly.

Then have the awkward conversation with the vendor

Once your own house is secure, press the supplier for specifics. What data was taken? Were credentials relating to your account included? What's their remediation timeline? A vendor worth keeping will answer plainly. Vague reassurance is itself a data point about whether you should stay.

The real lesson

Supplier breaches are not rare events you can treat as someone else's news story. Every integration you run, every vendor with access to your systems, is a door into your environment that someone else holds a key to. The Accenture incident is useful precisely because the stolen assets were so ordinary — tokens, keys, config — the same things half your suppliers hold about you right now.

Build the map before you need it. Keep an inventory of who has access to what, keep an SBOM current, and rehearse the rotate-revoke-review sequence so it's muscle memory rather than a scramble. If that feels like more than your team can carry, it's exactly the kind of work we handle for Nottingham SMEs day to day. Either way, the takeaway stands: when your vendor gets breached, the clock starts for you too.