New Features - PAN-OS - 12.2

While inline cloud analysis for Advanced Threat Prevention provides robust command injection protection, it can restrict traffic volume and introduce 100–200 milliseconds of latency—challenging for high-throughput environments. Local Deep Learning for command injection resolves this by running the Palo Alto Networks deep learning model directly on supported NGFWs. This allows you to inspect significantly more inbound traffic locally, delivering verdicts up to 100 times faster than cloud-only analysis.

Local Deep Learning for command injection uses the same proven model that runs in the Advanced Threat Prevention cloud, optimized for on-device execution through new CPU instruction sets and memory-efficient model loading. You configure the feature in the Vulnerability Protection profile under the Inline Cloud Analysis tab—a new Local Deep Learning column lets you enable or disable the feature for the command injection ML model. Local Deep Learning is enabled by default when you enable Inline Cloud Analysis on a new Vulnerability Protection profile, giving you immediate command injection protection without additional configuration.

During operation, the NGFW evaluates suspicious HTTP traffic against the local model and processes benign verdicts instantaneously. If the model identifies a potential command injection exploit, it forwards the traffic to the cloud for a false-positive check and returns the cloud verdict when available. If the cloud is unreachable or times out, the NGFW uses the local model verdict and takes the action you configured—eliminating the fail-open gap where threats could pass uninspected. A new local packet capture option lets you retain forensic evidence for detections made when the cloud is non-responsive.

Content updates deliver the latest command injection models automatically, keeping your on device detection current without manual intervention.

You can now apply a metadata profile to each zone on your NGFW to filter the log fields forwarded to Device Security . When you specify a metadata profile, PAN-OS only forwards log data based on the cloud services enabled on your NGFW . This helps bandwidth-constrained sites, such as remote facilities or OT environments, as they only forward log data required by the cloud services instead of excess logs.

Metadata profiles map log fields to the cloud services that need them. You assign a profile to a zone with a single setting, which replaces the multi-step Log Forwarding Profile configuration previously attached to each firewall policy.

This gives you a simpler way to send the right metadata to Device Security and reduces the volume of data your firewalls push to the cloud at sites where bandwidth is limited. Existing log forwarding configurations continue to work after upgrade, so you can adopt metadata profiles on a zone-by-zone basis.

Previously, in HA Active/Passive pairs with service routes configured for Palo Alto Networks services or DNS servers, it was impossible to renew device certificates on the passive device because the passive device's dataplane functions are down. Starting with this PAN-OS® release, the passive device can have service routes configured and receive certificate updates and renewals through its HA interface connected to the active device. You do not have to configure or change your network security policy to perform this function; the process happens automatically when a certificate is near its expiry date. This allows your HA pair to maintain up to date and secure connections with Palo Alto Networks licenses and services even after a failover event.

You can verify if the passive device has successfully renewed a certificate using the following CLI command:

show device-certificate status 

Note: It's recommended that you enable encryption on the HA link, otherwise you will receive the following system log during the renewal process: HA1 link is used without encryption .

Managing user authentication for the explicit web proxy previously required SAML or Kerberos SSO infrastructure, but you can now use basic authentication to validate proxy users against Local Database, LDAP, RADIUS, TACACS+, Kerberos Pre-Authentication, or an authentication sequence.

When you make a request through the proxy, the firewall issues an HTTP 407 Proxy Authentication Required challenge. The browser prompts the user for a username and password, and the proxy validates the credentials against the configured backend. Successful authentication creates a log entry and allows the request to proceed.

You can customize the authentication realm string displayed in the browser credential prompt. The default realm is Explicit Proxy, but you can change it to identify the protection scope for your users.

To reduce repeated authentication prompts, configure IP Surrogate Minutes to cache an authenticated user's IP address for up to 600 minutes. While the cache entry is valid, subsequent requests from that IP address bypass the authentication challenge. Because the cache is stored in memory, it does not persist when the proxy restarts. Don't use IP surrogate in NAT environments or virtual desktop infrastructure (VDI) deployments where multiple users share a single IP address.

