Todyl vs Cato for MSPs: SASE Has to Survive the Ticket Queue

Todyl vs Cato is not really a SASE beauty contest.

For MSPs, the real comparison starts after the sale, when the Windows agent breaks on three laptops, a site tunnel acts weird, DNS filtering blocks a line-of-business app, and the client thinks "secure access" means your team owns the whole mess forever.

Cato and Todyl can both make sense. Cato tends to fit MSPs that need a network-first SASE platform for sites, users, SD-WAN, security inspection, and a centralized policy layer. Todyl tends to fit MSPs that want SASE as one module inside a broader managed security motion with endpoint security, SIEM, MXDR, GRC, and reporting close by.

The useful question is not "Which vendor has more acronyms?" It is this: which platform creates fewer operational surprises for the clients you actually support?

Quick answer: should MSPs choose Todyl or Cato?

MSPs should look at Cato first when the client has multiple sites, network complexity, SD-WAN needs, VPN replacement pressure, and a buyer who expects a serious access and networking platform.

MSPs should look at Todyl first when the MSP wants SASE bundled into a broader MSP security platform that also touches endpoint, SIEM, MXDR, GRC, compliance evidence, and security reporting.

The deciding factor is ownership. If the MSP cannot define who owns endpoint agents, tunnel failures, DNS exceptions, access policy changes, reporting, and after-hours escalation, either platform can become a ticket factory.

Scopable fits before either quote. SASE should come from a scoped client decision, not a vendor demo and a rough seat count. Scopable helps MSPs turn access gaps, security findings, responsibility boundaries, budgets, and client approvals into roadmap items and quote-ready work. Join Scopable early access if your security scope still lives in engineer memory and half-finished PSA notes.

Todyl vs Cato at a glance

Criterion	Cato	Todyl	MSP read
Core shape	Network-first SASE platform with SD-WAN, SSE, ZTNA, site connectivity, and global cloud architecture	MSP-focused security platform with SASE, endpoint security, SIEM, MXDR, GRC, and automation in one product family	Cato is usually the cleaner network architecture conversation. Todyl is usually the cleaner managed security bundle conversation.
Site connectivity	Stronger fit when branch sites, firewalls, private apps, and WAN design matter	Useful for secure access and remote users, especially when the rest of the Todyl stack is already in play	If sites drive the pain, weight Cato higher. If security operations drive the pain, weight Todyl higher.
Endpoint agent risk	Remote users still need client deployment and support, but the buying motion is less centered on an all-in security agent	Todyl's platform story leans into one agent across identity, endpoint, network, and cloud security	One agent is nice until it owns too much blast radius. Test Windows behavior before standardizing.
Support model	Cato promotes MSP programs, MSASE partner tools, and Cato Distinguished Support Provider training	Todyl promotes MSP partnership, 24/7 MXDR access, and close security operations support	The MSP needs to know which tickets go to vendor support and which stay on the help desk.
Reporting	Strong network and security visibility story through the platform	Stronger adjacency to compliance dashboards, SIEM evidence, MXDR cases, and GRC reporting	Match reporting to what the client pays for in QBRs and renewals.
Hardest unwind	Network architecture, site tunnels, access policies, and client traffic paths	Security stack consolidation, endpoint footprint, SIEM data, MXDR process, and reporting history	Both are sticky. Do not pilot casually.

Sources: Cato SASE platform, Cato MSP partner page, Todyl SASE, Todyl platform overview, Todyl for MSPs, and Todyl MXDR.

What Cato is really selling MSPs

Cato is selling a network and security architecture, not just a VPN replacement.

Its public platform language centers on the Cato SASE Cloud Platform, SD-WAN, SSE, ZTNA, private application access, cloud-delivered security inspection, and one policy layer for users, sites, applications, and clouds. Cato's platform page also says the service maintains 99.999% service availability and low-latency security processing for users and locations.

That matters for MSPs with clients who have real network shape: branch offices, factories, warehouses, private apps, Azure or AWS workloads, old firewall rules, and users who move between home, office, and hotel Wi-Fi.

Cato's MSP page is also explicit about partner operations. It references the MSASE Partner Platform, co-branded customer experience, and Cato Distinguished Support Provider training and tools that help partners resolve issues with less outside escalation.

That is the tell. Cato expects serious partners to build real support muscle.

The upside is cleaner architecture for clients whose remote access problem is also a network problem. The risk is that network ownership becomes broad very quickly. If the client hears "SASE," they may assume every access complaint, firewall change, app latency issue, DNS exception, and after-hours outage is included in the monthly fee.

