The business owner and the security team should share accountability, because the risk is operational as well as technical. The owner decides whether the component stays, is isolated, or is replaced. Security defines the compensating controls, the exception period, and the review cadence until the dependency is retired or remediated.
Why This Matters for Security Teams
When a third-party component cannot be patched quickly, the question is not only whether a vulnerability exists. It is whether the organisation can tolerate the exposure long enough to keep operating safely. That makes ownership a governance issue, not just a ticket in a backlog. Security teams typically use the NIST Cybersecurity Framework 2.0 to anchor that decision in risk management, asset criticality, and response planning rather than informal escalation.
Practitioners often get this wrong by treating “unpatchable” as a technical dead end. In reality, compensating controls, exception handling, and retirement planning can all reduce risk while the dependency remains in service. The business owner is accountable for operational impact, while security is accountable for defining the control envelope and verifying that the exposure is understood. That split matters because the component may support customer-facing services, privileged workflows, or even machine identities that depend on long-lived secrets or API tokens, which makes the blast radius larger than the vulnerability itself. In practice, many security teams encounter ownership gaps only after an exploited dependency has already become a service outage, rather than through intentional risk acceptance.
How It Works in Practice
Shared ownership works best when the organisation treats the component as a managed risk item with a clear decision path. Security identifies the exposure, estimates exploitability, and recommends compensating controls. The business owner then decides whether to accept the residual risk temporarily, isolate the component, replace it, or remove the dependency entirely. That decision should be documented with an expiry date, named approvers, and a review cadence.
For third-party components, the practical response often includes:
- Network segmentation or service isolation to limit reachability.
- Application allowlisting or stricter input validation around the vulnerable path.
- Credential rotation, short-lived tokens, or tighter secret scope where the component uses identities or APIs.
- Monitoring and alerting for exploit indicators, abnormal requests, or privilege escalation attempts.
- Vendor escalation, patch tracking, and retirement planning if a fix is unavailable.
This is where identity governance becomes relevant. If the component runs with a service account, agent, or integration token, the organisation should apply the same discipline it would use for OWASP Non-Human Identity Top 10: minimise standing privilege, bound access narrowly, and review the trust relationship regularly. The current guidance suggests that unpatchable software should not be left with broad network access and durable credentials by default. These controls tend to break down in legacy environments with flat networks and shared administrative accounts because isolation and accountability cannot be enforced cleanly.
Common Variations and Edge Cases
Tighter containment often increases operational overhead, requiring organisations to balance service continuity against security debt. That tradeoff becomes sharper when the component sits inside a regulated workflow, a production cluster, or a partner integration that cannot tolerate downtime. In those cases, risk ownership may be shared across procurement, application ownership, infrastructure, and security, but one person still needs final authority for the acceptance decision.
There is no universal standard for every scenario, but best practice is evolving toward time-bound exceptions with explicit compensating controls rather than indefinite waivers. If the dependency is embedded in an agentic or automated workflow, the risk should also include non-human identities, token lifetimes, and tool permissions. If the component is external and the vendor cannot provide a fix, the owner should treat replacement as the default end state, not the exception. For broader control mapping, the NIST CSF emphasis on identify, protect, detect, and respond helps keep the decision tied to operational resilience rather than vendor assurances alone.
Related resources from NHI Mgmt Group
- Why do third-party incidents create identity governance risk as well as operational risk?
- Why do third-party dependencies create resilience risk for IAM programmes?
- Why do third-party data transfers create a governance risk in privacy programmes?
- What do security teams get wrong about third-party risk ownership?
