A SASE proposal and an on-premises firewall proposal rarely use the same unit of measure. One may be priced by users and remote-network bandwidth. The other may be priced by appliance, support term, and security subscription. Comparing the totals without normalizing those units is how a tidy spreadsheet produces a bad decision.
Start by separating architecture from product packaging. Zero trust does not require traffic to be inspected in a vendor cloud. NIST describes zero trust as removing implicit trust based on network location and making access decisions around users, devices, and resources. A cloud-delivered security service can support that model, but so can controls deployed on infrastructure you operate. The design question comes first; the commercial model comes second.
Define the comparison
Write down the controls both options must provide. Include secure internet access, access to private applications, DNS security, firewall policy, threat prevention, data controls, logging, high availability, and the management functions your team needs. If one quote includes endpoint software or digital-experience monitoring and the other does not, either add the missing capability or remove it from both sides.
Be equally precise about “on-premises.” It may mean appliances at every branch, regional hubs, virtual firewalls in colocation facilities, or a smaller private edge combined with cloud-delivered controls. The useful comparison is between two complete target designs, not between two labels.
Collect evidence before prices
Use measured traffic and current contracts. Gather at least 30 days of utilization for each site, including peaks and application destinations. Count named users, concurrent users, contractors, service accounts, and shared workstations separately. Map private applications, where they are hosted, and which users or systems need them.
Then collect the financial constraints that are easy to overlook:
- circuit terms, cancellation charges, and renewal dates;
- remaining depreciation or lease obligations on current hardware;
- support and security-subscription renewal dates;
- colocation, power, and remote-hands costs;
- logging storage and retention;
- identity, endpoint, and monitoring licenses required by either design; and
- the months in which old and new services will run together.
Public price lists are not enough. Enterprise discounts, minimum quantities, regional editions, add-ons, and renewal caps can change the result. Use written quotes for the same term and ask each vendor to state the licensing metric. For example, current Prisma Access documentation defines a mobile-user unit as one user and a remote-network unit as 1 Mbps. Other products and contract editions use different measures.
Build one cost model
Use a common evaluation period—usually the term you can price with confidence—and keep one-time migration cost separate from recurring cost. A basic model can be expressed as:
On-premises recurring cost
= circuits
+ annualized hardware and support
+ security subscriptions
+ facilities and remote hands
+ operations and after-hours coverage
+ logging and monitoring
SASE recurring cost
= user licenses
+ site or bandwidth licenses
+ access circuits and edge equipment
+ required add-ons
+ operations
+ logging and monitoring
Transition cost
= design and implementation
+ parallel service
+ contract termination
+ application remediation
+ training and documentation
Do not hide internal labor because it is already budgeted. Estimate the hours spent on policy work, upgrades, hardware replacement, incident support, carrier coordination, and user troubleshooting. Use the same loaded labor rate on both sides. If a managed service replaces some of that work, subtract only the tasks the contract clearly transfers.
Model growth and failure cases. What happens if user count rises by 20 percent? If a manufacturing site needs twice the expected bandwidth? If traffic must stay in a specific region? If an acquisition adds a second identity provider? A design that is slightly cheaper at today’s count may be more expensive under the change you already expect.
Run the technical tests
Cost does not rescue a design that cannot carry the applications. Test from the locations and devices that matter, during busy periods. Record latency, packet loss, tunnel stability, failover behavior, and the time to reach private and public applications. Include large file transfers, voice and video, authentication, software updates, and any protocols that do not behave like ordinary web traffic.
Inspect routing and failure behavior. Know where traffic goes when a cloud point of presence, tunnel, identity provider, or local circuit fails. Confirm whether users fail closed or fail open, and who can change that behavior. For branches, verify the minimum and maximum bandwidth constraints in the proposed service rather than assuming capacity is elastic.
Finally, test the operating model. Can your team find the cause of a slow application? Can it export raw logs? How are emergency policy changes approved? Which configuration is portable if the service ends? Those questions affect cost because weak visibility turns ordinary troubleshooting into paid escalation.
Make the decision reversible
Many networks land on a mixed design: cloud-delivered access for users and smaller sites, with local inspection for data centers, industrial networks, or high-throughput locations. That is not a failed migration. It is often the result of treating different traffic paths according to their actual constraints.
Write down the assumptions that determined the choice. Tie each assumption to a measurable trigger: user count, bandwidth, contract date, application move, or staffing level. Review the model when one of those triggers changes. A cost model is most useful when it can tell you when the original decision has stopped being true.
Sources
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 1800-35: Implementing a Zero Trust Architecture
- Palo Alto Networks: Prisma Access licensing
- Palo Alto Networks: remote-network bandwidth allocation
Source note: The vendor documentation is used to verify licensing units and technical constraints, not to compare prices. Obtain current quotes and contract terms for any financial decision.