Vendor Breach Response: 72 Hour NHI Playbook

When a supplier announces a breach, the credentials you gave it, and the tokens it holds on your behalf, are now in an unknown number of hands, and only you can revoke them. Vendor notices tend to arrive late, say little and focus on the vendor's own systems, not on the API keys, OAuth grants, service accounts and webhook secrets that connect it to your estate. This guide is a customer-side response plan for the first 72 hours, hour by hour, centred on those non-human identities (NHIs). It is written for incident responders, identity and cloud engineers, and third-party risk leads, and it applies whether the vendor is a SaaS platform, a software or build tool, a managed service provider or a remote access supplier. It goes deeper than the general Third-Party Incident Response Playbook template and does not name or judge any vendor's incident: the steps are the same whoever the supplier is.

Key takeaways

Supply chain is now the most common known way in. In NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026), 51 of the 200+ breaches analysed came through a poisoned package, build tool or CI pipeline, and supply chain attacks made up 38% of 2026 breaches.
Assume every credential the vendor could see is exposed. Do not wait for the vendor to confirm scope: revoke and reissue on your side, then narrow down as facts arrive.
Revoke completely, then prove it. A rotation that misses one token, refresh token or old key version leaves the door open; verify with your own logs, not with the vendor's statement.
The 72 hour clock may be a legal one. GDPR Article 33 and NIS2 Article 23 both set 72 hour outer limits that can start when you become aware, not when the vendor finishes its investigation.
Inventory decides the speed. Teams that already know every integration, its owner, scopes and expiry finish containment in hours; teams that do not spend the first day searching.

Why vendor breaches become your NHI incident

A supplier with access to your environment almost always holds a non-human credential, not a person's login. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026, counts secrets and passwords as the most exploited identity type (84 breaches) and found that 56% of breaches involved more than one kind of non-human identity: one leaked key is used to find the next. OAuth and SaaS integrations were the route in 15 breaches, and 79% of 2026 AI-related breaches also abused a key, token or credential. In ATT&CK terms, the attacker is using T1199 Trusted Relationship or T1195 Supply Chain Compromise to get in, then T1528 Steal Application Access Token and T1550.001 Application Access Token to move into your tenant with identities you approved.

Vendor type	Credentials it typically holds for you	What an attacker can do with them
SaaS application with integrations	OAuth access and refresh tokens, API keys into your CRM, mail or storage	Bulk data export through legitimate APIs
CI/CD, build or developer tool	Repository tokens, deploy keys, cloud credentials, package publishing tokens	Source theft, poisoned builds, cloud access
Managed service or remote access provider	Privileged service accounts, remote support keys, VPN or PAM access	Hands-on access to servers and directories
Data, analytics or AI platform	Database service accounts, warehouse keys, cloud role trust, AI API keys	Data theft, model or agent misuse
Monitoring and security tooling	Read-wide cloud roles, agent enrolment secrets, log pipeline keys	Wide visibility of your estate, tampering with telemetry

Hours 0 to 4: confirm, convene and freeze the picture

The trigger can be a vendor email, a status page update, a regulator or press report, a threat intelligence alert or your own detection. Treat a credible public report as a trigger: do not wait for a formal notice.

Declare and assign. Open an incident, name an incident lead, an identity lead, the integration owner(s), legal or privacy, and a vendor liaison. Use your Incident Response Contact and Call Tree Template.
Find every touchpoint. Pull the vendor's entry from your supplier register and your NHI inventory: OAuth app registrations and consented grants, API keys issued to or by the vendor, service accounts, IP allow-lists, SSO or SCIM connections, webhook endpoints, cloud cross-account roles and any secrets you uploaded into the vendor's product.
Preserve evidence before you change anything. Export audit logs from your identity provider, cloud control plane, SaaS admin consoles and the vendor's own customer-facing audit log while the data still exists. Default retention in many SaaS tiers is short; see the SaaS Audit Log Retention and Licensing Guide.
Start the notification clock record. Write down when you became aware and what you knew. Legal deadlines can run from this time.

Triage questions for the first call with the vendor

Ask in writing and record the answers with a timestamp. Vendors often cannot answer everything on day one, so ask again at every update.

