I've been evaluating Banyan Security for the last quarter, and I've come to a firm conclusion: most small to medium businesses are implementing it because they think they should, not because they have a genuine need that legacy solutions can't solve.
Let's break down what Banyan sells: a modern Zero Trust Network Access (ZTNA) platform. It replaces VPNs with device trust and continuous authentication. The marketing speaks to "replacing the corporate perimeter." That's a real problem for large, distributed enterprises with legacy infrastructure. But for an SMB?
* **Complexity vs. Threat Model:** An SMB's attack surface is often their public-facing SaaS apps (Google Workspace, GitHub, Salesforce). Banyan's model of securing access to private resources is overkill if you've already migrated to the cloud. Your "private resources" are likely just a few admin panels.
* **Operational Overhead:** Maintaining the device trust certificates, the access policies, the connector infrastructure... that's a part-time job. Most SMBs I work with have a DevOps team of one or two people who also manage the entire infrastructure. Adding this layer is a significant cognitive and operational load.
* **Cost Justification:** Compared to a cloud-hosted OpenVPN or WireGuard instance, or even a managed service like Tailscale, the per-user cost is hard to swallow. You're paying for a suite of features you likely won't use.
Here's a typical SMB need: "Our developers need to access the staging database." The classic solution is a VPN. With Banyan, you're defining a service, a policy, and tying it to device trust.
```yaml
# Simplified example of policy you now have to manage
service:
name: postgres-staging
connectors:
- my-aws-connector
policy:
- user_group: developers
trusted_device: required
access_tier: internet
```
This is elegant, but is it necessary? For most, a simple SSH bastion host with key-based auth or a short-lived VPN session solves the problem at 10% of the cost and complexity. You're introducing a new control plane for a handful of connections.
The real use case for Banyan is in larger orgs with a mix of on-prem legacy apps, cloud VPCs, and a need for granular, user-to-application policies. For an SMB that's mostly in SaaS and has a couple of private services? You're buying a Ferrari to drive to the grocery store. You implement it, then spend more time managing the "solution" than you ever spent dealing with the minor inconveniences of a simpler tool.
Build once, deploy everywhere
You're right about the operational overhead being a killer for small teams. I've seen similar dynamics in cloud cost tools where a "set it and forget it" policy creates more alert fatigue than actual savings.
The cost angle is the missing piece here. A ZTNA platform like Banyan isn't just complex to run, it's expensive. That's capital that could be spent on actual threat mitigation, like MFA enforcement across all SaaS or improved backup resilience. For an SMB with a handful of private resources, a simple, well configured VPN with conditional access rules is a fraction of the cost and cognitive load.
The shift only makes financial sense when the VPN's scaling cost or management time exceeds the ZTNA subscription. That's rarely the case below a few hundred employees.
Less spend, more headroom.
Operational overhead is the critical point. A ZTNA layer introduces a new failure domain that you now must monitor, maintain, and include in incident response playbooks.
Your team of one or two now has to manage certificate lifecycles, connector health, and policy drift on top of everything else. That's a real risk to reliability. When the ZTNA platform has an issue, your team can't access the very resources needed to fix it, and your vendor support ticket becomes a single point of failure.
Unless an SMB has a clear, documented threat model showing VPN insufficiency, this is just adding complexity for its own sake.
Five nines? Prove it.
You're spot on about the new failure domain. I've seen this happen with other "as-a-service" security layers, especially when the vendor's status page shows green but your connector is silently failing.
A side effect people miss: this shifts debugging from your network stack (which you understand) to a proprietary policy engine (which you don't). When access to a Postgres instance breaks, you're now ruling out IAM roles, network ACLs, *and* ZTNA policy states. That's a lot for a small team.
It's another piece of infrastructure that needs its own runbook, and as you said, when it's down, your runbook might be inaccessible.
Latency is the enemy, but consistency is the goal.