TL;DR: Questionnaires and security ratings still leave third-party risk teams with point-in-time, context-poor signals, because vendor scale, service criticality and rapid posture changes make static scoring and black-box grades unreliable for deciding which suppliers matter most, according to Black Kite.
At a glance
What this is: This is a critique of traditional third-party risk management and security ratings, which says static questionnaires and scores do not capture vendor context or current exposure.
Why it matters: It matters because IAM, NHI and security teams increasingly depend on third parties, SaaS links and outsourced operations, so governance has to reflect real service criticality and changing access paths.
Context
Traditional third-party risk management was built for a slower vendor landscape, when questionnaires and periodic reviews could approximate ongoing oversight. That model struggles when suppliers change quickly, service dependencies multiply, and access paths now include software integrations, API tokens and other third-party risk management relationships that can expand blast radius far beyond the contract owner.
Security ratings promised a simpler answer by compressing vendor posture into a score, but risk does not behave like a static grade. The same score can mean very different things depending on the service, the data it touches and how quickly the vendor’s environment changes, which makes context a governance requirement rather than an extra detail.
Key questions
Q: Why do questionnaires and security ratings fail as the main way to manage third-party risk?
A: They fail because they capture posture at a point in time, not the operational context that determines actual exposure. A vendor score can hide service criticality, data sensitivity and changing integrations, so teams end up comparing grades instead of governing real dependency risk. The better approach is to combine evidence with service context and live monitoring.
Q: How should security teams prioritise vendors when scores look similar?
A: Prioritise by business impact, access scope and the sensitivity of the data or systems the supplier can reach. Two vendors with the same score can carry very different consequences if one supports a critical workflow and the other only a low-impact service. Risk ranking should reflect blast radius, not just the score itself.
Q: What are the signs that a third-party risk program is too static to detect emerging vendor risk?
A: A third-party risk program is too static when it relies mainly on onboarding questionnaires, compliance certificates, or periodic point-in-time reviews. Those methods miss changes in security posture, new exposures, and incidents that emerge after approval. Better signals come from continuous monitoring, recurring reassessment, and incident reporting, which reveal whether the vendor’s risk profile has changed since the last review.
Q: How do identity teams govern supplier access without over-relying on procurement reviews?
A: They inventory all supplier identities, tokens and delegated permissions, then make offboarding, scope changes and exception handling part of access governance. Once third parties can act through non-human credentials, procurement approval alone is not enough to control risk.
Technical breakdown
Why questionnaires stop being useful at scale
Questionnaires were designed to collect control evidence from vendors at a moment in time, not to model live exposure. As vendor counts rise into the hundreds or thousands, the review burden grows faster than the signal quality. The result is operational fatigue: teams spend time chasing responses, while the actual question they need answered, which suppliers can affect sensitive data or critical operations right now, remains unresolved. In modern supply chains, point-in-time attestations do not capture short-lived changes in integrations, ownership or access scope.
Practical implication: Treat questionnaires as supporting evidence, not as the primary control for vendor risk decisions.
Why security ratings fail without service context
Security rating services reduce a vendor’s posture to a numeric or letter grade, but a grade is not a risk model. Two vendors with the same score can present radically different business exposure depending on what they do for you, which systems they can reach and how much operational dependency exists. Black-box scoring also creates governance friction because teams cannot test whether the methodology reflects their own risk tolerance. A score without service context can mislead prioritisation more than it informs it.
Practical implication: Use ratings only as triage input, then re-rank vendors by service criticality, data sensitivity and access scope.
Why point-in-time snapshots age too quickly
Vendor posture changes continuously as suppliers add features, alter integrations, remediate issues or absorb new third parties of their own. That means a score or incident report from 30 or 60 days ago may no longer represent current exposure. The governance problem is not only outdated data, but also the false certainty created when teams treat stale evidence as current risk. In third-party ecosystems, the control question is no longer whether a vendor was safe once, but whether its present operating state still fits your dependency profile. Read the Ultimate Guide to NHIs: Key Challenges and Risks.
Practical implication: Replace periodic-only review cycles with monitoring triggers tied to material service or access changes.
Threat narrative
Attacker objective: The objective is to exploit supplier trust to reach data, systems or operations that the attacker could not access directly.
- Entry begins through the third-party vendor relationship, where the organisation inherits exposure from a supplier’s controls, integrations or operational weak points.
- Escalation follows when the supplier’s posture changes or its access is over-trusted, allowing the issue to affect sensitive data, privacy or business operations.
- Impact lands in the customer environment as disrupted services, broader attack surface or compromised data handling rather than a narrow vendor-only incident.
Breaches seen in the wild
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Traditional TPRM is now a context problem, not a checkbox problem. The article shows that questionnaires and simple vendor scores were built for a slower, more bounded supply chain than the one organisations operate today. Risk decisions now depend on who the vendor is, what service it delivers and what access it has, not just whether it passed a review cycle. Practitioners should stop treating vendor assessment as a static compliance exercise.
Security ratings create false precision when the underlying relationship is operationally unique. A letter grade can be consistent across vendors while the real-world consequences are wildly different. That is especially true when the supplier touches identity flows, tokens, SaaS integrations or other paths that can widen blast radius. The governance gap is not lack of scoring, but lack of contextual weighting. Practitioners should rank suppliers by dependency criticality, not by score alone.
Third-party exposure is also an identity governance issue. Supplier access is increasingly mediated through accounts, APIs, tokens and delegated integrations, which means third-party risk management and identity governance now overlap materially. When third parties can act through non-human credentials, the control problem shifts from procurement paperwork to lifecycle governance, access scope and offboarding discipline. Teams should govern supplier identities with the same rigour they apply to internal privileged access.
Contextual vendor risk: the real control failure is assuming a vendor score can stand in for the service relationship itself. In practice, the same external dependency can be low-risk for one workflow and business-critical for another. That means governance needs an inventory of who the vendor touches, what it can reach and how quickly its risk state can change. Practitioners should build decisions around dependency context, not generic vendor grade.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Third-Party Risk Management Guide
What this signals
Contextual vendor risk: the control boundary has moved from vendor approval to ongoing dependency governance. As third parties become embedded in identity flows, SaaS integrations and operational runbooks, the practical question is not whether a supplier was assessed, but whether its current access still matches the service it provides.
Static grades are increasingly poor proxies for resilience because they compress relationship-specific risk into a single number. Security teams should expect more pressure to prove why a vendor matters, what it can touch and how quickly exposure can change, especially when third-party access is mediated through OAuth app governance and other delegated credentials.
For practitioners
- Rebuild vendor tiering around service criticality Separate suppliers by the business processes, data sets and operational dependencies they affect, then apply stricter review to the suppliers that could disrupt core services.
- Use ratings as triage, not as a decision engine Treat SRS results as one input for prioritisation, then validate them against service scope, access paths and customer impact before approving or renewing a vendor.
- Review third-party access as an identity problem Inventory supplier accounts, OAuth grants, API keys and other delegated access so offboarding and scope reduction are governed as access lifecycle tasks, not procurement tasks.
- Replace static reviews with change-triggered monitoring Trigger reassessment when a vendor adds integrations, changes ownership, expands access scope or suffers a material security event, because those changes alter real exposure faster than annual questionnaires.
- Tie continuity planning to supplier blast radius Identify the vendors whose failure would affect operations, then use that dependency map to prioritise resilience planning, fallback options and contractual escalation paths.
Key takeaways
- Traditional vendor questionnaires and ratings miss the business context that determines whether a third party is tolerable or dangerous.
- The article’s core critique is that static scores can be precise-looking while still being irrelevant to the actual service relationship.
- Practitioners should anchor third-party risk decisions in dependency criticality, access scope and change-triggered monitoring.
Related NHI Mgmt Group resources: Third-Party Risk Management Guide · SaaS-to-SaaS and OAuth App Governance Guide · Top 10 NHI Issues · BeyondTrust breach 2024
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party vendors are a direct source of risk in this article, especially where delegated access and integrations are involved. |
| NHI-10 — Human Use of NHI | The article highlights supplier access through accounts, tokens and delegated credentials that need identity governance. | |
| Recommendation — Track third-party identities and revoke vendor access when their relationship or security posture changes. Govern supplier tokens and accounts as non-human identities with lifecycle controls, ownership and offboarding. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The article is fundamentally about how organisations prioritise and manage third-party risk. |
| ID.RA-01 — Asset Vulnerability and Threats are Identified and Analyzed | Vendor scores and questionnaires are being critiqued as incomplete risk identification methods. | |
| Recommendation — Use a risk management strategy that weights suppliers by service criticality, data exposure and operational dependency. Continuously identify supplier vulnerabilities and threats instead of relying on annual review cycles. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s identity angle is supplier accounts, tokens and access that must be managed across the vendor lifecycle. |
| Recommendation — Manage supplier accounts and delegated access with the same lifecycle discipline as internal user accounts. | ||
Key terms
- Third-party risk management: Third-party risk management is the process of identifying, assessing, monitoring, and reducing risk introduced by external vendors and service providers. In identity terms, it governs who outside the organisation can reach systems or data, how that access is approved, and when it must be removed.
- Security Rating: A security rating is an external score that estimates an organisation’s cyber posture from observable signals such as exposed services, configuration, and known issues. It is a useful screening tool, but it does not by itself prove that identity controls, access boundaries, or offboarding are effective.
- Vendor Criticality Tiering: Vendor criticality tiering is the process of grouping suppliers by the business impact they could create if they failed or were compromised. It helps organisations decide how deeply to assess each vendor, how often to review them, and which controls deserve the most attention.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for practitioners who need to connect identity governance, machine identity security, and access control to broader risk decisions.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org