What should banks do when a critical flaw cannot be patched quickly?

Why This Matters for Security Teams

When a critical flaw cannot be patched quickly, the problem is no longer just vulnerability management. It becomes a resilience and containment decision: how to keep core banking services running while limiting exposure, especially where privileged access, service accounts, and API-driven workflows are involved. The right response depends on whether the weakness sits in a customer-facing channel, a backend integration, or an identity path that can be abused for lateral movement. Guidance from the NIST Cybersecurity Framework 2.0 emphasizes outcomes such as risk reduction and response coordination, but banks also need identity-aware controls that can be executed immediately.

This is where NHI governance becomes practical. If a flaw touches a token, key, certificate, or service account, the exposure often spreads faster than patch cycles can keep up. NHI Mgmt Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why banks should treat unpatched critical flaws as a credential and trust problem, not only a code defect. In practice, many security teams encounter systemic impact only after an attacker has already turned a small technical gap into a privileged access path.

How It Works in Practice

Containment needs to start with the smallest safe blast radius. For banks, that usually means isolating the affected application path, reducing entitlements on adjacent identities, tightening network and application allowlists, and increasing detection on the exact workflows that still must stay live. If the vulnerable component is tied to automation, an agent, or a machine-to-machine integration, the immediate question is whether the identity can be constrained without breaking settlement, payments, fraud checks, or customer authentication.

A practical response sequence often includes:

• Disable non-essential access to the vulnerable service, including partner integrations and admin routes.
• Rotate or revoke exposed secrets where there is any sign of leakage, with priority on tokens used by high-trust systems.
• Move from standing access to just-in-time elevation for nearby administrative identities.
• Increase telemetry on authentication, API calls, privileged actions, and unusual inter-service traffic.
• Document compensating controls for audit, risk acceptance, and incident review.

That approach aligns with zero trust principles, but banks should be careful not to assume that segmentation alone is enough. If the flawed component already holds broad privileges or long-lived credentials, isolation may only slow abuse unless those credentials are also narrowed. The GitHub Personal Account Breach is a useful reminder that identity compromise often becomes the real control failure, not the initial bug. Current guidance suggests combining containment with identity reduction, because one without the other leaves a live attack path in place. These controls tend to break down when the vulnerable service is deeply embedded in payment processing or mainframe-connected workflows, because even minor changes can trigger operational outages.

Common Variations and Edge Cases

Tighter containment often increases operational overhead, requiring organisations to balance reduced exposure against service continuity, regulatory expectations, and customer impact. There is no universal standard for this yet, especially when the flaw affects a vendor-managed component or a legacy banking platform that cannot tolerate rapid configuration change. In those cases, the best practice is evolving toward compensating controls, formal risk acceptance, and short review cycles rather than waiting passively for a patch.

One common edge case is a flaw in a third-party dependency that cannot be upgraded without breaking an upstream system. Another is a weakness in an identity provider, secrets manager, or certificate workflow, where the right move may be temporary credential re-issuance and tighter trust boundaries rather than broad service shutdown. The Schneider Electric credentials breach and SpotBugs Token GitHub Supply Chain Attack both highlight how quickly access material can turn a technical weakness into wider trust compromise. For banks, the key judgement is whether the control gap is local or systemic, because local flaws can often be contained, while systemic ones may require temporary service restrictions and executive risk sign-off.

Related resources from NHI Mgmt Group

• How should organisations secure legacy OT that cannot be patched quickly?
• Who is accountable when a compromised password cannot be reset quickly enough?
• What breaks when users cannot quickly issue or replace a credential?
• What breaks when a Linux kernel flaw like Dirty Frag is not patched?