That is how a good platform becomes an unpaid support promise.

What Todyl is really selling MSPs

Todyl is selling an MSP security platform where SASE is one part of the operating model.

Its SASE page says the module includes secure connectivity, cloud firewall, SSL inspection, URL and content filtering, secure DNS, conditional access policies, optional static IPs, automatic failover, and 40-plus global points of presence. Its platform overview describes SASE, EDR/NGAV, SIEM, MXDR, SOAR, and GRC in a single-agent, cloud-native product family.

That is a different pitch from Cato. Todyl is not only asking, "How do users reach apps?" It is asking, "Can the MSP run more of the security program through one vendor relationship?"

For an MSP, that can be attractive. One partner. One agent story. Security data close to SIEM. MXDR cases tied to the same platform. GRC and compliance reporting nearby. That is much easier to explain to an owner than six disconnected security products with six portals and seven ways to create a ticket.

But the same strength creates the risk.

When SASE, endpoint, SIEM, MXDR, and GRC sit in the same vendor conversation, the client may assume the MSP owns the whole security outcome. They may not separate access policy from endpoint investigation, log retention, identity response, compliance evidence, or remediation labor.

The MSP has to separate those things before the client signs.

Endpoint tickets are the category tax

SASE vendors love architecture diagrams. MSP techs live in endpoint tickets.

Remote access only works if the client device behaves. The agent has to install cleanly, survive Windows updates, coexist with EDR and VPN history, handle captive portals, reconnect after sleep, respect DNS policy, and not wreck the user's day every time a hotel network gets weird.

MSP community discussions keep circling the same issue. The practical language is not about category theory. It is about stability, Windows agent behavior, and who eats the tickets. Treat that as directional signal, not proof. The proof comes from your own pilot.

Before standardizing on either vendor, run a controlled pilot with real client devices:

• Windows 10 and Windows 11 laptops with normal client junk installed
• one machine with old VPN software still present
• one remote user with bad home internet
• one Entra-joined or hybrid-joined device
• one user who travels
• one line-of-business app that breaks when DNS changes
• one after-hours support test

A lab demo is useful. A pilot that creates 11 tickets is more useful.

DNS, tunnels, and policy design need boring ownership

The easiest SASE sale is "replace the VPN."

The hard part is everything after that sentence.

DNS filtering can break payroll, scanners, ERP clients, VoIP softphones, vendor portals, and whatever ancient line-of-business app the client forgot to mention. Site tunnels can expose bad routing assumptions. Private app access can reveal that nobody knows who owns the app inventory. Conditional policies can look clean until the warehouse manager cannot reach a timeclock app from a shared kiosk.

Cato is usually stronger when those questions are network design questions. Todyl is usually stronger when those questions are security program questions.

Neither vendor removes the need for policy ownership.

Use a plain responsibility table before the quote goes out:

Workstream	What the MSP must define
Endpoint agent	deployment method, supported operating systems, update process, uninstall rights, and break-fix owner
DNS policy	categories blocked, exception process, emergency bypass path, and who approves business app changes
Site tunnels	supported sites, failover expectations, ISP dependency, firewall retirement plan, and outage contacts
Private apps	app inventory, owner, access groups, testing plan, and acceptance criteria
After-hours support	what triggers a page, who calls the client, and what counts as billable work
Reporting	what proof appears in QBRs, renewals, insurance requests, and compliance reviews

If that table feels annoying, good. It is supposed to. Annoying before signature is cheaper than vague during an outage.

Pair this work with the MSP shared responsibility matrix template and the MSP scope of work template. SASE has too many gray zones to sell from a one-line quote.

Where Cato fits best for MSP clients

Cato is the cleaner first look when the client has network complexity that cannot be solved by another remote access agent.

It fits best when:

• the client has multiple offices, warehouses, clinics, or field locations
• private app access and WAN design matter as much as user security
• the client wants to retire firewall sprawl or legacy VPN appliances
• site reliability, traffic steering, and security inspection need one architecture
• the MSP has enough network skill to own design, rollout, and support
• the buyer values a serious access platform over a broader security bundle

Cato can also fit an MSP that wants a premium network standard. The partner program language around MSASE and support accreditation suggests Cato wants partners who can support customers with less reliance on vendor escalation.

If your network bench is thin, a Cato project may expose the gap. It is not enough to sell the logo. Someone has to design routes, migrate sites, test private apps, manage exceptions, and explain why Monday morning traffic is now different.