If you switch the authentication service type (for example, between Kerberos SSO and basic authentication), users must clear their browser cache and history for the change to take effect.

Previously, a firewall could receive a credential bloom filter from only one Windows-based User-ID agent running the credential service add-on. In PAN-OS 12.2.2, the data plane supports multiple bloom filters per virtual system, one per connected credential agent. This means you can deploy a separate credential agent on each read-only domain controller (RODC) in a multi-domain or multi-forest environment and connect all of them to the same firewall. Details are available for the changes to installation and configuration.

PAN-OS introduces Subscriber and Equipment objects, giving firewall administrators a readable, reusable way to reference mobile network identities in security policy — similar to how address objects work for IP-based networks.

• Subscribers — Define mobile subscribers by IMSI, IMSI Range, or IMSI Prefix. IMSI ranges now support changes from the 4th through 15th digit (previously limited to digits 11–15), and IMSI prefixes can now be any variable length starting from the 4th digit (previously fixed at 6 digits).

• Subscriber Groups — Group one or more Subscriber objects for use in policy, improving rule readability and reducing repetition.

• Equipment — Define mobile devices by IMEI, IMEI Range, or IMEI Prefix. IMEI ranges now support 6 to 16 digits, and IMEI prefixes can be any variable length from the 6th digit (previously fixed at 8 digits).

• Equipment Groups — Group one or more Equipment objects for use in policy.

Subscribers, Subscriber Groups, Equipment, and Equipment Groups can all be referenced as match criteria in Security policy rules, allowing administrators to write policies using meaningful names instead of raw IMSI or IMEI values.

GTP Security must be enabled through DeviceSetupManagementGeneral Settings to make Subscriber and Equipment objects available.

Supported on all Gen 3–5 hardware platforms, VM-Series, and CN-Series. Not supported on Cloud NGFW or Prisma Access.

Devices using the publicly available global default master key leave sensitive data vulnerable to decryption. You can now secure private keys and passwords through mandatory master key replacement enforcement. A thirty-day grace period initiates automatically when you power on a brand new device, restore a device to its factory default settings, or upgrade your PAN-OS software to the latest release. During this initial time frame, you will see active warnings in the interface whenever you perform a commit. These warnings proactively prompt you to configure a unique, secure key before the expiration date arrives.

If you do not change the master key after the thirty days elapse, your device fails all standard configuration commits, excluding essential auto-commits, until you successfully apply a custom master key. This enforcement applies whether you manage your devices through PAN-OS, Panorama, or Strata Cloud Manager (Strata Cloud Manager). This strict enforcement ensures you proactively secure sensitive device data across your entire network deployment, preventing attackers from easily extracting and exploiting credentials using a known default key.

For environments with specific operational requirements that need minimal disruption, you retain the flexibility to globally disable this master key enforcement setting at any time in PAN-OS, Panorama, or Strata Cloud Manager to prevent unexpected commit failures and maintain your existing administrative workflows.

PAN-OS® 12.2.2 introduces a redesigned transport architecture for cloud-delivered security services that eliminates performance bottlenecks in the Multi Inline Cloud Analysis (MICA) data forwarding channel. This architecture improves inline cloud analysis for Enterprise DLP, Advanced Threat Prevention, Advanced URL Filtering, Advanced WildFire, Prisma AIRS (AI Runtime Security), ACE (App-ID Cloud Engine) when used alongside SaaS Security Inline, and AI Access Security.

The new architecture removes the fixed-core transport limitation that previously constrained cloud submission throughput regardless of available hardware resources. All data plane cores now natively handle payload forwarding to the cloud through a scalable connection pool. Each connection is established directly from the data plane over TLS, eliminating the intermediate process that previously serialized all cloud submissions through a single core.

