Home Resources FortiGate vs Palo Alto Central management
FortiManager vs Panorama for an MSP estate
Every comparison of these two platforms is written for one enterprise managing its own firewalls. An MSP needs something different: strict separation between customers, delegated administration, and reporting that carries your name rather than the vendor's. This page is written for that reader.
The short answer
Both platforms do centralized policy, centralized configuration and centralized logging competently. A feature-count comparison between them is a poor use of an evaluation.
For an MSP the deciding factors are three. How cleanly the platform separates one customer from another. How precisely administration can be delegated. Where the logs physically land, since that determines what you can report and what you can promise a customer with data obligations.
Answer those three against the customer estate you expect in three years. The platform follows from the answer.
How each organizes devices
The two platforms use a different unit of grouping, and that unit shapes everything else.
FortiManager
FortiManager organizes managed devices into administrative domains. A domain holds its devices, its policy packages and its objects. Administrators are scoped to the domains they are permitted to work in, which makes the domain the natural boundary for a customer.
Where the managed FortiGates use virtual domains, the mapping becomes more granular. A single appliance can present separate virtual domains, and those are managed and licensed individually.
Panorama
Panorama separates policy from device configuration. Device groups carry the security policy and objects, arranged in a hierarchy so that common policy can sit above specific policy. Templates and template stacks carry the device configuration, including interfaces, routing and network settings. Access domains scope administrators to specific device groups, templates and virtual systems.
The separation of policy from device configuration is the structural difference worth understanding. It allows one customer's network configuration to change without touching their policy, and it means a complete customer definition spans at least two constructs rather than one.
Organization and administrative models taken from Fortinet's FortiManager administration guide and Palo Alto Networks Panorama administration documentation, checked 8 August 2026.
Separating customers
Separation is the requirement that makes this an MSP question rather than an enterprise one.
State the requirement precisely before evaluating either platform. An administrator working on customer A should be unable to see customer B's policy, objects, logs or device inventory. A report generated for customer A should contain no reference to any other customer. An error made in customer A's configuration should be incapable of reaching customer B's devices.
Both platforms provide mechanisms for this, and both are configurations rather than guarantees. The distinction matters. A platform that supports separation and is deployed without it provides none.
| Requirement | FortiManager | Panorama |
|---|---|---|
| Unit of customer separation | Administrative domain | Device group, with a template stack for device configuration |
| Administrator scoping | Administrators assigned to permitted domains | Access domains mapping administrators to device groups, templates and virtual systems |
| Object separation | Objects held per domain, with a global layer available | Objects held per device group, inherited down the hierarchy |
| Policy separation | Policy packages per domain | Rules per device group, with shared rules above and below |
| Log separation | By domain, with retention configured per domain | By device and device group, with collector configuration determining storage |
| Per-customer reporting | Scheduled reports scoped to a domain | Scheduled reports scoped to devices or device groups |
| Role granularity | Role-based administration with per-domain profiles | Role-based administration combined with access domains |
Mechanisms described from vendor administration guides, checked 8 August 2026. This table describes what each platform provides. It makes no claim that either arrangement satisfies a particular compliance regime, because that assessment depends on the customer's obligations and on how the platform is actually configured.
Two questions are worth putting to a vendor in writing during an evaluation, because the answers are specific and rarely volunteered.
- Which objects, if any, are visible across separation boundaries by default, and can that be changed?
- What does an administrator scoped to one customer see in the audit log, the task queue and the device inventory?
Shared policy, local exceptions
Every MSP estate reaches the same shape. Most policy is common across customers, and a minority is specific to one. How each platform handles that determines how much work each new customer costs.
Panorama expresses it through the device group hierarchy. Rules can sit above a device group's own rules and below them, so common policy is authored once at a higher level and the customer's own rules sit between. Rules defined locally on a firewall are evaluated in a defined position relative to the pushed rules.
FortiManager expresses it through policy packages, with a global layer available for policy that applies across domains. Common policy is authored in the global layer and installed alongside the domain's own package.
The design work is the same on both platforms and it is worth doing carefully. Decide which policy is genuinely universal, which belongs to a class of customer, and which is specific to one. That hierarchy is easy to change with three customers and expensive to change with thirty.
One rule earns its place in the runbook. A change to shared policy affects every customer inheriting it, so shared policy needs a change process that matches its blast radius. Treat a shared-policy change as a change to every customer rather than as one change.
Where the logs land
Log architecture decides more MSP outcomes than the policy features do.
On both platforms, logs can stay on the firewall, go to a collector you operate, or go to a cloud service. On Fortinet the dedicated collection and analytics role is FortiAnalyzer. On Palo Alto it is Panorama itself with log collectors, or the vendor's cloud logging service.
Three consequences follow, and each shows up in a customer conversation.
Retention is a purchase rather than a setting. Storage sizing follows from log volume, which follows from traffic volume and from how much logging the policy generates. Estimate it before the design is fixed, because a retention shortfall discovered later is remediated by buying capacity.
Physical location is a contractual question for some customers. A customer with data residency obligations needs to know where their logs are stored before they sign, and the answer constrains the deployment model on either platform.
Reporting depends on the logs being reachable and separable. A per-customer report requires that customer's logs to be identifiable and scoped, which is a property of the collection design rather than of the reporting feature.
Licensing as you grow
Both platforms are licensed by the size of the managed estate, and they count differently.
FortiManager counts managed devices. With virtual domains enabled, each virtual domain counts as one license rather than each appliance, so an estate using virtual domains heavily consumes licensing faster than the appliance count suggests.
Panorama uses a device management license sized in tiers, currently up to 25, 100, 1,000 or 5,000 firewalls. It is counted by serial number rather than by virtual system, so an appliance carrying several virtual systems counts once.
| Dimension | How it scales | Where the step change falls |
|---|---|---|
| Managed device count | Licensed on both platforms | FortiManager counts virtual domains, Panorama counts serial numbers in tiers |
| Log volume | Storage and collector capacity | When retention requirements exceed the appliance or collector sizing |
| Customer count | Separation constructs per customer | When the administrative model needs restructuring rather than extending |
| Administrator count | Role definitions and scoping | When per-person roles replace shared accounts, which should be early |
| Change rate | Task queue and push windows | When pushes start queueing behind each other during business hours |
| Management platform redundancy | A second instance and its licensing | When the platform becomes a single point of failure for delivery |
Licensing dimensions from Fortinet's FortiManager ordering guide and Palo Alto Networks Panorama documentation, checked 8 August 2026. Tier boundaries and counting rules change, so confirm against the ordering guide your reseller is quoting from.
Model both against the estate you expect in three years. The step changes fall in different places, so the cheaper platform at twenty devices and the cheaper platform at two hundred are not reliably the same one.
Automation and onboarding
Onboarding is where an MSP either makes margin or loses it.
Both platforms expose programmatic interfaces suitable for automating device onboarding, policy provisioning and reporting, and both have community and vendor tooling for common automation frameworks. The capability exists on both sides, so the evaluation question is about your own team rather than about the product.
Three questions decide whether automation will pay for itself.
- How much of a new customer's configuration is genuinely identical to the last one? That share is what automation can address.
- Who maintains the automation when the person who wrote it leaves? An unmaintained onboarding script is a liability during an incident.
- Does the change process allow an automated change, or does every change require a human approval that removes the time saving?
An MSP onboarding one customer a quarter should template rather than automate. An MSP onboarding one a week should treat automation as core infrastructure and staff it that way.
Configuration drift
Centralized management introduces a failure mode that individually managed firewalls do not have. The device and the manager can disagree.
Both platforms detect the disagreement and report the device as out of sync. What happens next depends on the next push, which may replace the local change with the managed configuration.
From the operations side
The recurring incident is always the same shape. An engineer applies a fix directly on a device at 2am to restore service, because that is the correct thing to do at 2am. The change is never brought back into the manager. Six weeks later an unrelated policy push replaces it, the original fault returns, and nobody connects the two events because they are six weeks apart. The fix is procedural rather than technical. Every out-of-band change gets a ticket before the engineer goes back to bed, and the out-of-sync state is a monitored alert rather than a screen somebody remembers to check.
Three practices keep drift manageable on either platform.
- Alert on out-of-sync status, and treat it as an open item rather than as information.
- Decide in advance whether the manager or the device is authoritative during an incident, and write it down where the on-call engineer will find it.
- Keep configuration revisions and know how to compare two of them, because "what changed" is the first question in most post-incident reviews.
The estate, managed for you
Central management is an operating discipline before it is a product. We run firewall estates that MSPs have already sold, under their brand, across Fortinet, Palo Alto and six other platforms, from $29 per firewall per month. Your customers stay yours, and the change queue, the drift alerts and the 2am ticket are ours.
Get your rateCommon questions
What MSPs ask once managing firewalls one at a time stops working. Something missing? Tell us and we will add it.
At how many firewalls does central management become necessary?
The trigger is the number of administrators and the change rate rather than the device count alone. A single engineer maintaining ten firewalls with occasional changes manages fine device by device. Three engineers maintaining twenty firewalls across several customers need a shared source of truth well before that. For an MSP the practical threshold arrives with the second customer, because that is when separation becomes a requirement rather than a preference.
How does each platform separate one customer from another?
FortiManager uses administrative domains, which contain the managed devices and their policy, and administrators are scoped to the domains they may work in. Panorama uses device groups and template stacks for configuration, with access domains scoping administrators to specific device groups, templates and virtual systems. Both mechanisms are documented and both are configurations rather than guarantees, so assess the specific role model against the customer's obligations rather than accepting a general claim.
How is each platform licensed as the estate grows?
FortiManager counts managed devices, and with VDOMs enabled each VDOM counts as one license rather than each appliance. Panorama uses a device management license sized in tiers, currently up to 25, 100, 1,000 or 5,000 firewalls, counted by serial number rather than by virtual system. The step changes fall in different places, so model both against the estate you expect in three years rather than the one you have.
What happens when someone changes a firewall directly?
Both platforms detect that the device configuration differs from the managed configuration and report the device as out of sync. What follows depends on the next push, which may replace the local change. That is the mechanism behind most central management incidents: an emergency fix applied on the device during an outage, then silently reverted weeks later by an unrelated policy push. Decide the reconciliation rule before the estate is built, and make the out-of-sync state a monitored condition rather than a screen somebody visits.
Can either platform produce per-customer reporting under our own brand?
Both produce scheduled reports scoped to a customer's devices, and both support customizing report presentation. The scope of what can be rebranded differs and changes between releases, so confirm it against the version you will run before promising a specific output to a customer. Where logs are held is the more consequential question, because it determines whether per-customer reporting is possible at all.