For clients already standardizing on Ubiquiti or similar network stacks, compare the SASE decision with your broader network standard. The UniFi Fabrics guide for MSPs is useful because it asks the same boring question: who owns the console, the policy, and the support bill?

Where Todyl fits best for MSP clients

Todyl is the cleaner first look when the MSP wants SASE to sit inside a broader managed security offer.

It fits best when:

• the client wants one security partner conversation instead of several tool decisions
• endpoint, identity, SIEM, MXDR, GRC, and reporting are part of the same roadmap
• the MSP wants compliance evidence and security operations context near access logs
• the security bundle is sold through the MSP, not as client-managed software
• the team values vendor adjacency more than pure network architecture depth
• the MSP is building a repeatable managed security package for SMB clients

Todyl's MSP page talks about threat management, risk management, compliance management, one agent, one interface, and one partner. Its MXDR page talks about 24/7 access through preferred channels, proactive notification, named resources, visibility into open cases, and event context.

That is useful if your client expects a security program, not just remote access.

The risk is bundle fog. When many things live under one vendor name, salespeople can get lazy. "Todyl covers it" is not a scope. Which module covers it? Which users are included? Which logs are retained? Which response actions are pre-approved? Which remediation tasks are separate projects?

If the client also needs Microsoft 365 hardening, do that baseline honestly. The Conditional Access baseline for MSPs keeps identity policy from becoming a vague promise inside a broader security bundle.

Decision table by client type

Client situation	Better first look	Why
Three offices, legacy VPN, private apps, and firewall cleanup	Cato	The buying problem is network architecture plus access control.
Microsoft-heavy SMB that needs security operations, reporting, and compliance evidence	Todyl	The buying problem is a managed security program, not just tunnels.
Warehouse or manufacturing client with site dependency and sensitive latency	Cato	Site design, failover, and private app paths need serious network planning.
MSP building a repeatable SMB security bundle	Todyl	SASE can sit beside endpoint, SIEM, MXDR, GRC, and reporting in one package.
Co-managed client with internal IT and clear network ownership	Cato	Internal IT can help with app inventory, site cutovers, and access policy decisions.
Compliance-driven client that asks for proof every quarter	Todyl or Cato with strong scope	The winner depends on whether proof comes from security operations or network policy.
Small client that only wants cheaper VPN replacement	Neither by default	A lighter ZTNA option may be enough. Do not overbuild because the acronym sounds expensive.

The last row matters. Some clients do not need a full SASE program. They need clean MFA, Conditional Access, device management, basic remote access, and a scope they can afford.

Selling more architecture than the client can operate is not maturity. It is future churn wearing a nice shirt.

Packaging guidance for MSPs

Do not sell SASE as one monthly line item unless the responsibility is already clean.

Split the offer into four buckets.

1. Assessment and design

This is paid discovery. Inventory users, devices, sites, private apps, DNS dependencies, firewall rules, identity groups, line-of-business apps, current VPN users, and after-hours expectations.

If the client will not pay for discovery, they are probably not ready for the project.

2. Migration project

This includes agent rollout, site cutover, policy creation, pilot testing, app testing, user communication, exception handling, acceptance criteria, and rollback planning.

Do not hide this inside monthly service. It is project work.

3. Managed service

This includes routine policy administration, agent health review, basic exception handling, monthly evidence, client reporting, and standard support.

Write the exact limit. "Basic exception handling" can become an unpaid application modernization project if you let it.

4. Paid escalation

This includes after-hours outages, major app failures, urgent tunnel redesign, incident response, remediation, forensic support, compliance evidence packs, and client-requested policy changes outside the agreed cadence.

Put the trigger in writing. The worst time to invent a paid escalation rule is when the CEO cannot reach the ERP system.

For margin discipline, read the MSP pricing and quoting margin guide. SASE can protect the client and still wreck the MSP's margin if the quote treats support load as free.

Final verdict

Pick Cato when the client has real network architecture pain: sites, WAN design, private apps, legacy VPN, firewalls, traffic paths, and a buyer who expects a serious platform behind remote access.

Pick Todyl when the client and MSP want SASE inside a broader managed security program: endpoint, identity, SIEM, MXDR, GRC, compliance evidence, and security reporting tied to one operating model.

Do not pick either until the support boundary is written down.

SASE can reduce ugly access sprawl. It can also create a new category of tickets with a nicer name. The difference is not the acronym. It is whether the MSP scoped the endpoint agent, DNS policy, tunnel ownership, reporting promise, after-hours escalation, and paid cleanup before the client assumed all of it was included.

That is the comparison that matters.