Top 10 Third-Party Risk Mistakes

Third-party risk programmes often measure what suppliers say about themselves while missing the access those suppliers actually hold. Recent supply chain breaches did not start with a failed questionnaire: they started with OAuth tokens, API keys and partner logins that nobody had inventoried, scoped or revoked. This list covers the ten mistakes that recur in those incidents and in regulatory findings, with a linked case from the NHI Mgmt Group breach database where one fits and a practical fix for each. It is written for TPRM, GRC and security teams. For building a programme, see the Third-Party Risk Management Guide; this page focuses on what goes wrong.

The Top 10 at a glance

The mapping column uses the NIST CSF 2.0 supply chain risk management category (GV.SC), which sits under the Govern function, plus related subcategories elsewhere in the framework.

1. Questionnaire-only assessment

The mistake: approving a vendor because it returned a completed questionnaire and a SOC 2 report, without checking the answers against the service actually being bought.

Why it matters: a questionnaire records claims at a point in time. It rarely asks how the vendor stores the tokens it holds for you, or whether the report's scope covers the product you use.

The fix: verify the high-risk answers with evidence (report scope, bridge letters, architecture of the integration, how customer credentials are stored and rotated) and assess critical suppliers before contract signature (ID.RA-10, SR-6). See the Security Questionnaires Guide and the Vendor Security Assessment Template.

2. No inventory of SaaS integrations and OAuth tokens

The mistake: the vendor register lists contracts, but not the connected apps, API keys and OAuth grants each vendor holds in your tenants. Teams and users connect integrations without procurement.

Evidence: in the Salesloft Drift breach, Google Threat Intelligence reported that stolen Drift OAuth tokens were used between 8 and 18 August 2025 to export Salesforce data, which the actor then searched for AWS access keys, passwords and Snowflake tokens. The Klue OAuth breach involved a forgotten integration credential.

The fix: link each vendor record to the identities it holds: connected apps, service accounts, API keys and their scopes and owners (ID.AM-04). Discover integrations from identity provider and SaaS admin consoles, not only from purchase orders. See the SaaS and OAuth App Governance Guide.

3. Over-scoped, long-lived integration credentials

The mistake: granting the broadest scope a vendor asks for, with refresh tokens that never expire and no IP restriction.

Evidence: the Gainsight Salesforce breach involved 285 long-lived OAuth tokens. After Drift, Google's guidance included restricting connected app scopes and avoiding full access, setting IP Relaxation to "Enforce IP restrictions" and removing "API Enabled" from profiles.

The fix: least-privilege scopes, token lifetimes and IP allowlists written into onboarding, with a named internal owner per integration. Attackers abuse these tokens through techniques such as Steal Application Access Token (T1528) and Application Access Token (T1550.001).

4. Tiering by spend, not by access

The mistake: deep assessment for large contracts while a cheap SaaS tool with write access to your CRM gets a light-touch review.

The fix: tier by data sensitivity, privilege and operational dependency (GV.SC-04). A free browser extension or AI plugin with tenant-wide consent can belong in the top tier. See the Third-Party AI Risk Guide.

5. Assess once, never monitor

The mistake: annual reassessment at best, with no signal between reviews when a vendor is breached, acquired or changes subprocessors.

The fix: monitor provider activity in your own logs (DE.CM-06): unusual API volumes, new IP ranges or user agents from connected apps. Add breach news and security ratings as triggers for reassessment rather than as a substitute for it. See the TPRM and Security Ratings Buyer's Guide.

6. Weak contract clauses

The mistake: contracts with no defined breach notification time, no audit right and no obligation to share logs or help during an incident.

Why it matters: DORA's recitals expect contracts with ICT providers to cover data location, access, recovery and return (including on insolvency), assistance during ICT incidents, and rights of access, inspection and audit.

The fix: a standard security schedule covering notification within a fixed number of hours (SR-8), log access, subprocessor disclosure, credential handling and audit rights (GV.SC-05). See the DORA Guide.

7. Ignoring fourth parties and concentration

The mistake: assessing the vendor but not the identity, cloud and support platforms it depends on, and not noticing that many critical vendors share one provider.

Evidence: the Snowflake breach reached 165 customer environments through credentials without MFA, and the Okta support system breach exposed 134 customers, one of which, Cloudflare, was later breached through credentials it had not rotated.

The fix: ask critical vendors for their own critical suppliers, map shared dependencies, and plan for one of them failing. DORA's recitals call for concentration risk analysis that includes subcontracting. See the Third-Party Concentration Risk Guide.

8. Uncontrolled partner and support access

The mistake: vendor engineers and outsourced help desks with shared or standing accounts, weak identity verification and no session monitoring.

Evidence: the Marks and Spencer cyberattack involved impersonation of a third-party user; the Scania breach used an IT partner's infostealer-stolen login; the BeyondTrust breach began with a stolen API key and led to an incident at the US Treasury. ATT&CK tracks this route as Trusted Relationship (T1199).

The fix: named, MFA-protected accounts for every external person, just-in-time privileged access, recorded sessions and help desk verification that cannot be talked around (AC-20, PS-7). See the Third-Party Access Guide.

9. Suppliers outside incident response

The mistake: when a vendor announces a breach, nobody knows which integrations, tokens and data are affected, so revocation takes days.

The fix: include critical suppliers in incident planning and exercises (GV.SC-08) and keep a vendor-breach runbook: identify every credential the vendor holds, revoke and rotate, then hunt in logs. NIST SP 800-61 Rev. 3 notes that providers may hold privileged access and that contracts should define responsibilities and information flows. See the Identity Incident Response Playbook.

10. No exit plan or offboarding

The mistake: contracts end but connected apps, API keys and vendor accounts stay live, and nobody has planned how to move a critical service elsewhere.

The fix: CSF 2.0 GV.SC-10 asks for provisions covering activities after a relationship ends. Revoke every credential at termination and confirm data return or deletion. For critical services, DORA's recitals expect dedicated exit strategies with mandatory transition periods. See the Cloud Concentration Risk and Exit Strategy Guide and the NHI Offboarding and Decommissioning Guide.

Mapping to NIST CSF 2.0, SP 800-53 and SP 800-161

NIST SP 800-161 Rev. 1 (Update 1, November 2024) is NIST's detailed cybersecurity supply chain risk management (C-SCRM) guidance and works alongside the SR control family below. The NCSC's supply chain security principles group the same work into four stages: understand the risks, establish control, check your arrangements and continuous improvement.

Where to start

If you can fix only three things this quarter, build the integration inventory that links every vendor to the tokens and accounts it holds (mistake 2), cut scopes and lifetimes on the integrations touching your most sensitive data (mistake 3), and write a vendor-breach runbook that revokes a vendor's access in hours (mistake 9). Useful measures: share of top-tier vendors with a mapped credential inventory, number of integrations with full or admin scope, time to revoke all access for a named vendor in an exercise, and credentials still live for terminated vendors (target zero).

Related NHI Mgmt Group resources: Third-Party Risk Management Guide · Vendor Security Assessment Template · Top 10 SaaS Security Risks · Top 10 Supply Chain Attacks