What’s New in Palo Alto Networks Trust Protection Foundation

Palo Alto Networks Trust Protection Foundation version 26.2 introduces some significant enhancements across all product lines. In the list below, features related to ideas posted and voted on in the Product Ideas Community are marked with a double caret: ^^ followed by the idea number.

IMPORTANT! Before upgrading to version 26.2, carefully review Important Considerations Before Upgrading.

Certificate Manager - Self-Hosted

  • New Upgrade Readiness tool - Trust Protection Foundation 26.2 includes UpgradeReadiness.exe, a new tool that checks a server before you install or upgrade. It finds problems that cause upgrades to fail, like missing prerequisites, service account rights, database issues, and upgrades that didn’t finish. It replaces the PreFlight tool.

    The tool is in the release .zip file, and you don’t need to install it. Run it as an administrator on each server. By default it only checks your server and doesn’t make changes. It can also fix some problems for you with the -fix-all or -fix-only option. Results are saved as HTML and JSON reports.

    For more information, see Check a server before you install or upgrade (Upgrade Readiness).

  • SCEP certificate renewal without a challenge password - Network devices can now renew a SCEP certificate by signing the request with the certificate they already hold, so there is no challenge password to distribute, rotate, or store on the device. Trust Protection Foundation accepts both the dedicated RenewalReq message defined in RFC 8894 and the older renewal flow, so each device can use whichever form it implements.

    A renewal keeps the certificate in the folder where it already lives, and it can move the certificate to a different issuing CA, which turns a fleet-wide CA migration into a configuration change rather than a re-enrollment project. For more information, see About SCEP certificate renewal.

  • Global password rules - Administrators can now set password requirements for local user accounts, certificate private key downloads, and software encryption key exports. In earlier releases, these password checks were fixed. A rule sets requirements such as minimum length.

    Built-in default rules keep the password requirements from earlier releases. You can choose another built-in rule or create your own. A certificate policy folder can use a different rule for private key downloads.

    For more information, see Global password rules.

  • Palo Alto Networks Firewall Log Discovery - A new discovery job type finds the TLS servers on your internal network that clients connect to. The job reads the decryption log of a Palo Alto Networks next-generation firewall, makes a list of internal servers from the log, and scans only those servers. Because of this, the job can find servers that are not in any scan range, and it does not scan addresses where there is no server.

    The scan works the same as network discovery, and placement rules, exclusions, schedules and blackout times work the same way. Each run continues from where the previous run stopped in the log. A read-only firewall account is sufficient.

    For more information, see Using Palo Alto Networks Firewall Log Discovery.

  • Domain Control Validation (DCV) monitoring - Administrators can now see the domain validation status of their public CA accounts without signing in to each CA console. If a validation expires and nobody notices, certificate requests for that domain fail. DCV monitoring works with DigiCert CertCentral, Sectigo Certificate Manager, GlobalSign MSSL, and HID PKIaaS.

    In Web Admin, a new Domain Control Validation tab on the CA Template object shows the status and expiration date of each domain. Trust Protection Foundation updates this data once a day and logs an event when a validation will expire soon or has expired.

    For more information, see About Domain Control Validation (DCV) Monitoring.

  • Root Certificates page – Administrators can now manage root and intermediate root certificates from the Platform product in the Aperture console. In earlier releases, you could manage these certificates only from the Roots tree in Policy Tree, which is still available.

    By switching to Platform and selecting Configuration > Root Certificates from the top menu, you can import, view, filter, download, enable or disable, and delete root and intermediate root certificates.

    For more information, see Managing root certificates.

Code Sign Manager - Self-Hosted

  • Signing pre-approvals now visible and cancelable from the Approvals page - Key Use Approvers can now see and manage signing pre-approvals directly in the web interface. A new Pre-Approvals view on the Approvals page lists every pre-approval along with its Project, Environment, key user, validity window, and whether it’s single-use, so you can tell at a glance what has been pre-approved. Approvers can also select one or more pre-approvals and cancel them to revoke them immediately, without having to use the API. Learn more.

