For years, “fewer vendors” has been a security industry talking point even as the average stack kept growing. CyberFOX CEO David Bellini argues something has actually shifted for small and mid-sized organizations: lean IT teams are being squeezed on budget and headcount at the same time insurance and compliance requirements are forcing more controls onto their plates. That combination, he says, is what makes genuine consolidation valuable now — not simply cutting invoices, but removing the real work of reconciling tools across separate consoles, where misconfiguration hides in the gaps.
It’s also the thinking behind CyberFOX’s decision to acquire Timus SASE rather than build a competing platform from scratch — a call Bellini says would have cost the company roughly two years, largely because cloud-native SASE isn’t a feature bolted onto an existing product but an architecture decision made on day one. In this VMblog Q&A, Bellini walks through what CyberFOX would have gotten wrong on its own, why VPN has survived a decade of obituaries, what most security vendors misunderstand about how five-person IT teams actually operate, and where CyberFOX is looking next as it continues building out its stack.
++
VMblog: On the decision itself: You’ve said Timus built the platform you would have built yourselves. So why buy instead of build, and what did that call come down to internally? What would you have gotten wrong if you’d tried to build SASE from scratch?
David Bellini: We bought it because Timus SASE already existed and had a superior product. Building it ourselves would have cost us about two years.
The call was short once we looked at what a real build meant. Cloud-native SASE isn’t a feature you add to a product you already have. It’s an architecture decision you make on day one, or you spend years working around the fact that you didn’t. Timus made that decision at the start and got it right. When I say they built the platform we would have built, I’m talking about the architecture, not the feature list.
What would we have gotten wrong? The network. We know identity and access. We’ve spent years on privilege, passwords, and DNS. Secure access looks adjacent to that, and it is, right up until you’re responsible for global gateways, latency, split tunneling, and an always-on agent that users won’t disable because it makes their laptop feel slow. That last part is where most VPN replacements die. People turn the thing off and nobody notices for six months.
The other piece we’d have underestimated is adaptive policy. Deciding once at login is easy. Deciding continuously on behavior and device posture, without throwing so many prompts at people that they stop reading them, is hard, and getting the thresholds right takes real time in production. There’s no shortcut for that.
VMblog: On the consolidation thesis: Your customers are asking to work with fewer vendors. But “fewer vendors” has been a vendor talking point for years while the average security stack keeps growing. What’s actually different now, and where does consolidation genuinely help versus where does it just move the lock-in around?
Bellini: Consolidation helps when it removes work. It doesn’t help when it only removes invoices.
You’re right that it’s been a talking point for a long time while stacks kept growing. Two things changed. Lean IT teams at small and mid-sized organizations got squeezed on budget and headcount at the same time insurance and compliance requirements were forcing more controls on them. So, they’re carrying more tools with fewer people to run them. That’s a different problem than having too many bills.
Consolidation genuinely helps where products answer related questions. Privileged access, passwords, DNS filtering, and network access all come back to who gets to touch what, and from where. Spread that across four vendors and four consoles and a lean team spends its time reconciling separate tools, and the gaps between them are where misconfiguration hides. Bring them under one vendor and you’ve taken real work off the team, not just cut a few invoices.
Where it just moves the lock-in around is the suite play. A vendor bundles six products, two are good and four are shelfware nobody would have bought on their own. Now you’re locked in and you’re not any more secure. My test is that every product in a bundle has to be one you’d buy standalone. If it wouldn’t win on its own, discounting it doesn’t make it worth deploying.
The dashboard problem is real, by the way. A console nobody opens is worse than not having one, because it makes people believe a control is working when no one has looked at it in a year.
VMblog: On the shelfware problem: You’ve talked about security products that get bought and then sit on the shelf. Why does that keep happening at small and mid-sized organizations, and what makes SASE prone to it? How do you know Timus SASE won’t become the thing that ships and never gets deployed?
Bellini: Because buying is easier than deploying, and a purchase order makes the problem look solved. A compliance deadline lands, or an insurance renewal, or a question from the board, and a product gets bought fast to make the finding go away on paper. Then the work of actually deploying and configuring it falls to a team that has no bandwidth for it and is already behind. Six months later there’s a line item on the budget and no coverage in the field.
Vendors are complicit in that. The commission gets paid at signature. Nobody calls in month three to ask how many users are actually protected, because nobody wants that answer.
SASE is more prone to it than most categories because it sits in the path of everyone’s work. Get it wrong and people can’t do their jobs, which is a different kind of risk than a scanner that generates noisy alerts. So teams pilot it on five people, it works fine, and it never goes past those five. Or they turn it on in monitor mode and leave it there for a year because nobody wants to be the person who blocked the CFO.
What protects us is the product itself. It installs in minutes, there’s no appliance, and nothing has to be re-architected to try it, so the usual reasons a rollout stalls aren’t there. Short time to deploy is the biggest lever on whether a tool actually gets rolled out, and that’s the one we pull hardest on.
VMblog: On VPN’s slow death: Timus SASE replaces legacy VPN with a zero-trust connection that’s always-on. VPN has been declared dead for a decade and it’s still everywhere. What actually keeps teams tethered to it, and what finally moves them off?
Bellini: It still works, most days. That’s the whole answer. Nothing that works most days gets replaced on a schedule.
The rest are switching costs. VPN isn’t a product somebody chose and champions. It came with the firewall. It’s wired into the routing, the documentation, and the one application nobody has touched since 2014. Pulling it out means touching all of that, and nobody gets promoted for replacing something that isn’t visibly broken.
The failure mode is invisible too, and that’s the part I’d push on. Legacy VPNs mostly can’t be made always-on, so the decision gets left to the user. People turn it off on hotel Wi-Fi because it’s slow, and usually nobody is checking whether they did. Once they’re disconnected there’s no visibility into what happens, so the admin sees no incidents and concludes everything is fine. Meanwhile credentials are the only thing standing between an attacker and the inside of the network, and once someone is in through the VPN they can move sideways.
What actually moves teams off it is usually a budget event, not a security one. The firewall hits end of life, or the renewal quote comes in higher than anyone expected, and for the first time somebody asks whether the box is still the right answer. Second most common is a questionnaire. Cyber insurance or a customer’s security review asks something VPN can’t answer, like whether access is granted per application and re-checked continuously rather than once at login.
The third trigger is a breach. That one works every time.
VMblog: On the lean IT team reality: You built ConnectWise, so you’ve seen this market up close for a long time. What do most security vendors get wrong about how lean IT teams at small and mid-sized organizations actually buy and run tools day to day?
Bellini: They build for a customer that doesn’t exist. Most security products assume somebody’s job is to run them. A lean IT team doesn’t have that person. The one deploying your product is also handling the helpdesk queue, the laptop refresh, and whatever broke that morning.
So the same things go wrong over and over. Vendors optimize for the demo instead of day 400. Buying is one decision. Deploying any application is hundreds of small decisions across every site, every department, and every exception somebody talks you into. If a product is pleasant to configure once and painful to configure repeatedly, it dies in rollout, and the vendor usually never finds out why.
They also assume there’s a project. Enterprise security gets sold with a consultant, a statement of work, and a rollout measured in months. A team of five doesn’t have a rollout window. They have the two hours between the thing that broke this morning and the thing that’ll break tomorrow. If a product can’t stand up in that time, it doesn’t matter how good it is.
Defaults get set wrong on purpose. Vendors ship permissive defaults so nothing breaks during the trial and assume the customer will tighten things up later. A lean team never gets to later. Whatever you ship on is what runs in production for the next three years.
And pricing that fights the way the customer actually works. Per device pricing, when one person has a laptop, a phone, and a tablet, turns a security decision into a budget argument. Timus SASE is priced per user, which is one of the things that made it fit.
VMblog: On what SASE means for a 5-person IT team: Enterprise SASE is famously heavy to run once it’s live, with policy sprawl and constant tuning that assume a dedicated network security person on staff. What has to be true for a small IT shop to manage this day to day without that headcount, and where does Timus SASE cut the ongoing complexity that usually eats a small team alive?
Bellini: It has to be right on the defaults, and it has to adjust without a human. That’s the requirement.
Enterprise SASE assumes someone on staff who tunes policy as part of their week. A five-person IT team doesn’t have that person and isn’t going to hire one. If a product needs weekly tuning to stay correct, a lean team will stop tuning it, the policy drifts, and a year later you have a control that’s technically deployed and functionally gone.
Three things cut the ongoing work. First, there’s no hardware. Nothing to backhaul traffic through, no appliance to size and refresh, no firmware update at 11pm on a Tuesday. That deletes a whole category of maintenance small teams don’t count as security work but spend real hours on.
Second, policy gets built once and pushed. You build a template and apply it across every site and department from one console instead of rebuilding rules location by location.
Third, the policy engine reacts to behavior and device posture instead of waiting for someone to write a rule for every case. Same with MFA. It prompts when the risk profile warrants it rather than on every login, which matters because MFA fatigue is what turns users into the vulnerability.
The honest test for any of this is what the product looks like after 90 days. If nobody has had to touch it and it’s still enforcing what you set up, it works for a small team. If it wants attention every week, it doesn’t, no matter how the demo went.
VMblog: On what’s next: You closed a growth round earlier this year and said acquisitions were part of the plan. Without tipping your hand, what gap in the stack are you looking at next, and how do you decide what’s worth owning versus partnering for?
Bellini: The pattern we look for is a control that touches the same decision our products already make. Access. Who gets to what, under what conditions. When a product answers that question, it’s worth owning, because access is the core of what we do and not something we want to hand to another vendor’s API. When the technology sits outside that, and the real value is in the integration rather than the product itself, we’d rather partner and keep our engineering on the parts customers hold us accountable for.
Timus passed that test before we ran it. About a quarter of their customers were already running one of our products. That isn’t a projection. That’s the market telling us it was valuable to the portfolio.
What we’re after is what we’ve been after the whole time. Fewer vendors a small to mid-sized enterprise has to trust, more of the stack from one place, and security that gets used instead of sitting on a shelf.
##
