Palo Alto Networks PAN-OS Hardening Guide: Locking Down Management, GlobalProtect and Logs

The PAN-OS firewalls that are meant to protect a network keep turning into the way in, because their management web interface and GlobalProtect portal are reachable from places they should never be. CVE-2024-3400 in GlobalProtect and the CVE-2024-0012 and CVE-2024-9474 management interface chain were both exploited in the wild and both sit in the CISA Known Exploited Vulnerabilities catalogue, alongside more than a dozen other PAN-OS and Expedition entries. This guide covers how administrator identity, roles, API keys and service accounts work on PAN-OS and Panorama, the hardening baseline Palo Alto Networks documents for administrative access, GlobalProtect settings that matter for security, and the logs that show tampering. It is for firewall engineers and the SOC analysts who watch these devices. For the cross-vendor view, see the VPN Security Guide.

Key takeaways

• Never expose the management interface. Palo Alto Networks rated CVE-2024-0012 at CVSS-BT 9.3 with open access, but 5.9 when only a jump box could reach the management interface: exposure, not just the bug, sets the risk.
• Keep management profiles off GlobalProtect interfaces. An Interface Management Profile on the interface hosting a portal or gateway publishes the management web interface (typically on port 4443) to the internet.
• Replace the default admin and use external authentication with MFA. One local break-glass superuser, everyone else through RADIUS or SAML with MFA, each person and each automation tool with its own account and Admin Role profile.
• PAN-OS API keys never expire by default. The API Key Lifetime setting is 0 (no expiry) out of the box; set a lifetime and use Expire all API Keys after any suspected compromise.
• Forward Config, System, GlobalProtect and Authentication logs off the box. Logs held only on a compromised firewall cannot be trusted, and a Tech Support File should be collected before rebooting a device you think was exploited.

How identity and access work in PAN-OS

PAN-OS runs on PA-Series hardware, VM-Series and CN-Series firewalls, and the same operating system runs Panorama, the central management platform. Identity on these devices falls into three groups that need different controls.

• Administrators: people who sign in to the web interface (HTTPS), the CLI (SSH) or the XML and REST APIs. Accounts are local or backed by an authentication profile that points at RADIUS, TACACS+, LDAP, Kerberos or SAML. Each account has an Administrator Type: a Dynamic role (built in, such as Superuser, Superuser (read-only), Device administrator) or a Role Based admin role profile you define.
• Machine and automation identities: API keys generated for an administrator account, accounts used by Terraform, Ansible or orchestration tools, the User-ID agent service account that reads domain controller security logs, LDAP bind accounts used for group mapping, SNMP credentials, and the certificates PAN-OS uses for its own management interface and for GlobalProtect.
• End users of GlobalProtect: remote users who authenticate to the portal and gateways through an authentication profile, optionally with client certificates, and who may receive an authentication override cookie that lets them reconnect without signing in again.

Panorama adds Access Domains, which limit a Panorama administrator to specific Device Groups, Templates and Log Collector Groups. A Panorama superuser can push configuration to every managed firewall, so Panorama access is the highest privilege in the estate and needs at least the same controls as the firewalls themselves.

Management plane exposure paths

Admin roles and privileged access

The Palo Alto Networks Administrative Access Best Practices give a clear target state. Work through it in this order.

1. Create a replacement superuser. Under Device > Administrators, create one new local account with Administrator Type Dynamic and Superuser. PAN-OS will not let you delete the default admin account until another superuser exists. Then delete admin, or at minimum change its password at first boot. Store the local credentials in a PAM vault and treat the account as break-glass. See the Break-Glass Account Guide.
2. Move everyone else to external authentication with MFA. Use RADIUS or SAML backed by your identity provider, with MFA, through an authentication profile. Where external authentication is not possible, use certificate-based authentication for the web interface and SSH key authentication for the CLI. If you use SAML, keep the identity provider certificate validation enabled: CVE-2020-2021, in the KEV catalogue, was an authentication bypass that applied when that validation was turned off. See the SAML Security Guide.
3. Give every person and tool its own account. The best practice guidance names automation explicitly: Terraform, Ansible and similar tools each get a unique account. Shared accounts break the audit trail in the Config log.
4. Define Admin Role profiles. Under Device > Admin Roles, build profiles that limit each account to the web interface areas, CLI level and API types it needs. A monitoring integration needs read access to logs and reports, not configuration commit rights.
5. Set session and lockout controls. Configure the global Idle Timeout under Device > Setup > Management > Authentication Settings, Failed Attempts and Lockout Time in the authentication profile, and Minimum Password Complexity for any remaining local accounts.
6. Put a bastion in front. The vendor guidance recommends a bastion host with screen recording and strong authentication as the only entry point to the management network; without one, use an Authentication Policy with MFA for management traffic. See the Privileged Session Management Guide.