Scope: Which systems were accessed, and did they hold customer credentials, tokens, secrets or customer data? Is our tenant named in their evidence?
Window: First and last known attacker activity, and whether the attacker still has access.
Credential types: Were OAuth refresh tokens, API keys, signing keys, SSH keys or stored customer secrets in the affected store? Were they encrypted, and was the key also exposed?
Vendor-side actions: What has the vendor already revoked (for example, all OAuth tokens for an integration) and what must customers do themselves?
Indicators: IP addresses, user agents, API client IDs and time ranges you can search for in your own logs.
Contract: Who is the named security contact, and how will updates reach you? Your contract's notification clause applies here; see the Third-Party Incident Notification Clauses Guide.

Hours 4 to 24: contain by priority

Contain from the highest blast radius down. Revoke on your side even if the vendor says it has rotated: you control your own identity provider and cloud accounts, and the vendor does not.

Priority	Credential	Containment action	Check that it worked
1	Privileged service accounts, remote access and PAM entries used by the vendor	Disable or reset; cut network paths and allow-list entries; require re-approval for any session	No authentications from the account after the change
2	Cloud cross-account roles and access keys	Remove the trust or add a deny condition; deactivate, then delete, keys	Control plane logs show no calls with the old role or key
3	OAuth grants and refresh tokens	Revoke the grant at your identity provider or SaaS admin console, not only the access token; review scopes before re-consent	Token use stops; no new token issuance for the client ID
4	API keys and personal access tokens issued to the vendor	Revoke and reissue with narrower scope and an expiry	Old key returns errors in your API gateway logs
5	Secrets you stored inside the vendor product	Rotate at the source system (database, cloud, payment provider), not in the vendor	Source system shows the old secret rejected
6	Webhook signing secrets, SSO and SCIM tokens	Rotate; confirm signature validation is enforced on your side	Unsigned or old-signature calls are rejected

Disable or delete: disable first where the business can tolerate it, so you keep the object for investigation; delete after evidence is captured. Break or keep the integration: if the vendor's core service is still trusted, reissue narrower credentials; if the vendor's control plane itself was compromised, keep the integration off until the vendor confirms remediation in writing. For OAuth specifics, follow the OAuth Token Theft Incident Playbook; for cloud keys, the Cloud Access Key Leak Playbook.

Hours 24 to 48: hunt for use of what was exposed

Containment stops new use; hunting finds use that already happened. Search the period from the vendor's earliest known attacker activity (or 30 days before, if unknown) to now.

Identity provider: sign-ins and token issuance for the vendor's client IDs and service principals from unfamiliar IP ranges, new consent grants, new credentials added to app registrations.
Cloud: API calls by the vendor's roles or keys outside their normal set, especially listing, snapshot, export and IAM changes such as new users, keys or role trust edits.
SaaS data access: bulk exports, report downloads and API query volume spikes for the integration user.
Code and pipelines: new deploy keys, workflow changes, unexpected package versions published with your tokens.
Chained credentials: any secret that the exposed identity could read. If the vendor's account could read a vault path, a ticket queue or a storage bucket containing more secrets, those are exposed too. The report's finding that most breaches involve more than one NHI type is the reason to follow the chain.

The SaaS Forensics guide covers which logs each major SaaS category exposes. Use the vendor's indicators as a starting point, but baseline the integration's normal behaviour and look for any deviation, because vendor indicators are often incomplete early on.

Hours 48 to 72: notify, recover and decide

Notification triggers

Rule	Who it applies to	Deadline as published
GDPR Article 33(1)	Controllers, for personal data breaches	Without undue delay and, where feasible, not later than 72 hours after becoming aware; reasons required if late
GDPR Article 33(2)	Processors (often the vendor)	Notify the controller without undue delay after becoming aware
NIS2 Article 23(4)	Essential and important entities, significant incidents	Early warning within 24 hours, incident notification within 72 hours, final report within one month of the notification
SEC Form 8-K Item 1.05	US public companies, material incidents	Generally four business days after determining materiality

A vendor breach can be your personal data breach if the vendor processed personal data for you, and it can be your significant incident under NIS2 if it disrupts your service. Legal and privacy decide; the incident team supplies facts and timestamps. Check sector rules and national transpositions too.

Recovery