The redesigned transport reduces latency by replacing protocol translation layers with a direct binary protocol between the data plane and advanced service addresses. Native PAN-OS memory pools replace the previously fixed-size memory allocation, reducing dedicated memory consumption and increasing overall system capacity. The newly introduced Advanced Forwarding discovery service dynamically assigns advanced service addresses based on your NGFW's location and configuration, improving reliability and enabling automatic failover without manual intervention.

You manage this feature from DeviceSetupContent-IDContent Cloud Settings in the web interface. When Advanced Forwarding is enabled, the NGFW establishes TLS connections directly from the data plane to the cloud. To use the legacy transport instead of Advanced Forwarding, you must manually disable Advanced Forwarding. The NGFW does not automatically fall back to the legacy transport method.

When you investigate suspicious web traffic, the absence of HTTP header data can force guesswork — HTTP Header Logging closes this gap by capturing any request or response headers, including custom headers, directly in URL filtering logs.

You configure HTTP Header Logging in a URL filtering profile by selecting which headers to capture. You can add individual request headers, individual response headers, or enable Log all HTTP headers to capture every header. The HTTP response status code is captured in every response log entry. Enable Enable logging of response code in HTTP response to force a response log entry even when response headers are not logged.

When you log both request and response headers, the firewall generates two URL filtering log entries per resource. A URL Index field and a Direction field correlate the pair so you can reconstruct the full exchange.

Use Max Header Length to limit how much data is captured per header value (1–4,092 bytes). The limit applies to the header value only and excludes the header name, colon, and whitespace. Enable Enable truncation of headers that exceed the max header length limit to capture headers up to the limit rather than skipping them entirely.

Request headers can contain personally identifiable information (PII) such as cookies and authorization tokens. A privacy notice appears the first time you enable request header logging — review your data privacy requirements before enabling logging for sensitive headers.

PAN-OS 12.2.0 expands DNS Proxy with complete dual-stack IPv6 support, enabling firewalls to forward DNS requests between clients and servers regardless of whether each side uses IPv4 or IPv6. Previously, only matching IP versions were supported (IPv4-to-IPv4 or IPv6-to-IPv6). Now all combinations work seamlessly. This support includes:

• Mixed IPv4/IPv6 forwarding — DNS Proxy now supports IPv4 clients resolving through IPv6 servers and IPv6 clients resolving through IPv4 servers, across all transport protocols: DNS-over-UDP, DNS-over-TCP, DNS-over-HTTPS (DoH), and DNS-over-TLS (DoT).

• Cross-version server failover — If the Primary DNS server (e.g., IPv4) becomes unreachable, the firewall can now fail over to a Secondary server configured with a different IP version (e.g., IPv6), and vice versa.

• Cross-version encrypted-to-cleartext fallback — When an encrypted DNS attempt (DoT/DoH) fails, the firewall can fall back to cleartext DNS even if the fallback server uses a different IP version than the client.

• Faster TCP failover — The DNS-over-TCP connection timeout has been reduced from a hardcoded 2 minutes to 4 seconds (connection) and 30 seconds (data transfer), significantly improving failover speed to secondary servers.

Note: Interfaces assigned to a DNS Proxy object must have both an IPv4 and an IPv6 address configured if both IPv4 and IPv6 upstream DNS servers are in use.

When you need to consolidate your network infrastructure, the Layer 2 Switching feature on Next-Generation Firewalls allows you to operate your firewall as a fully functional Layer 2 switch. This feature introduces comprehensive switching capabilities directly on the firewall, enabling you to configure access and trunk VLANs per port, deploy Multiple Spanning Tree Protocol (MSTP) for robust loop avoidance, utilize Link Aggregation (LAG), and apply Storm Control to mitigate excess broadcast, unknown unicast, and multicast traffic.

You can leverage this capability primarily to achieve a branch in a box deployment, which is specifically targeted at small to medium-sized network environments such as retail locations, healthcare facilities, and financial branch offices. By merging your traditional standalone switch, router, and firewall into a single appliance, you significantly reduce overall hardware costs and simplify your ongoing network management.

