What happens when a third-party provider controls the patch for a vulnerable service?

When a third party owns the patch, what risk actually changes?

The core issue is not just whether the vulnerability is real, it is who can move the fix and how quickly. Once a third party controls remediation, your exposure includes vendor delay, unclear ownership, and the possibility that the service remains reachable longer than the business wants. That turns patching into a resilience decision as much as a technical one.

In practice, the question shifts from "is there a bug?" to "what is the business consequence of waiting?" If the service supports critical operations, then the organisation may need to accept temporary exposure, disable a feature, or isolate a dependency while the vendor works the patch path. The right answer depends on blast radius, not just vulnerability severity.

That is why third-party patch control must be assessed alongside dependency criticality, compensating controls, and service ownership. A vulnerable component may be tolerable if the organisation can contain it, but dangerous if it sits on a high-trust path or supports sensitive workflows. Treat the patch timetable as one input into operational risk, not the whole decision.

How should banks judge compensating controls and service dependency?

The first task is to identify exactly what the vulnerable service enables, which upstream and downstream processes depend on it, and what would fail if access were reduced. If the service authenticates users or systems, the decision is also about trust boundaries, because a temporary workaround may need to narrow privileges, segment access, or move traffic to a safer path. IAM and IGA Basics is useful here because it frames how access, entitlement, and governance decisions interact when a dependency is outside your direct control.

Compensating controls should be judged on whether they reduce exposure in the same attack path, not whether they are merely convenient. That may include restricting network reachability, disabling nonessential functions, tightening authentication, or increasing monitoring until the third party ships a fix. If a control only adds friction but does not reduce exploitability or business impact, it is not a meaningful substitute for remediation.

The most important operational question is whether the organisation can safely continue running with reduced functionality. In some cases, the better decision is to accept a controlled outage or partial degradation rather than preserve full availability on an exposed service. That is a business continuity decision informed by security, not a security decision after the fact.

What does governance look like when remediation is outside your control?

Governance matters because third-party patch control introduces an accountability gap: the bank owns the risk to customers, but the vendor owns the fix. A mature response defines who can approve temporary exceptions, who tracks remediation status, and what evidence is required before risk acceptance expires. It should also include a clear escalation path when the patch date slips or the vendor cannot give credible assurance.

For exposed integrations and supplier-connected services, the important control is not just contract language. It is proving that the bank can inventory dependencies, isolate the affected service if necessary, and verify that fallback arrangements really work under pressure. Third-Party, B2B and Contractor Access Guide fits this problem because it covers sponsorship, least privilege, reviews, and time limits for external access.

When the service is internet-facing or part of a broader software chain, the vendor's vulnerability-handling discipline also matters. Banks should expect clear disclosure, version tracking, and evidence that the provider can remediate without introducing a worse failure mode. IAM and IGA Basics and vendor risk processes work best when they are tied to actual service paths, not just annual review paperwork.

Risk and Threat Considerations

Third-party patch control increases exposure because attackers often target the window between vulnerability disclosure and vendor remediation. If the affected service holds trust relationships, tokens, or privileged connectivity, compromise can spread beyond the original component into adjacent systems and business processes.

Failure mechanism: The provider delays the fix, the bank keeps the service online, and the vulnerable path remains reachable long enough for exploitation or abuse.

Impact: The result can be service compromise, data exposure, or a forced shutdown under worse conditions than a planned containment step would have caused.

Practitioner Guidance

What to prioritise: Determine whether the service is business-critical, externally reachable, or part of a trust chain before debating patch timing. If the service can be isolated or degraded safely, that often gives the bank more control than waiting for the vendor's release cycle.

What to verify: Confirm that you know which processes depend on the service, which compensating controls are active, and who can authorise continued exposure. If those three points are unclear, the organisation is not yet ready to accept the risk of waiting.

Decision rule: If keeping the service online preserves more operational risk than temporarily reducing it, treat isolation, feature restriction, or controlled outage as the safer path. If a fallback cannot be demonstrated, do not assume the compensating control exists just because it is documented.

Practitioner takeaway: When a third party owns the patch, the real decision is whether you can bound the business impact while you wait, because unmanaged waiting is itself a risk posture.

Related resources from NHI Mgmt Group

• What happens when a third-party service provider is compromised in a shared cloud ecosystem?
• What happens when a third-party ICT provider disrupts a DORA-covered financial service?
• What is the difference between relying on cloud service provider controls and adding third-party cloud data security tools?
• Who is accountable when a third-party service provider mishandles personal data under the Colorado Privacy Act?