What a Palo Alto Firewall Health Check Actually Includes

A Palo Alto Networks firewall can run for years without anyone touching it, and that is exactly the problem. Rules pile up, software falls behind, subscriptions lapse and the person who built it moves on. A health check is how you find out what the firewall is really doing before an auditor, an attacker or an outage tells you.

This is what a thorough Palo Alto firewall health check covers, in the order we usually work through it, and why each part matters.

1. Software version, support status and advisories

The first question is whether the firewall is running software that is still supported and patched. We check:

• The PAN-OS version against Palo Alto Networks’ published end-of-life dates and recommended releases.
• Open security advisories on security.paloaltonetworks.com that apply to the exact version and features in use, such as GlobalProtect or the management web interface.
• Whether the hardware model itself is approaching end of sale or end of support.
• The upgrade path, because jumping several major releases requires intermediate steps.

An unpatched firewall on an internet-facing edge is one of the highest-risk findings in any review. Several Palo Alto vulnerabilities have appeared on CISA’s Known Exploited Vulnerabilities catalog, which is why we publish a weekly Palo Alto advisory roundup.

2. Management-plane hardening

The management interface should never be reachable from the internet, and access to it should be limited to specific administrative networks. We review:

• Permitted IP addresses on the management interface and any interface management profiles that allow HTTPS, SSH or ping on data-plane interfaces.
• Administrator accounts: shared logins, unused accounts and whether roles follow least privilege.
• Administrator authentication through RADIUS, TACACS+ or SAML with multi-factor authentication, instead of local passwords only.
• Password complexity profiles, idle timeouts and login banners.
• Certificates used for management, GlobalProtect and decryption, and when they expire.

3. Rulebase hygiene

This is usually where the biggest wins are. Over time, rulebases collect rules that are unused, shadowed by broader rules above them or far more permissive than they need to be. We look for:

• Unused rules, using rule hit counts and the Policy Optimizer in PAN-OS.
• Shadowed rules that can never match because an earlier rule already catches the traffic.
• Overly broad rules with any source, any destination, any application or any service.
• Port-based rules that should be converted to App-ID, ideally with the application-default service.
• Rules without descriptions or owners, which nobody dares to remove.
• Disabled rules left in place long after they stopped being needed.

Every change recommended here is backed by data, and nothing is removed without agreement. A cleaner rulebase reduces attack surface, speeds up troubleshooting and makes the next audit far easier.

4. Security profiles and threat prevention

A Palo Alto firewall that allows traffic without security profiles is acting like a much simpler firewall. We confirm that allow rules carrying real traffic have a security profile group attached, and that the profiles themselves are sensible:

• Antivirus and anti-spyware, including DNS sinkholing or DNS Security where licensed.
• Vulnerability protection that blocks critical and high-severity threats.
• URL filtering with categories that match your policy.
• File blocking and WildFire analysis with frequent signature updates.

5. Decryption

Most traffic is encrypted, so without decryption much of the threat prevention you are paying for has nothing to inspect. We review whether SSL forward proxy and inbound inspection are in use, how exclusions are handled and whether certificates are deployed correctly.

6. High availability and resilience

For HA pairs, we check configuration synchronization, link and path monitoring, matching software and content versions, and whether failover has been tested recently. An HA pair that has never failed over is an assumption, not a design.

7. Zone and DoS protection

Internet-facing zones should have zone protection profiles to defend against floods, reconnaissance and packet-based attacks. We review whether they exist and whether thresholds make sense for your traffic.

8. Logging, visibility and User-ID

When something goes wrong, logs are the evidence. We check that rules log at session end, logs are forwarded to Panorama, a SIEM or syslog, retention meets your requirements and configuration changes are recorded. If User-ID is used, we check how much traffic is actually mapped to users.

9. Dynamic updates, licenses and backups

• Application, threat, antivirus and WildFire update schedules.
• Subscription and support expiry dates, so nothing lapses silently.
• Scheduled configuration backups stored off the device.
• Documentation that matches the running configuration.

What you should receive

A useful health check ends with a written report: findings ranked by risk, the effort to fix each one and a recommended order of work. Some fixes take minutes; others, like converting a large rulebase to App-ID, are planned projects. The report should make that distinction clear.

A five-minute self-check

Before you book a full review, answer these questions:

• Do you know which PAN-OS version you are running and whether it is still supported?
• Is the management interface reachable only from an administrative network?
• When were unused rules last removed?
• Do all allow rules have security profiles attached?
• Are configuration backups stored somewhere other than the firewall?

If any answer is “not sure,” a health check will pay for itself.

Related: Palo Alto firewall consulting · Cisco ASA to Palo Alto migration outline