What breaks when organisations rely on firewall rules instead of patching?

Why This Matters for Security Teams

Firewall rules can stop a known attack path, but they do not repair the application, close alternate routes, or remove the vulnerable component from the environment. That distinction matters because modern compromise usually moves across layers, not through one neat ingress point. NIST’s Cybersecurity Framework 2.0 treats protection and recovery as separate outcomes for a reason: blocking traffic is not the same as eliminating exposure.

Teams also tend to overestimate what containment can do once a vulnerability is already present. If an exception, proxy path, peering rule, or shadow deployment bypasses the filter, the attacker still reaches the vulnerable code. The problem becomes even more serious when the exposed service is tied to an identity-heavy workflow, because compromise can pivot into credentials, API calls, and downstream systems. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage.

In practice, many security teams discover the weakness only after an exception path is used in production, rather than through intentional validation of whether the patch actually removed the risk.

How It Works in Practice

Patching and firewalling solve different problems. A firewall rule is a control on reachability. A patch is a control on exploitability. When organisations rely on the first instead of the second, they create a fragile dependency on every network boundary remaining perfectly enforced. That is rarely true in real environments with temporary rules, load balancers, VPNs, partner links, testing clusters, and emergency access paths.

Good practice is to use firewall rules as a short-term compensating control while remediation is planned, then verify that the vulnerable version is removed everywhere it exists. That includes production, staging, failover, golden images, container layers, and any replicated service that might still accept traffic. NIST’s framework emphasises continuous risk management, not one-time containment, and the same logic applies to NHI-heavy systems where exposed services often depend on tokens, service accounts, or API keys. The NHIMG GitHub Personal Account Breach illustrates how access paths can persist even after an initial incident is recognised.

• Use firewall rules to reduce exposure immediately, especially for internet-facing services.
• Patch or remove the vulnerable component across every environment, not just the primary production path.
• Validate whether any alternate route, exception, or internal dependency still reaches the flaw.
• Track rollback plans carefully so security controls do not disappear during maintenance windows.
• Confirm that related secrets, tokens, and service credentials are rotated if exploitation is plausible.

These controls tend to break down when legacy systems, overlapping network zones, or unmanaged replicas make it impossible to prove that every exploitable path has been closed.

Common Variations and Edge Cases

Tighter firewalling often increases operational overhead, requiring organisations to balance immediate containment against the cost of slower access, more exceptions, and higher rule-management complexity. That tradeoff is real, but it does not change the core rule: if the vulnerable code remains deployed, the risk remains deployed.

There is no universal standard for when a compensating network control is “good enough” on its own. Current guidance suggests it should be treated as temporary unless the affected system is formally decommissioned or the exploit path is proven impossible to reach. This is especially important for segmented internal networks, third-party integrations, and systems that expose secrets or automation credentials. If a service account or API key is already in play, a blocked port does not undo credential theft or lateral movement.

Some teams also assume that patching can wait if the firewall is strict. That is risky because a later configuration change, cloud security group update, or partner connection can reopen the path without anyone revisiting the original exception. NHI Mgmt Group’s Ultimate Guide to Non-Human Identities is a useful reminder that 97% of NHIs carry excessive privileges, which means containment alone can leave a broad blast radius intact. In short, firewall rules buy time, but they do not substitute for remediation.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on trusted software to prevent malware execution?
• What breaks when organisations rely only on password complexity rules?
• What breaks when organisations rely on audit logs instead of runtime enforcement?
• What breaks when organisations rely on fraud tools instead of identity observability?