Mid-market IT teams are drowning in security tools. The average organisation now manages more than ten separate point solutions, and over a quarter juggle thirty or more. Each tool was purchased to solve a specific problem. Together, they create a new one.
This accumulation of firewalls, VPN concentrators, web gateways, and endpoint agents that barely communicate has earned its own name: the Frankenstack. It looks impressive on paper. In practice, it slows incident response, exhausts staff, and leaves gaps that attackers happily exploit.
What you will learn
-
Why adding more security tools often makes you less secure
-
How the Frankenstack phenomenon drains IT capacity and increases risk
-
Why traditional perimeter defences no longer match how organisations actually work
-
What a practical path forward looks like using a unified SASE architecture
How we got here
The tool sprawl did not happen overnight. It followed the pattern of every new threat being met with a new product. Ransomware emerged, so organisations bought anti-ransomware. Phishing spiked, so they added email security. Cloud adoption accelerated, so they layered in CASB. Each purchase made sense in isolation.
The problem is that security vendors rarely design for interoperability. Each tool comes with its own console, its own alert format, its own update cycle, and its own learning curve. When a firewall speaks a different language than your endpoint protection, and your VPN logs sit in yet another format, correlating events becomes nearly impossible without expensive SIEM platforms that many mid-market organisations cannot justify.
The result is an environment where IT teams spend close to half their capacity not on threat hunting or strategic improvements, but simply keeping the tools themselves running. Patching agents, reconciling conflicting alerts, managing vendor relationships. The hidden cost of this integration friction often exceeds the licence fees of the software itself.
The Frankenstack effect on daily operations
Nearly 80% of organisations report that the complexity of their security stack slows their incident response times rather than accelerating them. This is the opposite of what more tools should achieve.
The mechanism is straightforward. When an alert fires in one system, the analyst needs context from three others. They switch consoles, wait for dashboards to load, try to match timestamps across different time zones, and hope the naming conventions align. By the time they piece together what happened, the attacker has moved on.
Alert fatigue compounds the problem. Non-integrated systems generate overlapping notifications for the same event, or worse, contradictory ones. Critical warnings get lost in the noise. Staff learn to tune out alerts because investigating each one takes too long. This is not laziness. It is a rational response to an irrational environment.
The psychological toll matters too. Security analysts in mid-market organisations often wear multiple hats. When their day is consumed by operational maintenance, the strategic work that would actually improve the organisation’s posture gets pushed indefinitely. Burnout follows.
The perimeter that no longer exists
Underneath the tool sprawl sits an older problem: an architectural model that no longer matches reality.
The traditional approach treated security as a castle with walls. Firewalls guarded the perimeter. VPNs created tunnels for authorised visitors. Once you were inside, you were trusted. This worked reasonably well when employees sat in offices, applications ran in on-premises data centres, and “the network” had clear edges.
That world is gone. Employees work from home, coffee shops, and client sites. Applications live in multiple clouds. Data flows through SaaS platforms the IT team may not even know about. The network no longer stops at the office walls.
Yet many mid-market organisations still rely on the castle model. Firewalls remain the primary defence. VPN contracts run for years. The technology feels familiar, and sunk costs are real. But familiar does not mean effective.
Why firewalls and VPNs fall short
Firewalls block traffic based on ports and IP addresses. This made sense when threats arrived on recognisable ports and from known bad addresses. Modern attacks do not cooperate. Phishing emails arrive through legitimate mail services. Malware hides in encrypted web traffic on port 443. Attackers use stolen credentials to walk through the front door.
A standard firewall cannot stop what it cannot see. And when the attack uses valid credentials, there is nothing to block. This is where advanced methods like Browser Isolation become necessary, yet are often missing from legacy stacks.
VPNs create a different problem. They grant all-or-nothing access. Once connected, a user typically has far more reach than their job requires. An accountant can browse the engineering file share. A contractor can poke around systems that have nothing to do with their project. If one of those accounts gets compromised, the attacker inherits the same broad access.
This clashes directly with the principle of least privilege, which underpins modern security thinking. VPNs were not designed for a world where every user and every device needs individual validation.
The segmentation myth
Some organisations try to address lateral movement risk by segmenting their networks into zones. VLANs separate finance from engineering, production from development. In theory, a breach in one zone stays contained.
In practice, users routinely share insecure segments. The boundary between zones often has exceptions for convenience. And once an attacker lands on a compromised endpoint within a zone, they can move freely to other systems in that same space.
Classic segmentation does not stop lateral movement. It merely slows it down in the best case, and provides false confidence in the rest. Without Identity-Based Micro-Segmentation at the application level, the internal network remains an open field.
The devices that cannot run agents
The Frankenstack problem extends beyond traditional endpoints. Printers, cameras, IoT sensors, and industrial machines increasingly connect to corporate networks but cannot run security agents. They represent blind spots that legacy tools simply cannot address.
These agentless devices are often the weakest link. Their firmware rarely gets updated. Their credentials are sometimes left at factory defaults. Once compromised, they provide a pivot point into the broader network.
Industrial environments face this challenge acutely. Production equipment must stay running. Installing agents risks stability. But leaving these systems unprotected risks everything else. This specific gap requires a Network Isolation approach, rather than just another software firewall.
What a practical path forward looks like
The answer is not another point solution. It is consolidation around a different architectural model known as SASE (Secure Access Service Edge).
Zero Trust Network Access (ZTNA) replaces the VPN tunnel with granular, identity-based access. Each user and device gets precisely the resources they need for their current task, nothing more. If credentials get stolen, the blast radius shrinks to whatever that specific account could reach, not the entire network.
A Secure Web Gateway (SWG) utilizing Remote Browser Isolation (RBI) moves policy enforcement to the edge. Unlike traditional gateways that try to filter bad code, RBI executes web content in a secure container in the cloud. No malicious code ever reaches the endpoint. Central policy replaces the patchwork of firewall rules scattered across locations.
For agentless devices and OT environments, Inline Isolation hardware (such as the Jimber NIAC) creates a secure bridge. The printer can reach its update server. The industrial sensor can report to its collector. Neither can roam freely or become a stepping stone for attackers.
The shift is not just technical. It is operational. One console replaces multiple dashboards. One policy model applies everywhere. One audit trail covers the organisation. The time previously spent context-switching between tools gets redirected to work that actually improves security.
Measuring the improvement
Organisations that consolidate typically track a few straightforward metrics. The number of consoles staff need to access daily. The mean time to investigate an alert. The percentage of devices covered by consistent policy. The frequency of configuration errors.
When these numbers improve, so does the security posture. Not because of magic, but because the team has capacity to do their jobs properly.
Practical examples from European organisations
A Belgian municipal government replaced its patchwork of VPN gateways and site firewalls with a unified SASE platform. Access to citizen-facing applications and internal systems now flows through identity-based policies. IT gained a single view across all locations. Audit preparation that previously took weeks now takes days.
A manufacturing company in the Benelux connected its factory floor to corporate IT without exposing production equipment directly. Using NIAC hardware for inline isolation allowed maintenance engineers to access specific machines through recorded, time-limited sessions. The production network remains separate. The audit trail is complete.
A healthcare provider applied consistent web security and access controls across clinics and remote staff. Clinicians reach electronic health records from managed devices only. Imaging equipment connects to PACS servers and nothing else. When a workstation showed signs of compromise, the affected segment was isolated within minutes thanks to micro-segmentation.
Frequently asked questions
Is consolidation realistic for organisations with limited IT staff? Yes. The point of consolidation into a Unified SASE platform is specifically to reduce operational burden. Fewer tools mean fewer consoles to learn, fewer vendors to manage, and fewer integration headaches. Small teams benefit most.
What happens to existing investments in firewalls and VPNs? Most organisations phase out legacy infrastructure over time rather than replacing everything at once. The new model can run alongside existing tools during transition. Some firewalls may remain for specific north-south traffic controls while Identity-Based Access handles everything else.
Does this approach meet NIS2 requirements? NIS2 requires demonstrable risk management, access control, and incident response capabilities. A unified platform with central logging, policy versioning, and role-based access provides the evidence auditors expect. The consolidation itself makes compliance easier because the documentation is in one place.
How do agentless devices get secured without disrupting production? Inline isolation hardware (NIAC) sits between the device and the network. It controls what traffic flows in and out without requiring changes to the device itself. Production equipment keeps running. The security boundary moves to the network layer.
Where does endpoint detection fit in? Endpoint telemetry adds depth to the model. It provides visibility into what happens on managed devices and can trigger automatic isolation when threats are detected. Organisations that do not run EDR today can plan for integration as their security programme matures.
Can partners and MSPs manage multiple customers through this model? Multi-tenant platforms allow service providers to apply consistent policies across customers while keeping environments properly separated. This reduces the support burden and makes managed security services commercially viable at mid-market price points.
Moving forward
The complexity trap is real, but it is not inevitable. Mid-market organisations can escape the Frankenstack without heroic efforts or unlimited budgets. The path runs through consolidation, Zero Trust, and operational simplicity.
Jimber’s platform brings Zero Trust Network Access, Browser Isolation, Firewall-as-a-Service, and SD-WAN together in one cloud-managed SASE console. For agentless and industrial devices, our NIAC hardware closes the blind spots that legacy tools leave open.
Ready to see what your security operations look like with fewer consoles and clearer policies? Book a demo and walk through your environment with a Jimber specialist.
