After you upgrade to Prisma Agent 26.3 or 26.3.1, the ADEM tray icon no longer appears in the agent interface and ADEM telemetry data is not available in the ADEM dashboard. The ADEM service continues running on the endpoint.

On macOS endpoints, when a user logs out and the Prisma Agent switches to pre-logon mode, the user's session may not be removed from the gateway. The stale session persists until the session timeout expires. Pre-logon connectivity is not affected.

On macOS endpoints, after you upgrade macOS to 26.6.2, the Prisma Agent cannot retrieve the client certificate from the macOS keychain and does not send a client certificate during gateway authentication. All gateway pre-logon attempts are rejected with a client certificate validation error.

On Windows endpoints, Prisma Agent 26.3 repeatedly disconnects and reconnects when a third-party agent that uses a virtual network adapter is also running. Prisma Agent incorrectly identifies the virtual network adapter's routes as the physical network interface, causing repeated connection interruptions.

On macOS endpoints, after you upgrade to Prisma Agent 26.3, users receive repeated macOS keychain password prompts. The prompts appear even when the agent is not connected to a gateway and affect other applications that access the keychain.

On Windows endpoints, DNS resolution for internal domains configured as bypass traffic takes significantly longer on Prisma Agent 26.3 compared to previous versions. In deployments where Prisma Agent handles internet access and a third-party agent handles internal traffic, DNS queries for bypassed internal domains are not correctly routed through the third-party agent, causing resolution delays that slow access to internal applications.

In Always-On mode, running pacli connect gateway with any gateway name disconnects the active tunnel before validating whether the specified gateway is in the allowed gateway list. When the gateway is not found or is not authorized, the connection attempt fails and the agent remains in a disconnected state, allowing traffic to bypass the tunnel. This behavior occurs even though Always-On mode is intended to prevent tunnel disconnections and traffic bypass.

On Linux endpoints that use systemd-resolved for DNS (such as Ubuntu), DNS resolution stops working after you uninstall the Prisma Agent while the tunnel is connected. Because the agent does not restore the systemd-resolved configuration at uninstallation while the tunnel was up, the DNS service enters a broken state after uninstallation, preventing you from performing DNS resolution and connecting to the Endpoint Manager even after reinstallation. Endpoints that do not use systemd-resolved (such as Oracle Linux) are not affected.

Workaround: Before uninstalling the agent, disconnect from the endpoint manager by running pacli disconnect from the command line, or by clicking Sign Out in the agent interface. If DNS is already broken after uninstallation or reinstallation, restart systemd-resolved to restore name resolution:

sudo systemctl restart systemd-resolved

On Fedora endpoints connecting to a gateway where UDP is blocked, the Prisma Agent repeatedly attempts to fall back from IPSec to SSL and the agent service restarts after each failed attempt. While the service is restarting, the endpoint has no network connectivity. The restart loop continues until the service is manually restarted or the network interface is disabled and re-enabled.

Workaround: Restart the agent service to restore network connectivity:

sudo systemctl restart paa.service

Alternatively, disable and re-enable the network interface.

When you install or upgrade the Prisma Agent for Linux with the server_url field set in the config.json file, user authentication is triggered automatically during installation. In previous releases, the agent installed without prompting for authentication when server_url was pre-configured.

Client certificates that specify anyExtendedKeyUsage (OID 2.5.29.37.0) as their Extended Key Usage value are not accepted for certificate-based authentication. When you attempt to authenticate using one of these certificates, the agent reports an enrollment failure. Certificates that specify Client Authentication (OID 1.3.6.1.5.5.7.3.2) as their Extended Key Usage value are not affected.

Workaround: Re-issue the client certificate with an explicit Client Authentication Extended Key Usage value (OID 1.3.6.1.5.5.7.3.2).

On dual-stack networks where the router provides an IPv6 DNS server, DNS name resolution fails when the VPN tunnel is disconnected and the forwarding profile is configured with a Fail Safe default rule. The Prisma Agent for Linux blocks DNS queries sent to the IPv6 DNS server, so applications cannot resolve hostnames. On networks that provide only IPv6 DNS servers, the agent also cannot resolve the gateway address and cannot reconnect after the tunnel disconnects.

