Why do misconfigured firewalls still create risk in mature security programmes?

Why This Matters for Security Teams

Misconfigured firewalls remain dangerous because mature programmes often trust the process more than the live rulebase. Over time, exceptions accumulate, legacy ports stay open for “temporary” work, and network changes outpace documentation. The result is a control that looks robust on paper but no longer reflects the services actually exposed. That gap matters because perimeter policy is still a primary containment layer in many environments, even as identity and workload boundaries become more important.

NHIMG’s guidance on Top 10 NHI Issues shows the same pattern in a different control plane: drift, privilege creep, and stale assumptions are what create exposure, not just missing tooling. The problem is not that firewalls are obsolete. It is that firewall governance frequently degrades into ticket closure rather than exposure validation. That makes the control brittle during mergers, cloud migration, and rapid application delivery, when rule intent and actual traffic diverge fastest. In practice, many security teams encounter firewall risk only after an unexpected service exposure, rather than through intentional revalidation.

How It Works in Practice

A firewall is only as effective as the accuracy of its policy, asset inventory, and exception handling. In a mature programme, risk typically appears when rules are added to unblock a change, then never narrowed after the business need passes. Broad source ranges, shared service ports, and “any-any” temporary allowances can survive for months because no one owns the cleanup. That is why current guidance in the NIST Cybersecurity Framework 2.0 emphasises continuous risk management rather than one-time approval.

Practitioners usually reduce firewall risk by connecting three control activities:

• Validate the exposed asset first, then confirm the rule is still needed.
• Map each permit rule to a named business service, owner, and expiry date.
• Review inbound, outbound, and east-west paths separately, not as one combined list.
• Reconcile firewall policy against CMDB, cloud security groups, and load balancer changes.
• Use change windows to remove stale exceptions, not just add new ones.

NHIMG’s Ultimate Guide to NHIs is relevant here because the same governance failure shows up wherever long-lived access is allowed to accumulate without revalidation. The firewall may be in place, but if the environment has changed and the rule has not, the control is effectively stale. These controls tend to break down when application teams can modify infrastructure faster than security teams can re-baseline rule intent, because the review cycle lags operational reality.

Common Variations and Edge Cases

Tighter firewall governance often increases operational overhead, requiring organisations to balance containment against delivery speed. That tradeoff becomes more visible in cloud, hybrid, and containerised environments, where ephemeral workloads change addresses and ports frequently. In those settings, the classic “review the perimeter quarterly” model is often too slow. Best practice is evolving toward policy-as-code, short-lived exceptions, and automated reconciliation, but there is no universal standard for this yet.

Some environments also reduce the value of perimeter-heavy controls because traffic is encrypted, service-to-service, or brokered through managed platforms. In those cases, a firewall can still enforce segmentation, but it cannot reliably answer whether the allowed traffic is legitimate without context from identity, workload, and application telemetry. ISO/IEC 27002:2022 supports this broader control mindset by pairing network controls with asset, change, and monitoring discipline, not treating the firewall as a standalone safeguard.

Edge cases matter most during emergency changes, third-party connectivity, and acquired networks. Those are the moments when broad permits are easiest to justify and hardest to unwind. The result is a control that remains technically enabled while its protection value erodes. That is why mature programmes treat firewall review as an exposure management task, not just a network administration task.

Related resources from NHI Mgmt Group

• Why do identity providers still create security risk in mature IAM programmes?
• Why do privileged sessions still create risk in mature IAM programmes?
• Why do application security scanners still miss real risk in mature programmes?
• Why does email still create so much data leakage risk in organisations with mature security controls?