SASE vs. On-Prem: Where the Dollar Crossover Actually Sits

Two models, defined precisely

Before any cost conversation makes sense, the two architectures need to be described the way they actually get built, not the way they get pitched. "On-prem" and "SASE" get used loosely enough in vendor decks that two people can say both terms and mean different things.

On-prem, in the form most mid-size and enterprise networks actually run today, means a firewall or router appliance at every site, sometimes a pair for redundancy, terminating WAN transport that is either MPLS with carrier-managed QoS or an SD-WAN overlay running across broadband, LTE, or a mix of circuits. From there, security enforcement happens one of two ways. Either the site has a full local security stack (NGFW doing content inspection, maybe a local SWG or proxy, maybe local DLP), or the site has a thin router/firewall doing basic segmentation and everything that needs real inspection gets backhauled, or hairpinned, across the WAN to a regional hub or data center where the full stack lives. Hub-and-spoke MPLS designs from the 2010s are almost all built this second way, because putting a full NGFW at forty branch offices was never going to pencil out even before SASE existed as a category.

SASE, precisely, is the combination of SD-WAN (or, increasingly, no dedicated overlay at all, just internet transport with a lightweight client or on-ramp) and a cloud-delivered security service edge: secure web gateway, CASB, ZTNA in place of or alongside traditional VPN, and firewall-as-a-service, all enforced at a nearby cloud point of presence rather than on hardware you own and patch. The traffic still has to go somewhere for inspection; that part of the physics doesn't change. But "somewhere" is a PoP the vendor operates and scales, reachable over the public internet with, ideally, a handful of milliseconds of added latency, instead of a hairpin back to a data center you built.

The distinction that actually drives the cost model is this: on-prem cost is anchored to sites. SASE cost is anchored to users. Everything else in this article follows from that one structural difference, so it's worth sitting with before we get into line items.

It's also worth naming why the industry ended up with two competing models instead of one obviously correct answer. Hub-and-spoke MPLS with hairpinned inspection made complete sense in an era when most application traffic was destined for a data center you owned: email server, ERP database, file shares, all sitting in the same building the hub was built to protect. Backhauling branch traffic to that hub wasn't overhead, it was the direct route. What broke the model wasn't a security flaw, it was where the applications moved. Once email, CRM, file storage, and most line-of-business software migrated to SaaS and public cloud, the hub stopped being the destination for most traffic and became a detour on the way to somewhere else entirely: a branch office in Ohio inspecting its Salesforce traffic by routing it through a data center in Virginia before it turns around and heads back out to a SaaS provider it could have reached directly. SASE exists because someone asked the obvious question: if the destination isn't the hub anymore, why is the inspection point still there? That history matters for the cost conversation because it explains why the crossover isn't fixed. It moves further toward SASE every year that more of a company's application footprint leaves its own data centers, independent of anything vendors do on pricing.

Why "SASE is cheaper" is true — under specific conditions

The claim isn't wrong. It's underspecified. SASE wins the economics decisively in three situations, and the reason is the same in all three: the cost driver that on-prem can't avoid, a physical site needing physical hardware and physical labor, either doesn't exist or stops scaling the way it used to.

A high remote or hybrid workforce ratio

A remote employee isn't a site. There's no branch to wire, no appliance to rack, no local circuit to provision, no truck roll when the appliance fails at 11 p.m. on a Friday. Under the on-prem model, remote users get handled by VPN concentrators back to a data center or hub, which means their traffic is backhauling regardless, adding latency and consuming central bandwidth, and the VPN infrastructure itself becomes a site-equivalent cost center that has to scale with headcount, not with any physical footprint. Under SASE, a remote user connects to the nearest cloud PoP and gets the same inspection and policy as someone sitting in a branch, with no incremental site cost at all. Every percentage point of a workforce that shifts from fixed office to remote or hybrid moves the math further toward SASE, because the marginal cost of that user drops to a license fee instead of a fraction of a site build.

Many small sites

