When a vendor that holds your tokens, keys or remote access is breached, the speed of your response is set by a contract you signed years earlier, usually without a word about credentials. Most supplier agreements cover data breach notice and audit rights. Few say which of your credentials the vendor holds, how fast it must revoke them, whether it must tell you when its own infrastructure keys are stolen, or what help it owes you while you rotate. This guide sets out the clause topics that close those gaps, drawn from vendor breaches in the NHI Mgmt Group database and from NCSC, CISA and NIST supply chain guidance. It is for third-party risk, procurement, security architecture and legal teams. It describes practical clause topics, not model wording, and is not legal advice: have counsel draft and review the actual terms.
Key takeaways
- Name the credentials in the contract. A schedule of every token, key, OAuth grant and account the vendor holds or issues is the precondition for every other clause.
- Notice should trigger on credential compromise, not only on data loss. A stolen vendor API key or integration token is an incident for you before any data is confirmed taken.
- Revocation needs a time limit and a customer kill switch. The vendor should revoke on request within a defined time, and you should be able to revoke without waiting for the vendor.
- Vendor infrastructure keys are your risk too. The BeyondTrust case shows one vendor key with reach into many customer instances; require scoping and disclosure of such keys.
- Tier the clauses. Privileged access, remote access, CI/CD and SaaS integration vendors get the full set; low-risk suppliers get a proportionate subset, as NCSC guidance advises.
What the breach data shows
NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026), found supply chain to be the number one known way in (51 of the 200+ breaches analysed) and OAuth or SaaS integration the route in 15. Its lesson for the BeyondTrust and US Treasury case is that "a vendor's infrastructure keys can be keys to its customers: treat PAM and remote access vendors as tier zero." Its 90-day plan asks organisations to "treat vendors with privileged or remote access as tier-zero suppliers, and check how fast they can revoke keys." A contract is where that check becomes an obligation.
What went wrong in vendor credential breaches
| Case | Vendor-held credential | Contract gap it exposes |
|---|---|---|
| BeyondTrust Breach 2024 | A Remote Support SaaS infrastructure API key able to reset passwords for local application accounts on customer instances | No customer visibility of vendor keys with cross-customer reach. BeyondTrust detected anomalies on 2 December 2024, revoked the key on 5 December and notified the Treasury on 8 December. |
| Salesloft Drift Breach 2025 | OAuth access and refresh tokens for customers' Salesforce and Google Workspace integrations, held in Drift's AWS environment | Customer tokens stored centrally by the vendor; Google cited 700+ potentially impacted organisations and told customers to treat every connected token as compromised. |
| CircleCI Breach 2023 | Customer environment variables, tokens and keys stored in the CI platform | Customers had to rotate everything stored during the window; rotation speed depended on knowing what they had stored. |
| Okta Support System Breach 2023 | Session tokens inside HAR files customers uploaded to support cases | Escalation of customer reports: BeyondTrust raised the issue on 2 October 2023; Okta confirmed to affected customers on 19 October. |
| Cloudflare Thanksgiving Breach 2023 | Credentials Cloudflare held in its own systems, exposed after the Okta compromise | Customer-side rotation after a vendor breach was incomplete; the contract cannot fix that alone, but a credential schedule makes the scope visible. |
The common thread is that the customer learned what the vendor held, and what to rotate, during the incident rather than before it.
Clause topics for credential revocation
Each topic below is a heading counsel can draft against. The specifics in the right-hand column are starting points for negotiation, not standard market terms.
| Clause topic | What it should establish | Specifics to negotiate |
|---|---|---|
| Credential schedule | A maintained list of credentials the vendor holds for you, issues to you, or uses to reach your systems | Type, scope, owner, storage location, expiry, and update within a set number of days of any change |
| Vendor infrastructure keys | Disclosure of vendor-side keys or service accounts that can act on your tenant or instance | Their existence and scope, isolation per customer where feasible, logging of their use, short lifetimes |
| Least privilege and scope | The vendor requests only the scopes it needs and does not expand them without approval | OAuth scopes listed in the schedule; written approval for new scopes; no admin roles by default |
| Storage and protection | How the vendor stores your tokens and secrets | Encryption with keys separated from data, access restricted to named roles, no secrets in support tooling |
| Revocation on request | The vendor revokes credentials you name within a defined time | A time limit counted in hours for tier-zero vendors; confirmation with evidence |
| Customer-side kill switch | You can disable the integration or access without the vendor | Documented steps, tested at onboarding, no contractual penalty for using it in an incident |
| Rotation support | Vendor help when you rotate after its breach | Bulk revocation of tokens it issued, list of affected credentials per customer, engineering contact during the incident |
| Exit and offboarding | All credentials revoked and secrets deleted at termination | Written confirmation of revocation and deletion within a set period; covers subcontractors |
For the full vendor exit sequence, see the Vendor Offboarding and Termination Guide.
Clause topics for breach notice
NCSC principle 9 says organisations should "clearly set out requirements for managing and reporting security incidents in the contract", including timescales and who to report to. NIST SP 800-53 Rev 5 control SR-8 (Notification Agreements) and CSF 2.0 outcome GV.SC-08 (suppliers included in incident planning, response and recovery) point the same way. For credential incidents, the notice clause needs a wider trigger and more specific content than a data breach clause.
- Trigger: suspected or confirmed compromise of any credential in the schedule, of a vendor infrastructure key that can reach your tenant, or of a system storing your tokens. Do not wait for confirmed data access.
- Timing: an initial notice within a short, fixed time of the vendor becoming aware, followed by updates at agreed intervals. Where personal data is involved, align with your own regulatory deadlines; under GDPR a processor must notify the controller without undue delay, and the controller has 72 hours to notify the supervisory authority where required.
- Content: which credentials are affected (by identifier, not category), the exposure window, what the vendor has revoked, what you must rotate, and indicators of compromise such as source IPs or user agents.
- Recipients: a named security contact and an out-of-hours route, not the account manager.
- Customer reports: an obligation to acknowledge and investigate customer reports of suspected compromise within a set time, so a report like BeyondTrust's to Okta does not wait in a queue.
- Subcontractors: the same obligations flowed down, as NCSC principle 5 advises for minimum requirements.
For notification law and regulatory timelines across sectors, see the Third-Party Incident Notification Clauses Guide. For model clause wording covering the wider security relationship, use the Third-Party Security Contract Clauses Template.
Tier the clauses by vendor risk
NCSC principle 5 asks for minimum requirements that are "justified, proportionate and achievable". Apply the credential clauses by what the vendor can reach.
| Vendor tier | Examples | Clauses to require |
|---|---|---|
| Tier zero | PAM, remote access, identity providers, CI/CD platforms, managed service providers with admin rights | All topics; revocation time in hours; vendor infrastructure key disclosure; annual revocation test |
| High | SaaS integrations with OAuth access to CRM, email, code or cloud | Credential schedule, scope control, notice on credential compromise, revocation on request, kill switch |
| Medium | SaaS holding your data with API keys you issue | Credential schedule, notice, exit revocation |
| Low | No access to your systems or credentials | Standard security and breach notice terms |
How to implement
- Inventory first. List vendors with any credential, OAuth grant or remote access path into your environment. Your identity provider's app list, cloud IAM trust policies and SaaS connected-app views are the fastest sources. See the Consent Phishing and Illicit OAuth Grants Guide for OAuth grant review.
- Tier the vendors using the table above, and agree the tiering with procurement and the business owner.
- Add the clause topics to templates for new contracts, with counsel drafting the wording. NCSC principle 6 advises building security into normal contracting processes and reassessing at renewal.
- Use renewals for existing contracts. Start with tier-zero vendors. Where a vendor will not agree, record the risk and add compensating controls such as tighter scopes, IP restrictions or your own monitoring of the integration.
- Test the kill switch and revocation. At onboarding and yearly, ask the vendor to revoke a test credential and time it, and disable the integration yourself in a test tenant.
- Wire notice into incident response. Map vendor contacts and notice routes into your runbooks, and include tier-zero vendors in exercises, as GV.SC-08 expects.
Rollback is simple: if a clause proves unworkable for a vendor tier, revise the template for that tier at the next review rather than dropping the topic.
Decision guidance
- Negotiate or compensate: large SaaS providers often will not change standard terms. Then rely on their documented features (token revocation, admin controls) and your own controls, and record the residual risk.
- Customer-issued versus vendor-issued credentials: credentials you issue (API keys, service accounts) you can revoke yourself, so the schedule and exit clauses matter most. Credentials the vendor issues or stores (OAuth tokens it holds, its infrastructure keys) depend on the vendor, so revocation time and notice clauses matter most.
- Small organisations: focus on the tier-zero vendors and the credential schedule; a short schedule and a tested kill switch give most of the benefit.
- Large organisations: integrate the credential schedule with your NHI inventory so vendor credentials have an internal owner and expiry like any other NHI.
Detection and measurement
- Monitor vendor credentials as NHIs: alert on use from new locations, bulk exports and new scopes, which were the signals in the Salesloft Drift case.
- Track vendor advisories for tier-zero suppliers and treat a vendor breach announcement as an incident trigger.
- Percentage of tier-zero and high vendors with a current credential schedule.
- Percentage of those contracts with notice triggered by credential compromise.
- Measured vendor revocation time in the last test, against the contracted time.
- Percentage of high-risk integrations with a tested customer-side kill switch.
- Number of vendor credentials with no internal owner.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-05, GV.SC-07, GV.SC-08, GV.SC-10 | Requirements in contracts, ongoing supplier risk, suppliers in incident response, post-agreement provisions |
| NIST SP 800-53 Rev 5 | SR-8, SR-6, SA-4, SA-9 | Notification agreements, supplier assessments, acquisition process, external system services |
| NIST SP 800-53 Rev 5 | IA-5, AC-2, PS-7, IR-6 | Authenticator and account management for external parties, incident reporting |
| NIST SP 800-161 Rev 1 | C-SCRM practices | Supply chain risk management for products and services, including acquisition |
| NCSC supply chain principles | Principles 5, 6, 9 | Minimum requirements, contracting process and exit, incident reporting in contracts |
| MITRE ATT&CK v20 | T1199, T1528 | Trusted relationship abuse and stolen application access tokens |
Common failure patterns
- Notice tied only to personal data: a stolen integration token, as in the Salesloft Drift Breach 2025, may not trigger it until data theft is confirmed.
- No visibility of vendor infrastructure keys: the BeyondTrust Breach 2024 key could act on customer instances.
- No credential schedule: after the CircleCI Breach 2023, customers needed to know everything they had stored to rotate it.
- Customer reports with no response duty: the Okta Support System Breach 2023 timeline shows the cost.
- Exit without revocation evidence: tokens outlive the contract.
Practitioner checklist
- List every vendor with a credential or access path into your environment.
- Tier vendors by what they can reach.
- Require a maintained credential schedule from tier-zero and high vendors.
- Make credential compromise a notice trigger, with identifiers and an exposure window in the notice.
- Set a revocation-on-request time and test it.
- Document and test a customer-side kill switch for each high-risk integration.
- Require disclosure and scoping of vendor keys that can act on your tenant.
- Require revocation and deletion evidence at exit.
- Have counsel draft and review all wording.
Standards and references
- NCSC: Supply chain security guidance, Establish control
- NCSC: Supply chain security guidance, Understand the risks
- NIST: SP 800-161 Rev 1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CISA: Software Acquisition Guide for Government Enterprise Consumers
- NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
Related NHI Mgmt Group resources: Third-Party Security Contract Clauses Template, Third-Party Incident Notification Clauses Guide, Vendor Offboarding and Termination Guide, Third-Party Risk Management Guide. This guide describes contract topics and is not legal advice.