Notifications
Clear all
Topic starter
11/06/2026 11:02 pm
TL;DR: Third-party suppliers were tied to nearly 30% of data breaches in 2025, according to Verizon, as organisations expand their dependency on external applications and services. Treating vendor risk as an IT procurement issue leaves security teams exposed to domino effects that can compromise data, customers, and operational continuity.
NHIMG editorial — based on content published by JumpCloud: third-party vendor risk and simplified app patch management
By the numbers:
- 30% of data breaches in 2025 were tied, re tied to third-party suppliers.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: How should security teams manage third-party vendor risk across external applications?
A: Security teams should treat third-party vendor risk as a living control process, not a one-time approval.
Q: When does third-party application patching become a governance issue?
A: It becomes a governance issue as soon as the organisation cannot prove which application versions are installed, who owns remediation, and how quickly unsupported software is removed.
Q: What do organisations get wrong about vendor due diligence?
A: Many teams treat due diligence as a gate at onboarding instead of a continuous control.
Practitioner guidance
- Build a live third-party inventory Track every external application, supplier integration, and managed service that can reach sensitive data or systems.
- Enforce patch visibility across Mac and Windows fleets Create a central view of third-party application versions and tie it to policy that flags or remediates unsupported builds.
- Tie supplier due diligence to operational reassessment Re-run security reviews when a vendor changes ownership, patch posture, access model, or handling of sensitive data.
What's in the full article
JumpCloud's full post covers the operational detail this article intentionally leaves for the source:
- A closer look at the application patch management workflow for Mac and Windows endpoints.
- The console-level controls for patch visibility, update enforcement, and policy configuration.
- How end-user notifications and recommended settings are handled in the vendor workflow.
- The operational view of how organisations can reduce tool sprawl while managing third-party apps.
👉 Read JumpCloud's analysis of third-party vendor risk and app patching →
Third-party vendor risk and patching: what IAM teams miss?
Explore further
12/06/2026 7:31 am
Third-party risk is now a control boundary, not a procurement afterthought. The article’s central point is that organisations inherit risk from the suppliers and applications they trust, whether or not those systems sit inside their own perimeter. That is the same structural problem NHI governance faces when identities, tokens, and delegated access outlive the business process that created them. The implication is that trust relationships must be governed as active security assets, not static vendor records.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI, showing that policy intent is moving faster than governance readiness.
A question worth separating out:
Q: Who is accountable when a supplier breach affects downstream customers?
A: Accountability is shared, but it is not diffuse. The vendor is accountable for its own security failures, while the customer remains responsible for the trust it extends, the data it exposes, and the controls it enforces around third-party access. Frameworks such as the NIST Cybersecurity Framework 2.0 support that shared-responsibility view.
👉 Read our full editorial: Third-party vendor risk is now a core cybersecurity control gap