This is the one people underestimate. A ten-person branch office and a three-hundred-person headquarters cost roughly the same to wire for on-prem security: same firewall pair, same install visit, same ongoing patch and lifecycle management, same WAN circuit provisioning overhead. But the ten-person branch is amortizing that cost over a fraction of the users. Retail chains, bank branches, insurance agencies, clinics: any org whose footprint is dozens or hundreds of small locations is paying full per-site fixed cost at every one of them. SASE removes the per-site floor almost entirely. A small site becomes a cheap internet circuit and however many licensed seats sit there, no local appliance required at all in a lot of designs, or at most a low-cost SD-WAN edge device with none of the inspection stack riding on it.

Consolidation of point products

Most networks that have been running security architecture for more than five years are carrying separate contracts and separate appliances for things a SASE platform bundles: a secure web gateway or proxy, a CASB for SaaS visibility, some flavor of remote access (classic VPN, maybe a bolt-on ZTNA product), and firewall inspection, frequently from three or four different vendors with three or four different renewal dates and three or four different consoles that don't talk to each other. Collapsing that into one licensed SASE stack doesn't just save the line-item cost of the redundant contracts. It saves the engineering hours spent keeping four policy engines in sync, which is a real and recurring labor cost that almost never shows up in a TCO worksheet.

All three conditions point the same direction: the more a network's cost is currently driven by sites that exist for their own sake rather than by users doing work, the more SASE compresses it. And they compound rather than simply adding up. A retail chain with mostly small sites and no remote workforce still gets the site-count benefit even with a near-zero remote ratio. A professional services firm with three offices and a mostly remote staff gets the remote-workforce benefit even though it barely has a site-count problem at all. The organizations where the case is loudest are the ones stacking two or three of these conditions at once: many small sites and a growing remote share and a security stack that's aged into overlap-worthy redundancy. Those are the engagements where the numbers stop being a judgment call and start being obvious on a single spreadsheet tab.

Why "SASE is a tax" is also true — on certain networks

The counter-claim is just as true, on the networks where the conditions above run the other direction.

Sustained high local bandwidth

Manufacturing floors, distribution centers with heavy machine-to-machine traffic, video production, OT environments doing sustained sensor or camera telemetry: anywhere with real, continuous local bandwidth needs pays a structural cost under SASE that doesn't exist under a local security stack. Everything that needs inspection has to leave the site, cross the internet to a PoP, get processed, and come back, before it can even reach its actual destination if that destination is also local. For traffic that's site-to-site or site-to-cloud, that's a tolerable few milliseconds. For traffic that's genuinely local, a machine talking to another machine forty feet away, both on the same LAN, hairpinning it out to a cloud PoP and back is pure overhead with no security benefit proportional to the latency cost, and depending on the platform's egress and inspection pricing model, it can also mean paying to inspect bandwidth that never needed to leave the building. This is the scenario where a local NGFW doing wire-speed inspection at the site is doing something a cloud PoP structurally cannot do as cheaply: sit directly in the path.

Recently purchased, not-yet-depreciated hardware

If a site refreshed its firewall pair eighteen months ago on a five-year depreciation schedule, walking away from that hardware to move to SASE means eating the remaining book value as a write-off, on top of whatever the SASE licensing costs going forward. That's not an argument against SASE being the better long-term architecture. It's an argument that the crossover, for that specific site, sits a few years further out than the industry-average conversation implies. We've had clients look at that math and correctly decide to let the refresh cycle run out before converting, which is the right call, not a failure of nerve.

MPLS contracts with real remaining term

Carrier MPLS contracts commonly run three to five years, and early termination on a multi-site MPLS agreement is rarely trivial. It shows up as a real penalty line, sometimes sized to a meaningful fraction of the remaining contract value. An org eighteen months into a four-year MPLS term is not comparing "SASE cost" to "on-prem cost" in a vacuum; they're comparing "SASE cost plus an early-termination penalty" to "keep paying for MPLS I've already committed to." That changes the answer, and it's a category of cost that a generic industry TCO comparison almost always leaves out because it's contract-specific rather than architecture-specific.

None of these three conditions is a permanent objection to SASE. They're each a reason the crossover, for a specific site or a specific contract, sits later than the general trend line, and a reason the recommendation has to be made site by site rather than as a company-wide verdict.

