Third-party NHI due diligence questions drawn from real breaches: Ask Vendors What Actually Failed Before

Most supplier questionnaires ask how a vendor protects your users, and almost none ask how it protects the machine credentials that reach your data. In the vendor breaches below, the failure sat in the supplier's own non-human identities: a GitHub account, a forgotten personal access token, a multi-tenant app secret, a support service account, a signing key. This guide turns those failures into due diligence questions, each with the evidence to request and the answer that should worry you. It is for third-party risk, identity and procurement security practitioners who want a short, breach-tested NHI section to add to existing questionnaires, not a replacement for them.

Key takeaways

• Ask about the vendor's NHIs, not only yours. In Salesloft Drift, Klue and Sisense, the root credential belonged to the vendor and sat in source control or its cloud environment.
• Customer tokens held by a vendor are your credentials in someone else's vault. Ask where they are stored, how they are encrypted and isolated, and how fast they can all be revoked.
• Token age is a due diligence question. Gainsight's 285 stolen OAuth tokens were 2 to 8 years old and only about 23% still existed in its systems.
• Request evidence, not attestations. A measured rotation time, a recent inventory extract or a redacted runbook says more than a yes.
• Ask fewer, sharper questions by tier. Twelve questions for vendors that hold tokens to your data beat a hundred generic ones sent to everyone.

Why NHI questions need their own section

NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) finds supply chain the leading known route in, with 51 of the 200+ breaches analysed, and 24 breaches combining supply chain with a source control token. It also finds that 56% of breaches involved more than one kind of non-human identity: "One leaked key rarely stays one key." Standard questionnaires cover MFA, SSO and encryption at rest. None of those would have stopped an attacker using a vendor's valid integration token, because no user signs in. The Third-Party Risk Management Guide covers the full due diligence lifecycle and the Security Questionnaires Guide covers questionnaire design; this page supplies the NHI questions that slot into both.

Where vendor NHI failures happened

The question bank

Each question lists the evidence to request and the red flag. Ask the first two groups of every vendor that holds tokens to your systems; add the rest by service type.

A. Inventory and ownership of the vendor's own NHIs

• Q1. Do you keep an inventory of service accounts, API keys, tokens and app credentials with access to production and customer data, with an owner and last-used date for each? Evidence: a redacted extract and the date it was last reconciled. Red flag: no last-used data, which is how Cloudflare wrongly judged four credentials unused (see the Cloudflare Thanksgiving breach).
• Q2. How do you revoke credentials issued to your own contractors, pilots and suppliers when the engagement ends? Evidence: the offboarding procedure and one completed example. Red flag: tokens tied to individuals or projects with no expiry, as in Klue.

B. Customer tokens you hold

• Q3. Where are our OAuth tokens, API keys and connector credentials stored, and how are they encrypted and isolated per customer? Evidence: architecture description naming the vault or key management service. Red flag: shared buckets or databases for all customers' tokens, as reported at Sisense.
• Q4. What is the lifetime of the refresh tokens and keys you hold for us, and do you delete them when an integration is disabled? Evidence: configured expiry and the deletion process. Red flag: tokens valid until revoked with no reconciliation, as at Gainsight.
• Q5. Can you revoke every token you hold for us, on request, and how long does it take? Evidence: a measured time from a test or past incident. JumpCloud force-rotated all customer admin API keys in one day. Red flag: "we would contact the platform".
• Q6. Do you publish the IP ranges your integration calls from, so we can restrict it? Evidence: the published list. Red flag: calls from arbitrary cloud ranges, which removes a cheap detection and containment control.

C. Source control and build

• Q7. How are your GitHub or GitLab organisations protected, and which tokens can change code that handles customer credentials? Evidence: SSO and phishing-resistant MFA enforcement, token policy, secret scanning on push. Red flag: personal access tokens with organisation-wide write and no expiry.
• Q8. Do you scan repositories, CI logs, images and tickets for secrets, and what happens to a finding? Evidence: tooling and the rotation SLA. Red flag: findings closed by deleting the line without rotating the secret.

D. Multi-tenant apps and cross-customer keys