Re-enable the integration only with new credentials that are scoped to the minimum, short-lived where the vendor supports it, and owned by a named person.
Prefer federation over stored secrets: workload identity, OIDC trust or an OAuth client with certificate or private key authentication instead of a long-lived shared key, where the vendor offers it.
Add detections for the integration's new baseline so misuse of the reissued credentials alerts quickly.
Record the decision to keep, restrict or exit the vendor, with the evidence, and feed it to third-party risk. If you exit, follow the Vendor Offboarding and Termination Guide.

Evidence to preserve

The vendor's notices, status page snapshots and every written answer, with timestamps.
Identity provider, cloud, SaaS and API gateway logs for the full window, exported to storage you control with integrity protection.
Before and after copies of the integration's configuration: scopes, roles, allow-lists, app registrations.
The list of every credential revoked or rotated, when, by whom, and the verification result.
The awareness timestamp and every notification decision with its reasoning.

Detection and measurement

Metric	What it shows	Target to aim for
Time from awareness to full touchpoint list	Inventory quality	Under 4 hours
Time from awareness to last credential revoked	Containment speed	Under 24 hours for priority 1 to 3
Percentage of revocations verified in logs	Completeness, not just action	100%
Vendor integrations with a named owner, scopes and expiry recorded	Readiness for the next one	100% of tier 1 vendors
Long-lived vendor credentials replaced by federation or short-lived tokens	Reduced blast radius	Rising each quarter

The targets are practitioner suggestions, not regulatory values: set your own and test them in a tabletop exercise each year.

Common failure patterns

Waiting for the vendor's scope statement. Days pass while exposed tokens stay valid. Revoke first; restore narrower access later.
Revoking access tokens but not refresh tokens or grants. The attacker simply mints new access tokens. Revoke the grant or the client credential.
Rotating in the vendor, not at the source. A database password changed in the vendor's UI is still the old password in the database if the source was not changed, or the reverse.
Missing one copy. The same key sits in a second integration, a CI variable or a ticket. Search your secret scanners for the old value. The Incomplete rotation breaches guide shows how often a partial rotation is what lets an attacker back in.
Losing the logs. SaaS audit logs aged out before anyone exported them, so use cannot be ruled in or out.
No owner for the integration. Nobody knows what breaks if the token is revoked, so nobody revokes it.

Framework mapping

Framework	Reference	How this playbook meets it
NIST CSF 2.0	GV.SC-08	Suppliers included in incident planning, response and recovery
NIST CSF 2.0	RS.MA-01, RS.AN-03, RS.CO-02, RC.RP-01	Coordinated response with third parties, root cause analysis, stakeholder notification, recovery execution
NIST SP 800-53 Rev 5	IR-4, IR-6, SR-8	Incident handling, incident reporting, supplier notification agreements
NIST SP 800-53 Rev 5	AC-2, IA-5	Account management and authenticator management for vendor NHIs
MITRE ATT&CK	T1199, T1195, T1528, T1550.001	Techniques the hunting steps look for
NIST SP 800-61 Rev 3	CSF 2.0 Community Profile	Places incident response inside overall cyber risk management

Where identity fits

Every step above depends on knowing which non-human identities connect you to the vendor. Build that list before the next notice: each integration with its owner, credential type, scopes, storage location and expiry. The NHI Inventory Reconciliation guide covers how to keep it accurate, and the third-party NHI due diligence questions guide covers what to ask a vendor before you connect it, including how fast it can revoke keys.

Practitioner checklist

Keep a per-vendor list of every NHI touchpoint, with owner, scopes and expiry, for all tier 1 suppliers.
Confirm you can export each critical SaaS audit log today, and know its retention period.
Write a one-page revocation runbook per tier 1 integration: where to revoke, what breaks, who approves.
Record the awareness timestamp at the start of every vendor incident.
Revoke grants and refresh tokens, not only access tokens, and rotate stored secrets at their source.
Verify every revocation in your own logs and keep the evidence.
Hunt for use of exposed credentials and for any secrets those credentials could read.
Replace long-lived vendor keys with federation or short-lived scoped credentials during recovery.
Run a vendor breach tabletop yearly and measure time to full touchpoint list and time to last revocation.

Your vendor was breached: a 72 hour NHI response playbook