Role design for common administrator types

Integrations, API tokens and service accounts

Most firewall estates carry more machine credentials than people, and those credentials are what attackers look for after they get onto a firewall or a management server.

• API keys: a PAN-OS API key is derived for an administrator account and inherits its role. The API Key Lifetime setting (Device > Setup > Management > Authentication Settings) defaults to 0, which means keys never expire; the configurable range is 1 to 525,600 minutes. Generate keys only after the Admin Role profile is in place, set a lifetime the pipeline can renew within, and use Expire all API Keys after any compromise or staff change in the automation team. See the API Key Management Guide.
• Master key: PAN-OS encrypts stored secrets (passwords, private keys) with a master key. Change the default master key under Device > Certificate Management > Master Key, back up the configuration first, and on HA pairs disable Config Sync, set the same key on both peers, then re-enable it. Panorama, WildFire appliances and Log Collectors must share Panorama's master key. Rotate it on a schedule and store it in a vault.
• User-ID and LDAP accounts: the account that reads domain controller event logs and the LDAP bind account for group mapping are domain identities. Give them the minimum rights (for example, membership of Event Log Readers rather than Domain Admins), deny interactive logon, and prefer LDAPS. They are a common source of over-privileged domain credentials stored on the firewall.
• SNMP: use SNMPv3 with authentication and privacy rather than SNMPv2c community strings. SNMP cannot use service routes, so route it through an inspected data plane subinterface if it uses the MGT port. See the SNMP Security Guide.
• Certificates: replace the default management certificate with one from your enterprise CA, set the SSL/TLS Service Profile to Min Version TLSv1.2 and Max Version Max, and restrict ciphers and key exchange in the SSH Service Profile.
• Expedition and other tooling: the Expedition migration tool has its own KEV entries (CVE-2024-5910 missing authentication, CVE-2024-9463 command injection, CVE-2024-9465 SQL injection) and stores firewall credentials and API keys. Keep it off the network when not in use, never expose it, and rotate every firewall credential it has held.

GlobalProtect settings that affect security

Logging and detection

PAN-OS can forward every log type it generates to syslog over UDP, TCP or TLS 1.2, and to Panorama or Strata Logging Service. Forwarding matters most for the logs that show what administrators and attackers did on the box.

Enable audit comments on Security policy rules and require commit descriptions so that each change has a reason. Use the Administrator Login Activity Indicators, which show the last login and failed attempts when an administrator signs in. When exploitation is suspected, the CVE-2024-3400 advisory is explicit: collect a Tech Support File before rebooting into a fixed version, because some logs from before the upgrade become inaccessible afterwards. For the cross-vendor detection approach, see the VPN and Firewall Log Detection Guide and the Edge Device Compromise Investigation Playbook.

Metrics that show the baseline is holding

• Management exposure: number of firewalls and Panorama instances whose management interface is reachable from the internet or user networks (target: zero, verified by an external scan each week).
• Patch latency: days from a PAN-OS advisory rated Critical or High to the fixed version running on every affected device.
• Externally authenticated admins: percentage of administrator accounts using external authentication with MFA (target: all except break-glass).
• Key hygiene: API Key Lifetime set on every device, and the age of the oldest active automation key.
• Log completeness: percentage of devices forwarding Config, System and GlobalProtect logs, with an alert when a device goes quiet.

Hardening baseline

Roll this out in phases, using Panorama templates where you have them so that settings are consistent and drift is visible.

