Nobody thinks they’ll leave the back door wide open until it happens.  

Sometimes the biggest cybersecurity weaknesses are the ones that hide in plain sight, where nobody bothers to look for them. One of the most underestimated and dangerous is the humble IP conditional access policy that network security teams use to limit network access to certain IP address ranges.  

How might restricting access by IP become a security weakness? Incredibly easily, in fact. IP address restriction is a great idea, indeed; it’s an essential tool of modern cybersecurity policies. But anyone who forgets its limitations will find themselves heading into hazardous territory, which is where my story of a real-world near-disaster begins.  

Company X decided it would only allow employees with UK IP addresses to access its network. So far, so good, but then the admins made a big mistake. Reasoning that IP address filtering was enough on its own, they decided not to require users to authenticate using MFA. If you’ve ever wondered what zero-trust cybersecurity looks like, this was its opposite.  

Address restriction has known limitations, but one of the biggest is that it can be bypassed using a VPN that spoofs the IP address to appear to be originating from any country the attacker wants. That’s why US-based IP addresses regularly feature near the top of attack IPs, even though only a small percentage of those originate in the US.  

Armed with a compromised credential for a UK employee, this allowed an attacker to bypass what appeared to be a sensible control, thereby accessing that user’s emails. What lay at the end of this was most likely a ransomware attack, except that, in this case, our SOC monitoring spotted that something was awry and stepped in to block further access. 

Doing it to Yourself 

What happened in this incident is what’s politely called a misconfiguration. Look that term up on Google and you’ll quickly uncover a long list of common examples, many connected to cloud platforms. In fact, examples barely scratch the surface of a problem that has become one of the biggest underlying causes of cybersecurity failure. 

We’re conditioned to see things like software vulnerabilities and state-of-the-art hacking malware as the big threats. But what catches many organizations is the things they do to themselves. Take, for instance, the organization that migrated from a vulnerable legacy VPN platform to one based on the cloud. This looked like a good security move until it was discovered that someone had forgotten to turn off the old VPN interface, leading to full domain access and the deployment of ransomware (this company has now upgraded its SOC capability to stop a repeat).  

Or the large UK company whose managed services provider forgot to patch a vulnerable interface exposing its client’s firewall console. The MSP assumed that putting the interface on a separate port offered protection. The result was another ransomware compromise followed by significant business downtime.  

These are not isolated examples. Misconfigurations are commonplace and can happen to anyone, not helped by the tech industry’s habit of inventing new ones. The latest example for 2025 is Model Context Protocol (MCP), a suddenly very important mechanism for AI platforms to connect to external systems and data sources. Unfortunately, it’s becoming clear that MCP is also vulnerable to token theft, prompt injection attacks, and direct server compromise. MCP is new and unfamiliar, which means that security is not always front of mind. Securing an external-facing MCP server is a major undertaking that inexperienced security teams can easily get wrong. 

Can Misconfigurations be Avoided? 

As long as humans configure computer systems, there will always be misconfigurations and oversights, especially around new technology. Sometimes a misconfiguration can look like the failure of a single control – an unsecured S3 bucket, someone forgetting to apply MFA properly, a weak password policy, or a failure to apply encryption – but many are more complex. Rather than a single mistake, misconfigurations are often a chain of smaller errors and misunderstandings that amplify one another. The trick is to analyze the underlying problem, not simply the control that has failed. At root, this is often a human failure, either to apply something or to understand its importance. Examples include: 

Out-Of-The-Box Failures 

For years, the shared responsibility model adopted by cloud platforms made security a gray area. Sometimes controls were on by default, sometimes they weren’t. This has now changed, but exceptions keep cropping up. The 2024 breach of Snowflake customers offers a good example. After the incident, it turned out that a small number of customers weren’t enabling MFA to protect their accounts, presumably because they weren’t required to. MFA is now mandatory, but it took a serious breach to force change.  

The On-Prem Mindset 

Just because an organization is moving to the cloud doesn’t mean its staff are moving with it. An example is organizations that embark on ambitious cloud application projects without the in-house skills to understand how to secure this in a completely new environment. On-premise and cloud security overlap, but they are not the same thing. That’s why it’s important to have the right people in place before you start.  

Outsourcing is secure (unless it isn’t) 

A big attack trend is to bypass an organization’s security by targeting weaknesses in suppliers and managed service partners. Put another way, however much an organization thinks it knows about the weaknesses in its own network, it always knows less about the weaknesses in the MSPs working for it. When you outsource to a provider, you don’t outsource the whole problem. External MSPs and SOC need careful assessment to make sure they meet the necessary standards. 

Network Oversharing  

The commonest everyday failing Acumen sees is customers leaving external interfaces or ports exposed. They don’t do this deliberately, and, understandably, mistakes happen. What’s less understandable is that these misconfigurations are allowed to persist for days, weeks or even months because organizations have no defined way of detecting them. By increasing the number of interfaces, the cloud only makes this problem bigger. 

Being Realistic 

There is no simple fix for misconfigurations, but this doesn’t mean that organizations are powerless. The first and most important action is to accept that misconfigurations will happen, even to the best of us. Armed with this realization, you need to go looking for them. If you don’t find any at first, you’re not looking hard enough. What matters is that someone spots them before attackers do. As the maxim says, the tragedy of cybersecurity failure isn’t that it goes wrong but that it goes wrong unexpectedly.