• Q9. Which credentials can act on more than one customer, and what can each do? Evidence: a list with scopes. Red flag: a single key able to reset passwords or sign in to many tenants, the BeyondTrust and ConnectWise pattern.
• Q10. Does your multi-tenant app authenticate with a client secret, a certificate or federation, and how is it rotated and monitored? Evidence: credential type, rotation interval, alerting on use from unknown infrastructure. Red flag: long-lived shared client secrets.
• Q11. Which application permissions does your app request, and why does it need each one? Evidence: a permission-by-permission justification. Red flag: directory write or role management rights for a data service.

E. Support, signing and notification

• Q12. How do you handle HAR files, logs and screenshots customers upload, and do you strip session tokens? Evidence: sanitisation process. Red flag: raw uploads visible to all support staff.
• Q13. Where are code signing keys held, and how would you tell customers which releases to distrust? Evidence: HSM or managed signing service; a revocation runbook. Red flag: signing keys on build servers.
• Q14. Within what time will you tell us if a credential that reaches our systems is suspected exposed, and will you tell us which of our tokens were affected? Evidence: the contract clause and named contact. Red flag: a status page as the only channel.

Matching questions to vendor tier

Use the Vendor Tiering and Inherent Risk Questionnaire Template to set the tier. Vendors with privileged or remote access deserve the strictest handling; see the guide on remote access and PAM vendors as tier-zero suppliers in this series and the Vendor Privileged Access Management (VPAM) Guide.

Putting the bank into practice

1. Find the vendors that hold credentials: pull connected apps, enterprise applications, integration users and API keys from your SaaS and cloud platforms and map each to a supplier. The report's 30-day plan starts here: list every third-party OAuth grant and SaaS integration and revoke what is unused, unowned or over-scoped.
2. Tier them using the table above.
3. Pilot the questions on three to five vendors, including one you trust and one you do not, to calibrate what good evidence looks like.
4. Score: mark each answer as evidenced, stated without evidence, or red flag. Two or more red flags in groups B or D go to the risk owner for a documented decision.
5. Turn answers into contract terms at renewal: token lifetime, revocation time, notification window, IP ranges. Use the Third-Party Security Contract Clauses Template.
6. Compensate where answers are weak: narrow scopes, IP restrictions where supported, and integration monitoring on your side.
7. Re-ask after any incident at that vendor or a peer with a similar architecture.

Decision guidance

• Weak answers, critical vendor: do not just accept the risk. Reduce what the vendor's token can do, and on Microsoft Entra note that Conditional Access for workload identities applies only to single-tenant service principals registered in your tenant, so for a vendor's multitenant app your levers are permission reduction and sign-in monitoring.
• Certification offered in place of answers: a SOC 2 or ISO 27001 report helps, but check whether its scope covers source control and the systems that store customer tokens. See How to Read a SOC 2 Report Guide.
• Small organisations: ask questions 3, 4, 5 and 14 of every vendor holding tokens. They cover where the tokens are, how long they live, how fast they die and when you will hear.

Detection and measurement

Due diligence is a point-in-time view; pair it with monitoring of what vendor identities actually do, such as integration sign-ins from addresses outside published ranges and bulk exports by integration users.

Common failure patterns

• Accepting "we follow best practice": no evidence, no assurance.
• Asking only about your accounts: MFA and SSO answers say nothing about the vendor's GitHub tokens.
• One-time assessment: Klue's credential was created years before it was abused.
• Sending the full bank to everyone: vendors answer generically and the critical ones get no deeper review.
• No link to contracts: good answers that are not written into the agreement can change without notice.

Framework mapping

Practitioner checklist

• Map every vendor that holds tokens, keys or app credentials to your systems.
• Tier them by what their credentials can do.
• Add the NHI question bank to the questionnaire for the top two tiers.
• Require evidence for every answer in groups B and D.
• Escalate red flags to a named risk owner with a documented decision.
• Write token lifetime, revocation time and notification terms into renewals.
• Compensate weak answers with narrower scopes and your own monitoring.
• Re-ask after any incident at the vendor or a similar vendor.

Standards and references

• NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• OWASP: Non-Human Identities Top 10
• Microsoft Learn: Conditional Access for workload identities
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: Trusted Relationship (T1199)

Related NHI Mgmt Group resources: Third-Party Access Guide · SaaS and OAuth App Governance Guide · Vendor SaaS Breach Response Playbook · Vendor Offboarding and Termination Guide