1. Phase 1, exposure (days 0 to 7): inventory every firewall, Panorama and Expedition instance; scan from outside for management services on all public addresses (HTTPS, SSH and port 4443 on GlobalProtect addresses); remove Interface Management Profiles from untrust and GlobalProtect interfaces; set Permitted IP Addresses on the MGT port. Test by connecting from a non-permitted address and confirming it fails. Roll back by restoring the previous named configuration snapshot.
2. Phase 2, patch and subscribe (days 0 to 14): move to a fixed maintenance release for every open KEV entry, subscribe to Security Advisories and Software Update emails on the Support Portal, and read release notes before upgrading. Upgrade the HA passive peer first, fail over, then upgrade the other peer.
3. Phase 3, administrator identity (weeks 2 to 6): create the replacement superuser, delete or lock down admin, move administrators to RADIUS or SAML with MFA, build Admin Role profiles and Panorama Access Domains, and set Idle Timeout and lockout. Pilot on one firewall pair before pushing the template; keep the break-glass account tested in case the identity provider is unreachable.
4. Phase 4, machine credentials (weeks 4 to 8): set API Key Lifetime, reissue keys for automation under dedicated accounts, change the master key in a maintenance window, move SNMP to v3, and reduce User-ID and LDAP account rights.
5. Phase 5, inspection and logging (weeks 6 to 10): route management traffic through a data plane interface with a cloned strict Vulnerability Protection profile, set SSL/TLS and SSH Service Profiles, replace the management certificate, configure service routes, and forward Config, System, GlobalProtect and Authentication logs to the SIEM over TLS.
6. Phase 6, verify (ongoing): audit configuration against the template monthly, and re-scan externally after any change to NAT, interfaces or cloud security groups.

Framework mapping

In ISO/IEC 27001:2022 Annex A the same work falls under A.8.2 Privileged access rights, A.8.5 Secure authentication, A.8.8 Management of technical vulnerabilities, A.8.9 Configuration management, A.8.15 Logging and A.8.20 Networks security.

Common misconfigurations

• Management profile on the GlobalProtect interface: added once for troubleshooting and never removed. It turned CVE-2024-0012, a management interface flaw, into an internet-facing one for many organisations. Check every interface that carries a public address.
• Signatures treated as the fix: Threat Prevention signatures only work when Vulnerability Protection is attached to the rule that carries the traffic, and the vendor states they are not a substitute for upgrading. For CVE-2024-3400, devices that had neither patch nor signatures in place by 25 April 2024 were advised to request an Enhanced Factory Reset through TAC.
• Patching without hunting: upgrading a firewall that was already compromised removes the vulnerability but not stolen configuration, credentials or keys. Collect the Tech Support File first, and rotate administrator passwords, API keys, the master key, VPN pre-shared keys, LDAP and User-ID account passwords and certificate private keys held on the device. The Ivanti Connect Secure exploitation of 2024 showed the same pattern on another vendor: attackers harvested credentials and service account secrets from the appliance, which outlived the patch.
• Never-expiring API keys in scripts: the default lifetime of 0 means a key copied into a script years ago still works. Set a lifetime and expire all keys once to flush old ones.
• Long-lived authentication override cookies: a cookie lifetime of weeks or months, combined with MFA on the portal only, lets a stolen cookie reconnect without a second factor. See the Session Hijacking and Cookie Theft Guide.

Practitioner checklist

• Confirm by external scan that no firewall, Panorama or Expedition management service is reachable from the internet, including port 4443 on GlobalProtect addresses.
• Remove Interface Management Profiles from untrust and GlobalProtect interfaces and set Permitted IP Addresses on the MGT port.
• Run a fixed PAN-OS maintenance release for every KEV-listed PAN-OS vulnerability and subscribe to Security Advisories.
• Replace the default admin with one vaulted break-glass superuser; move all other administrators to RADIUS or SAML with MFA.
• Build Admin Role profiles (and Panorama Access Domains) so each person and automation tool has only the access it needs.
• Set API Key Lifetime, reissue automation keys under dedicated accounts, and change the default master key.
• Shorten GlobalProtect authentication override cookie lifetimes and require dynamic passwords on the portal and external gateways.
• Attach a strict Vulnerability Protection profile to management and GlobalProtect rules.
• Forward Config, System, GlobalProtect and Authentication logs to the SIEM over TLS and alert on admin logins from outside the bastion range.
• Keep an incident runbook: collect a Tech Support File before reboot, then rotate every credential and key held on the device.

Standards and references

• Palo Alto Networks: Deploy Administrative Access Best Practices
• Palo Alto Networks: Best Practices for Securing Administrative Access
• Palo Alto Networks: Configure API Key Lifetime
• Palo Alto Networks: GlobalProtect Portals Agent Authentication Tab
• Palo Alto Networks: CVE-2024-3400 Security Advisory
• Palo Alto Networks: CVE-2024-0012 Security Advisory
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: VPN Security Guide · Network Device Management Plane Hardening Guide · Palo Alto Prisma Access Configuration Guide · Edge Device Security Guide · FortiGate Hardening Guide