There's a fourth condition worth naming even though it's softer than the other three: operational maturity around the existing on-prem stack. A team that has run the same NGFW platform for a decade, has its change-management process built around that platform's console, and has staff who can troubleshoot it half-asleep is carrying real institutional capability that a SASE conversion resets to zero. That's not a cost line you can put in a spreadsheet, but it's a genuine switching cost: retraining, rebuilding runbooks, re-earning the operational confidence that comes from having broken something and fixed it before. It doesn't override a clear crossover in either direction, but on a close call, it's a legitimate tiebreaker toward staying put, or toward bringing in a managed partner who already carries that institutional knowledge on the new platform so the org isn't rebuilding it from scratch.

The cost categories, in detail

Here's the full list of cost buckets that actually belong in this comparison. Most TCO conversations we sit in on miss at least two of these, usually the ones without a clean line item on an invoice.

Circuit costs

MPLS transport with carrier-managed QoS costs meaningfully more per megabit than commodity internet transport, because the carrier is selling you guaranteed performance and a managed SLA, not just bandwidth. SD-WAN over broadband, LTE, and fiber blends is cheaper per megabit but pushes the QoS and path-selection work onto your edge device instead of the carrier's network. SASE architectures typically lean on internet-only or SD-WAN transport, which is part of where the savings come from. But it means the quality-of-service story for latency-sensitive traffic (voice, video conferencing, some ERP transactions) now depends on your SD-WAN policy and the SASE vendor's PoP proximity, not a carrier SLA. That's a real trade, not a free lunch.

Appliance capex and the refresh cycle

On-prem firewall and router hardware runs on a refresh cycle, commonly landing somewhere around five years before performance, support, or vendor end-of-life forces a replacement, and that capex is lumpy: a big outlay at refresh time, then several years of comparatively low incremental cost, then another big outlay. SASE licensing runs the opposite shape: flat, predictable, recurring per-user cost with no capex spike. Whether that's better depends on how your organization prefers to carry cost. Some finance teams strongly prefer converting capex to opex, some have the opposite preference for tax or budget-authority reasons, but it's a real structural difference worth naming explicitly rather than assuming everyone wants the same shape of spend.

Local install and engineering labor

Every physical site is a labor event: initial install, periodic maintenance visits, and, the one people forget until it happens, an emergency truck roll when hardware fails and there's no one on-site who can swap it. That labor cost scales with site count, and it scales worse in geographies where qualified field techs are scarce or travel is expensive. A hundred-site retail footprint spread across small towns pays a very different labor premium per site than a hundred-site footprint concentrated in three metro areas, even with identical hardware.

Backhaul and hairpin latency, as a business cost, not just a technical one

This deserves to be pulled out separately because it's chronically underweighted. When a hub-and-spoke on-prem design hairpins branch traffic to a data center for inspection, that added round-trip isn't just a number on a ping test. It's added latency on every application transaction that traverses it, and for latency-sensitive workloads (VoIP, video, certain SaaS and ERP front ends, real-time inventory lookups at a point of sale) that translates into measurable user-facing slowness: slower checkout, choppier calls, users routing around the sanctioned path with shadow IT because the official one is annoyingly slow. The cost of that isn't on an invoice. It shows up as lost productivity and, in retail and hospitality environments specifically, as measurable transaction friction. SASE's promise here is enforcement at a nearby PoP instead of a distant data center, which, when the PoP actually is nearby (not universal), genuinely cuts this cost. It's a real advantage, but it's only real if the vendor's PoP footprint actually covers where your users and sites are.

Per-user SASE licensing

This is the cost shape that makes SASE fundamentally different from on-prem rather than just a cheaper version of it: cost scales with headcount, not with site count or circuit count. That's a feature for a distributed or remote-heavy workforce and a liability for a site-dense, headcount-light operation. A warehouse with forty employees and enormous local bandwidth needs is a case where per-user licensing doesn't capture the actual cost driver, bandwidth and local inspection load, at all.

Security-stack overlap and sunk cost

If you're carrying live NGFW subscriptions, SWG contracts, and CASB licenses across your current site fleet, a SASE conversion doesn't zero those out on day one. You're paying for the new stack while the old contracts run out, unless you can time the conversion to contract renewal dates, which is exactly the kind of planning input a real scoping exercise gathers up front, and which we come back to later in this article. That overlap window is real cost, it's temporary, and it's the single biggest reason a SASE business case that looks great over five years can look mediocre in year one. Anyone building a board-level cost case needs to show both numbers, not just the steady-state one.

Cloud-delivered-inspection egress and bandwidth cost