Furthermore, this architecture empowers you to implement micro-segmentation and Zone-Based Forwarding (ZBFW) for lateral traffic, allowing you to secure east-west communication within and across VLAN boundaries.

When the same IP block is reused across sites or virtual systems, Device Security can misidentify devices, mix device behavior across locations, and deliver incorrect Device-ID verdicts to your firewalls — breaking policy enforcement for every affected segment. Multi-vsys support for Advanced Device-ID solves this by letting you define named network segments in Panorama and associate each virtual system with a specific segment, so Device Security tracks and delivers device context separately for each logical partition of your network.

Network segments are configured in Panorama as shared objects and pushed to firewalls through templates, the same way other Panorama-managed features work. Once a virtual system is assigned to a segment, Device Security receives the vsys-to-segment mapping from PAN-OS and generates a unique segment ID for each network segment. That ID travels with every verdict, so Edge delivers device context only to the firewalls that belong to the corresponding segment. For devices in non-overlapping IP space, Restrict Context Sharing gives you control over whether device context learned in one segment is visible to firewalls in other segments, or kept private to the segment where the device was discovered.

If your organization currently uses the Device Security -managed network segment configuration from an earlier release, you can migrate to Panorama-managed segments through the Device Security portal. After migration, segment definitions are owned entirely by Panorama, and the portal displays them in read-only mode. Devices already learned through existing segments are preserved in your asset inventory — only the management of segment definitions moves to Panorama. Devices in shared IP blocks always receive scoped verdicts regardless of the context sharing setting, preserving isolation between segments that operate on overlapping address space.

• In the PAN-OS 12.2.2 release, PAN-OS Shield is only supported for protecting GlobalProtect gateway and portal.

To ensure continual protection against critical vulnerabilities and exploits targeting your firewall, Palo Alto Networks introduces PAN-OS Shield, a built-in feature that uses Advanced Threat Prevention (ATP) to provide inline protections.

These vulnerability protection signatures are delivered via a PAN-OS Shield module as part of the standard Applications and Threats Content Package. PAN-OS Shield applies these critical vulnerability updates automatically, independent of PAN-OS release cycles, and requires no NGFW restarts or operational downtime. This automatic security update capability is built into all platforms by default and does not require an active Advanced Threat Prevention license for PAN-OS specific vulnerability protections. Additionally, when malicious traffic is detected, the NGFW executes the action defined within the PAN-OS Shield security policy and its associated vulnerability protection profile. Additionally, the NGFW automatically generates a standard Threat Log detailing the event.

To provide immediate protection out of the box, Palo Alto Networks recommends enabling PAN-OS Shield, which requires a commit, followed by a system reboot. While the base policy name and description of the pre-configured PAN-OS Shield profile cannot be modified, administrators retain the flexibility to handle false positives. If you need to bypass a specific vulnerability signature for your environment, you can navigate to your security profiles and open the built-in PAN-OS Shield Vulnerability Profile to modify its threat exceptions. When adding exceptions, you can easily filter and search specifically for "Palo Alto Networks" signatures associated with the PAN-OS Shield service.

Note: In the rare circumstances that PAN-OS Shield blocks a benign web management session, you can choose to use the PAN-OS CLI or use a bastion machine with access to the console port or manage via interface management profile configured on a dataplane port. Check PAN-OS Shield logs to determine if this is the case and contact Customer Support.

You can now prevent legitimate traffic from being silently dropped when it matches a stale discard session that never ages out. When enabled, the no-refresh-on-discard session setting freezes the timeout for discarded UDP and connectionless protocol sessions, allowing them to expire naturally instead of being perpetually refreshed by incoming traffic.

