TL;DR: Coalition’s Q2 2026 Risky Tech Ranking shows the vendor set grew from 10,388 to 10,530 while contributing vulnerabilities rose from 49,320 to 58,098, and the average vendor score increased 110% since Q2 2025. Exploitability, not raw CVE count alone, is becoming the more useful way to think about technology risk.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Coalition's research: Coalition's quarterly Risky Tech Ranking tracks which technology vendors are most exposed to exploitation, and Q2 2026 shows both the scored vendor pool and contributing vulnerabilities rising sharply.
Why it matters: This matters because security and identity teams use third-party technology across access, authentication, and operations, so exploit-prone products can expand attack surface before governance or compensating controls catch up.
By the numbers:
- The Average Vendor Score increased 110% since Q2 2025.
Context
Vulnerability ranking systems are only useful when they convert raw disclosure volume into a triage signal. In this case, Coalition is ranking vendors by multiplying the number of vulnerabilities affecting their products by the average exploitability score, which is a useful reminder that exposure is not the same as count.
For identity and access teams, the relevance is indirect but real: the technologies that sit around IAM, PAM, SSO, API access, and operations often become the first route into the environment when exploited. A ranking like this helps teams decide which third-party products deserve tighter review, faster patching, or compensating controls before they become an access path.
Key questions
Q: What should security teams do when an exploited CVE is tied to a third-party product?
A: Treat the issue as an operational assignment problem, not just a scanner finding. Map the vulnerability to the owning platform, confirm the vendor fix path, and track the due date in the same record so the patch owner can act without chasing separate reference sources.
Q: Why does exploitability matter more than severity in CTEM prioritisation?
A: Severity alone does not show whether an attacker can reach the exposure or turn it into a compromise path. A lower-severity issue on an internet-facing, business-critical asset may deserve more urgency than a higher-severity issue on an isolated system. CTEM works best when validation confirms which findings are actually actionable.
Q: What are the signs that vendor and account risk is increasing in practice?
A: Common warning signs include unusual access times, abnormal data downloads or transfers, privilege escalation attempts, lateral movement patterns, exposed vendor credentials, and a drop in vendor security ratings. These indicators often appear before a full compromise becomes obvious. Teams should treat them as signals to investigate access scope, identity controls, and external dependencies.
Q: How should organisations review third-party risk when a vendor’s ranking moves sharply?
A: Treat sharp movement as a trigger for governance review, not just a reporting note. Recheck exposure paths, renewal assumptions, and exception decisions, then decide whether the product deserves tighter controls, faster remediation, or reduced trust in sensitive workflows.
Technical breakdown
How exploitability scoring changes vulnerability prioritisation
A vulnerability ranking built on exploitability is different from a simple CVE tally. It weights the presence of flaws by how likely they are to be used in real attacks, which helps separate noisy disclosure volume from the subset that creates near-term operational risk. That matters because organisations cannot treat every CVE as equally urgent, especially when patch backlogs are large and remediation resources are finite. A score that blends vulnerability volume with exploitability gives security teams a sharper way to compare vendors, products, and release cycles. Practical implication: Use exploitability-weighted scoring to decide which products enter emergency review first. See the Vulnerability Management Guide.
Practical implication: Use exploitability-weighted scoring to decide which products enter emergency review first.
Why vendor score movement matters more than rank movement alone
A vendor’s position in a quarterly ranking can shift because of either more disclosed vulnerabilities or a higher average exploitability profile. Those are different problems. A falling rank does not necessarily mean a safer estate if the underlying product set is still accumulating severe issues, and a rising rank can reflect concentrated risk even when patch activity increases. For practitioners, the point is to look past the ordinal position and examine the drivers behind it: product count, CVE density, and the exploitability profile behind each disclosed weakness. Practical implication: Trend the inputs behind rank changes, not just the rank itself.
Practical implication: Trend the inputs behind rank changes, not just the rank itself.
How third-party product risk feeds identity and access exposure
When commonly deployed products are vulnerable, the downstream risk is often privilege exposure rather than only service disruption. Many enterprise products sit on trusted paths, store secrets, or integrate with authentication and administrative workflows. If those products are exploitable, they can become a pivot point into account takeover, tenant access, or broader control-plane compromise. That is why vulnerability ranking belongs in identity governance conversations as well as traditional patch management. The question is not only whether a vendor has flaws, but whether those flaws intersect with access boundaries, secrets, or administrative trust. Practical implication: Treat exploitable third-party products as potential identity attack paths. See the Vendor Security Assessment Template.
Practical implication: Treat exploitable third-party products as potential identity attack paths.
NHI Mgmt Group analysis
Exploitability-weighted ranking is more operationally useful than raw CVE counting. A vendor with fewer total vulnerabilities can still present a worse real-world risk if its issues are easier to exploit or more likely to be weaponised quickly. That is the right lesson from this ranking: remediation priority should follow exploitability and exposure path, not disclosure volume alone. Practitioners should use ranked exposure to decide where response SLAs tighten first.
Third-party software risk now belongs inside identity governance, not beside it. Products that broker access, store tokens, or expose administrative interfaces can turn vulnerability management into an IAM problem very quickly. That is where vendor security assessment becomes relevant: procurement and assurance teams need to ask whether a product can become an access path before they approve it. Practitioners should evaluate vendor trust as part of access design, not only after deployment.
Rank volatility is a signal that remediation discipline, not reputation, should drive policy. Cisco, Oracle, Fortinet, and others moved as their vulnerability profiles changed, which means yesterday’s assumption about vendor risk can age out within a quarter. Security teams should not anchor on brand familiarity or historical procurement decisions when deciding what to inspect first. Practitioners should convert ranking movement into review cadence and exception management.
The named concept here is vendor exploit surface drift. This is the gap between how a technology is perceived operationally and how quickly its exposed attack surface changes through new disclosures, patch backlogs, and exploitability shifts. When that drift is not tracked, procurement and operations continue to treat a product as stable after its risk profile has materially changed. Practitioners should measure drift continuously and feed it into renewal, approval, and containment decisions.
What this signals
Vendor exploit surface drift: quarterly vulnerability movement changes the trust profile of widely used technology faster than many procurement and renewal cycles can absorb. Security leaders should treat ranking volatility as a governance input, not a reporting curiosity, because the practical question is whether a product still deserves the same level of trust it had last quarter.
Coalition’s update reinforces a broader operational pattern: vulnerability management and third-party assurance are converging. When exploitable flaws are being used to rank vendors, the control conversation shifts from patch counts to exposure boundaries, secret-bearing products, and the paths that turn a software flaw into an access event.
For practitioners
- Prioritise exploitability over raw CVE volume Use exploitability-weighted review to decide which vendors and products move to the front of patch, containment, and exception queues.
- Map risky products to identity and access dependencies Inventory which externally facing products sit on authentication, privilege, token, or administrative paths so a weakness can be tied to access exposure.
- Shorten remediation SLAs for products with rising exposure Set tighter internal deadlines when a product’s vulnerability count and exploitability profile both trend upward across consecutive quarters.
- Review procurement decisions against current exposure data Reassess renewal, onboarding, and exception approvals using the latest ranking movement rather than historical vendor assumptions.
Key takeaways
- The core issue is not just how many flaws exist, but how quickly exploitable weaknesses change the risk profile of third-party technology.
- Coalition’s Q2 2026 update shows a larger scored vendor set, more contributing vulnerabilities, and a higher average vendor score than in prior periods.
- Practitioners should translate exposure rankings into procurement review, remediation SLAs, and tighter governance around products that touch access paths.
Related NHI Mgmt Group resources: Vulnerability Management Guide · Vendor Security Assessment Template · Zero-Day and Exploited Vulnerabilities Guide · Patch Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article is built around ranking and prioritising disclosed vulnerabilities by exposure. |
| Recommendation — Use continuous vulnerability management to rank exposed products by exploitability and remediation urgency. | ||
| NIST CSF 2.0 | ID.RA-01 — Vulnerability and Threat Identification | The ranking is a threat and vulnerability identification signal used to prioritise response. |
| Recommendation — Incorporate vulnerability intelligence into risk identification and prioritisation workflows. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The article centres on identifying and tracking vulnerable products across vendors. |
| Recommendation — Apply RA-5 to monitor vendor products and drive remediation based on current exposure. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | Exploited products often become entry points that support discovery and lateral movement. |
| Recommendation — Map vulnerable products to attack paths that enable discovery and lateral movement. | ||
Key terms
- Exploitability-Weighted Risk: Exploitability-weighted risk is a prioritisation method that combines severity with real-world attacker likelihood, asset criticality, and exposure. It is more useful than raw scoring because it helps teams focus on what can actually be abused first, not just what looks serious on paper.
- Application Exposure Drift: The gap that opens when a mobile app’s approved state no longer matches its real-world exposure. SDK updates, API changes, distribution changes, and delayed user upgrades can all alter risk without a formal revalidation event.
- Third-Party Attack: A third-party attack is a security incident that begins through a supplier, contractor, partner, or other external dependency. It exploits trusted access, integrations, software updates, credentials, or data flows to reach the target organization. In practice, it is a supply chain or ecosystem compromise that bypasses direct perimeter defenses.
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. Explore the course if your role includes access governance, secrets management, or machine identity oversight.
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