SSH Manager

  • AuthZHelper has its own release cycle - Starting with 26.2, AuthZHelper is released separately from Trust Protection Foundation and is available from a AuthZHelper-specific download site. New AuthZHelper versions release when features or security fixes are ready, and each supported version works with all supported versions of Trust Protection Foundation.

  • Approve SSH keys and block all others - SSH Key Authorization Rules now support positive authorization. After you review the keys observed for a host and account, mark the legitimate keys as Allowed and switch the rule to Enforce. Only the allowed keys can then log in to that account; any other key is denied automatically (implicit deny).

    • Observe remains the default, so no keys are blocked except Denied until you choose to enforce a rule.
    • Switching a rule to Enforce asks for confirmation, because it immediately blocks every key that isn’t marked as Allowed.
    • Each implicitly denied attempt is logged and listed in the rules inventory, so you can review the key and then allow or deny it.

    For more information, see Managing and monitoring SSH Key Authorization Rules.

  • Automate SSH Key Authorization Rules with the WebSDK API - New WebSDK methods let your scripts and pipelines manage SSH Authorization Rules without using the web interface:

    • Find rules, hosts and keys, with filters and paging.
    • Allow or deny a key under a rule, and switch a rule between Observe and Enforce modes.
    • Revoke a key on all hosts.

    The API follows the same rules as the web interface. Tokens need the sshrules OAuth scope.

    For more information, see SSH authorization rules API reference.

  • See why agentless discovery can’t fully scan a host - Agentless SSH discovery now tells you when a host’s configuration keeps it from working, such as missing sudo access or file permissions.

    • Under Inventory > Devices, the SSH Scan Status column shows Complete with warnings when discovery finished but couldn’t read part of the host, such as sshd_config or users’ custom home directories. Some keys may be missing for that host. You can filter the device list by this status.
    • If discovery can’t read sshd_config, it now keeps the last configuration it read instead of discarding it.
    • The Latest Update column shows why discovery couldn’t connect to or run on a host, for example invalid credentials or sudo permissions denied.
    • Enhanced activity log messages record each step discovery runs on the host, so you can find and fix the cause.
    • Critical differences between agent-based and agentless results on the same hosts are fixed.

    For more information, see Performing agentless discovery of SSH keys on demand.

  • Documentation updates: More reliable permissions for SSH Key scans - SSH Manager 26.2 now uses a standard list of 13 commands to discover and remediate SSH keys on target servers.

    • One-time setup: Configure sudo or PAM permissions once for your SSH service account.
    • Cross-version compatibility: Your permission rules will continue to work without changes after future software upgrades.
    • Least privilege: Grant access only to required commands (ls, stat, grep, sha256sum, mkdir, touch, chmod, chown, cp, rm, echo, hostname, host) instead of full administrative access.

    For more information, see About using sudo.

  • Documentation updates: Agent vs. Agentless discovery differences - The SSH Manager documentation is updated to clarify key functional differences between Server Agent and Agentless discovery methods:

    • Agentless Discovery: Evaluates sshd_config and queries system user databases (e.g., using getent) to accurately detect authorized keys and map ownership, even in environments with custom AuthorizedKeysFile directives or non-standard home directories.
    • Server Agent Discovery: Evaluates standard path conventions and folder names, which may not detect all keys or correctly attribute key ownership when custom paths or non-standard home directories are used.

    For more information, see Setting up SSH Manager for agent and agentless discovery.

  • Enhanced SSH authorization rules UI and standardized access states - To improve report scannability and operational clarity when auditing and managing SSH access, the SSH Key Authorization Rules user interface has been updated with streamlined terminology and standardized access states, such as the new “Effective Access” column that replaces the legacy lock/unlock icons in the main Rules grid.

    The enhancements make it easier for administrators to distinguish between administrative overrides, compliance profile enforcement, and key lifecycle states at a glance. For more information, see SSH Key Authorization Rules and AuthZHelper.