Workaround: Configure the network connection to use only IPv4 DNS:

nmcli connection modify connection-name ipv6.ignore-auto-dns yes
nmcli connection up connection-name

The first connection attempt to a new destination where the forwarding profile verdict resolves to Block does not receive an immediate refusal. Instead, the application appears unresponsive for 6 to 15 seconds before the connection times out. Subsequent connection attempts to the same destination receive an immediate denial.

Forwarding profile rules scoped to a specific source application intermittently do not match connections from that application. When the agent cannot resolve the full executable path of a short-lived process due to a timing condition, the connection is evaluated without matching the app-scoped rule and falls to a lower-priority rule instead. As a result, the same application connecting to the same destination can receive different verdicts across separate connection attempts with no configuration changes.

Forwarding profile rules that include source application conditions do not apply to IPv6 connections. The agent evaluates IPv6 connections without application identity, so connections match lower-priority rules instead of the intended app-scoped rules. Additionally, the IPv6 policy cache does not include application identity, so the first application to connect to an IPv6 destination determines the enforced verdict for all subsequent applications connecting to that same destination, regardless of which rules apply to each application.

Workaround: Use destination-only conditions for IPv6 forwarding profile rules. Avoid adding source application conditions to rules that target IPv6 destinations.

When you install the agent with the config.json file containing "unload_gp": true, GlobalProtect may remain active on endpoints where GlobalProtect runs as a per-user service, such as Red Hat Enterprise Linux 10. The pacli status command reports GlobalProtect as enabled even though the configuration specifies it should be disabled.

Workaround: Manually disable GlobalProtect using the GlobalProtect app on the endpoint.

On Linux endpoints running Docker, IPv6 name resolution from containers may fail intermittently when the forwarding profile is configured with a Best Available - Fail Open rule and the tunnel is connected without an IPv6 address. IPv4 name resolution is not affected.

Workaround: If name resolution fails for an IPv6 destination, retry the connection. Retrying the connection may resolve the issue.

On Linux endpoints running Docker, traffic between containers on the same host is evaluated against the forwarding profile instead of receiving the local network bypass. Forwarding profile rules can route container-to-container traffic through the tunnel or block it, even though the traffic does not leave the host. Additionally, Docker networks created after the agent starts are not included in the agent's local network list until the agent service restarts, so container-to-container traffic on those networks may not receive the expected bypass treatment.

Workaround: After creating a new Docker network, restart the agent service to update the local network list: sudo systemctl restart paa.service

On Ubuntu and Red Hat Enterprise Linux endpoints, when you install the agent with "unload_gp": true in the config.json file, GlobalProtect is disabled during installation but re-enables after a system restart. After the restart, both GlobalProtect and the Prisma Agent are active simultaneously, which can cause routing conflicts and prevent you from switching between them.

On Fedora endpoints, the Prisma Agent cannot maintain a stable SSL tunnel to gateways. When the tunnel is connected, SSL keep-alive packets do not route through the physical network interface and the tunnel disconnects within seconds of connecting. This prevents Host Information Profile (HIP) reports from being sent to the gateway, and the gateway rejects the HIP report submissions. This issue is specific to Fedora and does not occur on Ubuntu endpoints.

On Linux devices, the Prisma Agent does not reconnect to the internal gateway it was previously connected to after a temporary network disruption, such as an Ethernet cable disconnection and reconnection. Instead, the agent connects to the best available gateway.

On iOS endpoints, establishing a tunnel connection takes approximately 15 seconds. During this time, the Prisma Agent displays the connection in progress but does not connect immediately.

On iOS endpoints, if you close the system browser without completing SAML authentication, the Prisma Agent remains in the connecting state instead of returning to the disconnected state.

Workaround: Re-enroll the Prisma Agent using the same Endpoint Manager FQDN.