Previously, when the firewall placed a UDP session in a DISCARD state, any subsequent packet matching the same 6-tuple would reset the session timeout, preventing the session from expiring. Because connectionless protocols such as UDP, GRE, and ESP do not establish unique tuples for each new connection, legitimate traffic that reused the same source and destination addresses was silently blackholed by the stale discard session. This behavior caused intermittent and difficult-to-diagnose disruptions across multiple protocols and scenarios, including DHCP sessions after tunnel restoration, RADIUS authentication requests, GRE tunnel traffic after security policy changes, and SIP sessions discarded due to resource exhaustion.

You enable this setting using the CLI command set session no-refresh-on-discard yes . The setting is disabled by default to maintain backward compatibility. When enabled, the firewall freezes the timeout for discard sessions triggered by specific validated scenarios, allowing the session to age out so that subsequent valid traffic can establish a new session and be processed normally. TCP sessions are not affected because TCP's connection-oriented state machine naturally mitigates this issue through connection resets.

Proxy ARP and DHCP Relay Overwrite redirect traffic through the firewall for inspection and policy enforcement. For scenarios where devices share the same Layer 2 broadcast domain, they communicate at Layer 2 without passing through a Layer 3 gateway, which means the firewall lacks visibility into or control over that traffic. This lack of visibility creates a security enforcement gap that allows unrestricted lateral movement between devices. This is particularly concerning in flat network environments, such as operational technology (OT) networks, industrial control systems, and manufacturing environments, where devices like programmable logic controllers, sensors, and engineering workstations share a single broadcast domain.

The following two mechanisms address this gap but work differently depending on how devices obtain their IP addresses:

• Proxy ARP (Address Resolution Protocol) is a technique where a network device (usually a router) answers ARP queries on behalf of another device.

• DHCP Relay Overwrite modifies the subnet mask and default gateway values in DHCP responses before the firewall forwards them to clients.

Once traffic passes through the firewall, the full range of security capabilities is available for enforcement, including App-ID™, User-ID™, Device-ID, Threat Prevention, WildFire®, and Device Security.

To implement this feature, configure Proxy ARP on the Layer 3 interface and configure DHCP Relay Overwrite on the DHCP relay interface. After configuration, verify that the traffic is passing through the firewall and matching your security policy rules.

PAN-OS now supports bandwidth as a path quality metric for SD-WAN traffic distribution. You can define bandwidth thresholds and sensitivity levels within SD-WAN Path Quality profiles to ensure links have sufficient capacity before the firewall selects them for application traffic. The firewall evaluates path quality based on jitter, latency, packet loss, and bandwidth, calculating real-time usage across all dataplanes to monitor link capacity.

During session setup, the firewall compares current link usage against your configured thresholds. If a link's usage exceeds the specified threshold, the system disqualifies that path to prevent congestion. By adding bandwidth to the path selection logic, you gain granular control over traffic steering, ensuring applications use links with available capacity while maintaining performance alongside existing jitter, latency, and packet loss parameters.

Security policy cannot inspect or control intra-VLAN traffic when devices on the same VLAN communicate directly at Layer 2. This visibility gap creates a security risk in operational technology (OT) environments that utilize flat network architectures. To redirect intra-VLAN traffic through the firewall and apply granular security rules, use OT Intra-VLAN Microsegmentation. This capability allows you to control device communication within the same broadcast domain by using two integrated mechanisms:

• Proxy ARP — Enables the firewall to respond to ARP requests on behalf of other devices on the VLAN, which forces local traffic to the firewall for inspection.

• DHCP Relay Overwrite — Modifies the subnet mask and default gateway in DHCP messages to assign each client a /32 host mask, ensuring the firewall remains the gateway for all client traffic.

To implement this architecture, configure Proxy ARP on Layer 3 VLAN aggregate interfaces and enable DHCP Relay Overwrite on the DHCP relay agent. You must also enable port isolation on managed switch ports to prevent devices from bypassing the firewall at Layer 2. By transitioning to this microsegmented model, you gain full visibility and can apply consistent security policy to all internal traffic.