Driver Integrations

  • Panorama certificate discovery and provisioning - Trust Protection Foundation now manages certificates across your whole firewall fleet through Panorama, instead of connecting to each firewall one at a time. Discovery reads certificates from Panorama’s shared configuration, templates, and template stacks, and scans Device Groups for certificates used in decryption rules. Provisioning pushes renewed certificates and private keys back into Panorama for distribution to the firewalls it manages. Discovery and provisioning support RSA and ECC (P-256, P-384). Post-quantum certificates are discovered but cannot be provisioned. Learn more.

  • Onboard discovery for Palo Alto Networks firewalls - The Palo Alto Networks firewall driver now runs onboard discovery against the device’s own configuration, so the certificates behind SSL decryption and the management web interface are inventoried automatically instead of needing bulk provisioning scripts. Discovery records how each certificate is used and understands the certificate lists introduced in PAN-OS 10.2, where one rule can carry several certificates. Provisioning now covers SSL Inbound Inspection and virtual systems (vsys), and both discovery and provisioning support ECC (P-256 and P-384) alongside RSA. Learn more.

  • Optional Azure Tenant ID for Azure Key Vault applications - Configuring an Azure Key Vault application no longer requires you to look up and enter the Azure Tenant ID. Leave the field empty and Trust Protection Foundation reads the tenant from the key vault the first time it connects, then saves it on the application. A Tenant ID you enter yourself is never overwritten. Learn more.

  • Certificate inventory from Next-Gen Trust Security - The certificate import and Kubernetes discovery jobs can now pull inventory from Next-Gen Trust Security, so hybrid customers moving from Certificate Manager, SaaS keep full visibility in Trust Protection Foundation. When a certificate is expired or revoked in Next-Gen Trust Security, Trust Protection Foundation updates the status of the matching record and moves its metadata to the historical tab instead of disabling the local object. Kubernetes discovery creates the matching cluster, namespace, and container objects for you. Learn more.

  • NGTS CA driver - A first-party CA driver issues private certificates from the Next-Gen Trust Security certificate authority. The CA object lists the key types the NGTS issuing template allows, so you can see what a template will accept before you use it, and the issuing chain is returned with each certificate. Learn more.

  • Google Cloud CAS certificate template selection - A CA template can now select the Google certificate template it uses from a list, instead of you standing up a separate Google certificate authority for each profile. This lets you point several CA templates at a single Google certificate authority and still issue client, server, and user certificates. When a Google certificate template is selected, its use is recorded as a log event on each certificate issued, and a second event is logged whenever the template’s maximum lifetime caps the validity period you asked for, naming both the requested and the issued number of days. Existing CA templates keep working unchanged. Learn more.

  • Microsoft CA post-quantum issuance - Issuing ML-DSA certificates (FIPS 204 parameter sets 44, 65, and 87) through the Microsoft CA driver is now validated against a standalone Windows Server 2025 certificate authority. Learn more.

  • Wider algorithm support in application drivers - The CAPI, F5 LTM, and JKS drivers each accept a wider set of RSA and ECC algorithms than they did before. When a driver is asked for an algorithm it cannot handle, it now fails the request before it contacts the device, so you get a clear error instead of a device-side failure partway through provisioning. On the F5 LTM driver, that pre-check covers on-device key generation, which supports RSA 1024, 2048, 4096, and 8192, and the EC P-256 and P-384 curves.

  • CAPI: post-quantum keys, more resilient provisioning, and HTTPS-only WinRM - The CAPI driver now generates ML-DSA keys (FIPS 204 parameter sets 44, 65, and 87), both centrally and remotely, on Windows Server 2025 and later. These certificates go into the Windows certificate store, but they cannot be used for IIS or TLS bindings, because Windows does not yet support ML-DSA for TLS, and onboard discovery does not find them, because it only finds certificates bound to IIS. Provisioning is also more resilient: remote scripts get a five-minute timeout, temporary Kerberos and WinRM login failures are retried automatically, and failures are logged with more detail. A new WinRMRequireHttps option makes the driver skip every HTTP WinRM attempt and connect over HTTPS only. Set it on each engine as a REG_DWORD value of 1 under HKLM\SOFTWARE\Venafi\Platform; a REG_SZ value throws an error. Learn more.

  • F5 LTM: one certificate across many virtual servers - A single certificate and key can now be assigned to several virtual servers from one F5 LTM Advanced application. The separate Virtual Server and Partition fields are replaced by a single list of virtual servers, so you can meet HSM-mandated compliance requirements without duplicate private keys or manual configuration in the F5 interface. The key is generated once per certificate, no matter how many virtual servers use it. Learn more.