PKCS#11 Certificate Authentication for Prisma Agent on Linux
Focus
Focus
Prisma Agent

PKCS#11 Certificate Authentication for Prisma Agent on Linux

Table of Contents

PKCS#11 Certificate Authentication for Prisma Agent on Linux

Learn how Prisma Agent on Linux uses PKCS#11 to authenticate with hardware-backed certificates stored in a TPM 2.0 chip.
Where Can I Use This?What Do I Need?
  • Prisma Agent on Linux
  • Minimum Prisma Agent version 26.4
  • Linux endpoint with a TPM 2.0 chip and tpm2-pkcs11 installed
  • Client Certificate authentication configured in Cloud Identity Engine
Enterprise and regulated organizations require Linux endpoints to use hardware-bound private keys. These keys must be non-exportable and cryptographically tied to the device so they can't be copied or extracted. Storing private keys as files on disk doesn't satisfy this requirement. Prisma® Agent on Linux uses the standard PKCS#11 interface to read client certificates and perform authentication signing operations directly inside the TPM 2.0 chip, keeping private keys hardware-locked at all times.
When certificate authentication is configured on your deployment, the agent automatically detects the TPM 2.0 PKCS#11 module on a Linux endpoint. The agent checks the TPM for a valid client certificate before consulting file-based certificate stores. If a matching TPM certificate is found, it is used for authentication. If no TPM certificate matches the configured criteria, the agent falls back to file-based certificates. If certificate authentication fails entirely and a fallback method is configured, the agent falls back to SAML.
The agent applies the same certificate filtering rules to TPM certificates as to file-based certificates: the certificate must be currently valid, must match the Extended Key Usage (EKU) OID (defaulting to client authentication, OID 1.3.6.1.5.5.7.3.2), and must match any issuer or subject criteria you configure through certificate selection settings. When the agent finds a matching certificate, it prompts the user to enter their hardware PIN, if applicable, to unlock the private key. Signing operations happen inside the TPM. No key material leaves the hardware. The PIN is cached for the duration of the session.
On deployments where GlobalProtect also uses certificate authentication on a shared gateway, the agent reuses an active PIN session rather than prompting users again, avoiding redundant authentication prompts.