FortiGate vs Palo Alto security: the real difference

App-ID and application control

Both platforms can tell you which application a flow belongs to. They disagree about when that question gets asked.

Where Palo Alto asks it

App-ID classifies traffic by application regardless of port, protocol or evasion technique, using application signatures, protocol decoding and heuristics. The classification applies to traffic crossing the firewall rather than to selected policies, and the resulting application is available as a match condition in the security rulebase.

The consequence is that a Palo Alto administrator writes rules in terms of applications by default. A rule that permits traffic has already had the classification performed on it.

Where FortiGate asks it

FortiGate in profile mode performs application identification through an application control profile attached to a firewall policy. The policy matches on interface, address and service. The profile determines which applications are identified and what happens to them.

The consequence is that application awareness is present where it has been attached. A policy with no application control profile permits traffic on the basis of address and port, and produces no application-level decision.

The middle path

FortiGate policy mode allows applications and URL categories to be used directly in security policies, without requiring application control or web filter profiles. That places the application decision back inside the policy, which is closer to how PAN-OS expresses it.

Policy mode carries constraints. It is set per VDOM, requires flow-based inspection, and central NAT is always enabled. Those trade-offs are covered in the migration page, where the choice between the two modes is a project decision rather than a preference.

Architectural placement compiled from Palo Alto Networks App-ID and policy documentation and Fortinet's FortiOS administration guide, including its section on profile-based and policy-based NGFW mode. Checked 8 August 2026. Behaviour is version sensitive on both platforms.

Detection is not enforcement

A platform that identifies an application perfectly and is configured to allow it has enforced nothing.

This distinction gets lost because identification is visible and enforcement is not. The logs fill with correctly named applications, the dashboard shows activity, and the customer concludes the firewall is working. What the logs demonstrate is that identification is working. The action taken is a separate field.

A concrete example. A customer asks for file-sharing services to be blocked. An engineer adds an application control profile with the relevant applications set to monitor, attaches it to the outbound policy, and confirms in the logs that the traffic is identified. Every part of that is functioning. The traffic is also still flowing, because monitor records and permits.

The same gap appears on the other platform in a different form. A Palo Alto rule that permits an application without a security profile group attached allows the traffic and performs no threat inspection on it. The application decision was made correctly and the content inside it was never examined.

The check that catches both is the same. For any control the customer believes exists, find the rule, read the action, and confirm the inspection attached to it. Presence in the logs is not evidence of enforcement.

Intrusion prevention and malware

Both vendors run signature-based detection supported by their own research organizations, and both supplement signatures with inline analysis for traffic that matches no known pattern. Content arrives through subscription updates on both platforms, which is why a lapsed subscription degrades detection without changing anything visible in the configuration.

We publish no effectiveness ranking between them. Third-party test results carry licensing restrictions and interpretation problems, and the specific configuration tested rarely matches the configuration a customer runs.

Three properties are worth comparing, because they are verifiable rather than promotional. How frequently content updates are published and how they are applied. What the platform does with traffic when inspection is unavailable. Whether the customer's chosen subscription tier actually includes the capability being discussed, which is the subject of the licensing page.

Sandboxing

Both vendors offer analysis of unknown files, and both offer more than one place to perform it.

Palo Alto's WildFire is a cloud service with a private-cloud appliance option. In the private-cloud deployment, files are analyzed locally and benign, grayware and phishing samples analyzed there stay inside the customer's network. A single private-cloud appliance serves a bounded number of firewalls, which is a capacity planning input for a large estate.

Fortinet's FortiSandbox is available as an on-premises appliance, as a virtual machine and as a cloud service, and integrates with the antivirus inspection path on the firewall.

Two operational properties decide this more often than the feature lists do.

The first is data handling. A customer with data residency obligations, or one whose files contain regulated material, may require local analysis. That requirement selects the deployment model before any capability comparison begins.

The second is verdict latency. A sandbox returns a verdict after the file has been analyzed, which raises a design question about what happens to the file in the meantime. Whether the platform holds the file, releases it and retracts later, or logs it for review changes the user experience and the security posture. Confirm the configured behaviour rather than assuming, because the answer differs by deployment on both platforms.

Sandbox deployment options and data handling taken from Palo Alto Networks WildFire private cloud documentation and Fortinet FortiSandbox documentation, checked 8 August 2026.

TLS inspection decides everything

TLS inspection is the largest determinant of whether any of the capabilities above do anything, on either platform.

Most traffic is encrypted. Intrusion prevention, antivirus, sandboxing and URL enforcement all operate on content the platform can read. A customer who has bought a full security subscription and disabled decryption has bought capabilities that apply to a minority of their traffic.

What decryption costs, the eight classes of traffic that break under it, and a rollout order that keeps the helpdesk standing are covered on the TLS inspection page.

Decryption is frequently disabled for reasons that are real.

• It is expensive in capacity terms on both platforms, and is covered in the sizing page as the single largest variable.
• It requires certificate distribution to every device that will be inspected, which is a project rather than a setting.
• Applications break under inspection, including some that pin certificates deliberately, so an exemption list is required and grows over time.
• It raises a legitimate question about employee privacy that belongs with the customer's management rather than with their engineer.

Raise it before the purchase. Decryption changes the sizing, adds a workstream to the project, and requires a decision from the customer that only they can make. Discovering it after the appliance is installed converts it into a difficult conversation about an appliance that is now too small.

The honest position to take with a customer is that partial inspection is a legitimate choice, provided everybody knows it is the choice being made. What causes harm is a customer who believes they have full inspection and has exemptions covering most of their traffic.

URL and DNS filtering

Both platforms categorize URLs against a maintained database and act on the category, and both offer DNS-layer filtering as a related control. Categorization depends on live lookups, so both degrade when the subscription lapses or the service is unreachable.

The behaviour on degradation differs by default and is configurable on both. A FortiGate whose FortiGuard subscription has lapsed returns a rating error for every site, and the default handling blocks the traffic unless fail-open is configured. Palo Alto URL filtering more commonly permits when categorization is unavailable. Set the behaviour deliberately on both platforms and record which one you chose for the customer.

Degradation behaviour compiled from vendor documentation and vendor community guidance, checked 8 August 2026. It is configurable and version dependent on both platforms, so test it in a maintenance window rather than during an incident.

What we actually see

The failure modes below are the ones that arrive with estates we take over. Each is a configuration state rather than a product fault, and each platform invites a different one.

Two further checks belong in any takeover of an existing estate.

• Compare the rules the customer describes to you against the rules that carry hits. Rules that never match describe an intention rather than a control.
• Establish what share of traffic is being decrypted, in figures. Every conversation about detection quality is downstream of that number.