Naive comparisons routinely stop at "per-user license fee" and forget that inspected traffic volume itself can carry cost under a SASE model, either directly, through bandwidth or data-processing charges built into certain SASE pricing tiers, or indirectly, through the internet transport needed to reach the PoP in the first place. A site with genuinely heavy sustained traffic, the same OT and manufacturing profile flagged above, needs this line item modeled explicitly, not assumed away because "it's all in the per-user fee."

The table reads cleanly by row, but the categories don't stay in their lanes in practice. They trade off against each other, and a comparison that treats them as independent line items will misprice the total. A site with an aging appliance nearing end-of-support pulls the capex row toward SASE (the refresh spend is coming regardless, so it isn't really a switching cost at all), while its bandwidth profile might pull the egress row toward on-prem. A site with a fresh MPLS renewal locks in the transport row for on-prem for another few years, while its headcount growth pulls the licensing row toward SASE. None of this resolves into a single "SASE wins" or "on-prem wins" statement in the abstract. It resolves per site, which is exactly why the next section builds the comparison at that level instead of trying to net all eight categories into one company-wide number.

A method for finding your own crossover, not a number to trust

We're not going to hand you an industry-average dollar figure here, and you should be skeptical of anyone who does, because the real inputs vary by carrier, region, vendor, contract term, and negotiated rate to a degree that makes a universal number close to meaningless for budget purposes. What's actually useful is a formula you can run with your own numbers, site type by site type, because almost no real organization has one uniform site profile, and running this as a single company-wide comparison is where most naive TCO exercises go wrong.

For a given site type, the comparison looks like this:

• On-prem side: fully-loaded monthly cost equals circuit cost, plus amortized appliance capex spread over its refresh cycle, plus amortized install labor, plus ongoing support and subscription cost, plus any allocated share of hub or data-center inspection infrastructure if this site backhauls to one.
• SASE side: fully-loaded monthly cost equals per-user license cost multiplied by users at that site, plus any remaining local transport still needed (a lightweight SD-WAN edge device and circuit, since SASE doesn't eliminate the need for a network connection, just the need for local inspection hardware), plus estimated egress and bandwidth cost if the site's traffic profile is bandwidth-heavy, plus temporary overlap cost with existing security contracts, front-loaded into whichever year the conversion happens.

Once you have both monthly figures for a site type, the crossover isn't a mystery, it's arithmetic: whichever side is lower, at that site's actual user count and actual bandwidth profile, wins for that site type. The reason this has to be done per site type rather than once for the whole company is that the two sides of the equation respond to completely different variables. On-prem cost is roughly flat regardless of headcount at a site and scales with site count. SASE cost is roughly flat regardless of site count and scales with headcount. A company with wildly different site profiles, a headquarters with three hundred people, a dozen ten-person branches, and two hundred remote employees, doesn't have one crossover point. It has at least three, and possibly a different answer for each.

An illustrative way to see why: say a site's fully-loaded on-prem cost runs on the order of some fixed dollar figure per month regardless of how many people sit there, and a SASE seat runs on the order of some fixed dollar figure per user per month. As a purely illustrative example, not a market rate, if the fixed site cost happens to be forty times the per-user SASE rate, then any site with more than roughly forty users sitting at it is cheaper to run on-prem, and any site with fewer than forty is cheaper to run on SASE, all else equal. The actual ratio for your organization could be ten, could be two hundred. It depends entirely on your negotiated circuit rates, your hardware refresh economics, and your SASE vendor's per-seat pricing tier, none of which we're going to guess at on your behalf. What matters is that the ratio is a number you can calculate from your own contracts in an afternoon, and once you have it, the question of how many users a site needs before on-prem wins answers itself.

A few adjustments worth making to the raw formula before you trust it:

• Weight bandwidth-heavy sites by adding an explicit egress and hairpin-latency cost estimate to the SASE side rather than assuming it nets to zero. It usually doesn't, for OT- or video-heavy locations.
• Model the overlap window separately from the steady state. A three-year view and a steady-state, year-four-and-beyond view will often point in different directions, and both numbers matter to whoever signs the budget.
• Check contract end dates before finalizing anything. A crossover calculation that ignores eighteen months of remaining MPLS term or an early-termination penalty isn't wrong in principle, it's just answering a different question than what should happen this fiscal year.
• Run the comparison twice: once assuming today's headcount and traffic, and once assuming where the site is headed over the next two to three years. A branch that's growing headcount fast can cross from "SASE wins" to "on-prem wins" within a single budget cycle, and the reverse happens just as often when a site is being consolidated or downsized. Sizing the decision to a snapshot instead of a trajectory is one of the more common ways this analysis goes stale within a year of being finished.

The question worth asking isn't whether SASE is cheaper. It's cheaper than what, at which of your sites, over what time horizon, accounting for what you've already paid for. Any answer shorter than that is a marketing claim, not a cost analysis.

Three illustrative scenarios

These are hypothetical composites built to show how the reasoning above plays out differently by profile, not case studies, not sourced figures, and not a prediction of what any specific organization will find. Treat the numbers as placeholders standing in for small, medium, and large, not as real pricing.

Scenario one: the small regional retailer

Picture roughly ten sites, each a modest storefront with a handful of point-of-sale terminals and a back-office workstation or two, low bandwidth needs, and a workforce that is essentially entirely on-site: retail staff don't work from home. Each site currently runs a small firewall appliance and a business-grade circuit. Total headcount across all ten sites might be seventy or eighty people.

Run the formula: on-prem cost here is driven almost entirely by the per-site fixed costs, ten circuits, ten appliances on a refresh cycle, ten sets of install and maintenance labor, spread across a workforce that's small relative to the site count. SASE cost, by contrast, is driven by a total headcount of under a hundred users. Because this profile has many small sites relative to total users, the exact condition flagged earlier as favoring SASE, the crossover reasoning points toward SASE fairly clearly, especially once you fold in that ten separate small-appliance refresh cycles and ten separate vendor relationships carry real coordination overhead that a single SASE console removes. The caveat: if store hardware was refreshed recently and MPLS or business-circuit contracts have real term left, the near-term math softens even though the direction doesn't change.

Scenario two: the distributed manufacturer

Picture a few hundred small-to-midsize manufacturing and distribution sites, each with real OT equipment (PLCs, sensor networks, machine vision systems, sometimes video surveillance feeding local recording), generating sustained local bandwidth that mostly needs to talk to other local equipment, not the internet. Workforce is on-site by necessity; nobody remotes in to run a stamping press.

This is the profile where the "SASE is a tax" reasoning applies hardest. The site count favors SASE on paper, many sites is usually a point in its favor, but the bandwidth profile cuts the other way hard enough to dominate the calculation: sustained high local, machine-to-machine traffic that would gain nothing from cloud inspection and would pay a real latency and egress cost for the privilege of leaving the building. For this profile, a full move to cloud-delivered inspection at every site is very likely to land as a net cost increase once egress and latency-driven productivity cost are modeled honestly, not just a wash. The more defensible reasoning path here is SASE for whatever's genuinely internet-bound or remote, corporate email, SaaS access, remote vendor support sessions, paired with retained local inspection for OT and machine-to-machine traffic. That's not a failure to commit to SASE; it's correctly reading a bandwidth profile the category wasn't built to optimize.

Scenario three: the remote-first company

Picture a company with two or three physical offices, really just meeting and collaboration space, and a workforce that's eighty or ninety percent remote or hybrid. There's barely a site fleet to speak of; most cost, under either model, is going to be driven by users, not locations.

This is the cleanest case in either direction, and it points hardest toward SASE. Under the on-prem model, this company would already be paying for VPN concentrator capacity that scales with headcount, functionally already carrying a user-scaled cost structure, just through a worse mechanism, since classic VPN doesn't give the granular per-app access control or inspection that ZTNA does. Moving to SASE doesn't introduce a new cost shape here so much as replace an already user-scaled cost with a better-architected, purpose-built one. The two or three physical offices might keep a small local stack if there's a specific reason to, a data-center dependency, a compliance requirement, but the company-wide architecture decision is not a close call.

The hybrid reality

Almost none of the migrations we actually scope end up as a clean, all-or-nothing conversion. The honest pattern, across nearly every client engagement we've run this analysis for, is a hybrid: SASE covering the remote workforce and the small-site majority, with on-prem stacks retained or right-sized at a minority of sites that have a real bandwidth need, a real contractual lock-in, or both.

That's not a failure to fully commit, and it's not a consulting hedge to avoid giving a straight answer. It's what the site-by-site math in the last two sections actually produces once you run it honestly across a real, mixed site inventory instead of asking one company-wide yes-or-no question. The mistake we see most often isn't organizations landing on a hybrid architecture. It's organizations discovering they need one only after they've already signed a company-wide SASE contract sized for full coverage, or after they've decommissioned on-prem hardware at a site that genuinely needed to keep it.

The fix is architecting for the mix from day one. That means designing the SASE policy framework, the identity and access model, and the network segmentation plan so that a site running local inspection today and a site running cloud-delivered inspection sit inside one coherent policy structure, not two separate ones that happen to be procured from the same vendor. Concretely, that usually means a single ZTNA and identity layer that doesn't care where enforcement happens, consistent segmentation policy expressed once and pushed to both cloud PoPs and local appliances, and a site-tagging scheme in whatever orchestration or management plane you're using so that "this site is on-prem, this site is SASE, this site is transitioning" is a known, queryable state rather than tribal knowledge. Get that structure right at the start, and a site moving from one enforcement model to the other later, because its bandwidth profile changed, or a contract finally lapsed, or the business grew past the crossover point, becomes a configuration change, not a second migration project.

We've watched organizations skip this and pay for it twice: once for the initial SASE rollout, and again eighteen months later re-architecting the policy layer because it was built assuming full conversion and a handful of stubborn sites broke the model. Planning for a permanent minority of on-prem sites, even before you can say exactly which ones, costs almost nothing extra up front and saves a full re-architecture later.

There's an operational dimension to the hybrid reality too, separate from the architecture question: running two enforcement models means someone has to actually operate both, which is a staffing and skills question as much as a technical one. A team that's spent years going deep on one NGFW platform now needs enough SASE fluency to run policy on both sides, or the organization needs to bring in a partner who already carries both skill sets. This is where a lot of internal SASE projects quietly stall, not because the architecture was wrong, but because the team scoped the migration and not the ongoing operating model that follows it. Because we run these platforms as a managed service, we design the hybrid split the way it'll actually get staffed and supported day to day, not just the way it maps out cleanly on an architecture diagram.

What we actually gather before giving a recommendation

Most shops will sell you the new platform. We move you onto it, which means before we'll put a crossover recommendation in writing for a client, we go get the inputs that actually determine the answer, because a generic industry number is worth roughly nothing against a real, mixed site inventory. The inputs, specifically:

• Full site inventory. Not a rough count: every site, its current hardware, its current circuit type and provider, and its headcount. This is the raw material for the per-site-type math; without it, everything downstream is guesswork.
• Bandwidth profile per site. Sustained utilization, not just circuit size. A site with a large circuit that's mostly idle behaves very differently in this analysis than a site with the same circuit running near saturation from OT or video traffic. We look at actual flow data where it exists, not the number on the original circuit order.
• Existing contract end dates. MPLS terms, appliance support and subscription renewal dates, SASE-adjacent point-product contracts such as SWG, CASB, and VPN concentrator support, all of it, because the timing of a conversion against these dates is frequently what separates a business case that looks good on paper from one that's actually fundable this fiscal year.
• Remote-work ratio, measured, not assumed. Badge or VPN login data over a real window, broken down by site or team where possible. "We're mostly remote now" and an actual sixty-forty split are different inputs, and the gap between perception and measured reality is often bigger than clients expect going in.
• Current security-stack depreciation schedule. What's on the books, what's already been written down, what still has real remaining value. This is the input that determines how bad the year-one overlap cost actually looks, and it's usually sitting in a finance system nobody on the network team has looked at.

Once we have those five things, we build the same per-site-type comparison laid out earlier in this article, except with real numbers instead of illustrative placeholders, and because we run these platforms as a managed service on the other side of the conversion, we're not incentivized to oversell one direction. A site that should stay on-prem for another three years stays on-prem for another three years; we'd rather manage that estate correctly than force a conversion that makes the wrong site type worse. The recommendation that comes out the other end is specific to the client's actual contracts, actual traffic, and actual workforce, which is the entire point of doing this exercise instead of trusting a percentage figure from a vendor's TCO calculator that was built to make one platform look good against a generic average network that doesn't resemble yours.