You can configure PingFederate to use a hardware security module (HSM) for cryptographic material storage and operations. When configured, private keys and their corresponding certificate are stored on the HSM. Related signing and decryption operations are processed there for enhanced security. By default, even in HSM mode, dynamic OAuth and OpenID Connect signing and decryption keys are generated and stored in the memory of PingFederate cluster nodes. To ensure continuity after a full cluster restart, the decryption keys are also persisted to disk, and encrypted there with PingFederate's active configuration encryption key. To ensure OAuth and OpenID Connect keys are instead stored on the HSM, you must enable static keys.

You can also integrate PingFederate with a third-party software cryptographic solution.

Hardware security modules

Typically, integrating with an HSM involves two steps:

  1. Install and configure the HSM according to the manufacturer's documentation.
  2. Follow the vendor-specific instructions to configure a new or existing PingFederate environment to use the HSM for key generation, storage, and operation.

Use HSM hybrid mode to store each relevant key and certificate on the HSM or the local trust store. This allows you to transition the storage of keys and certificates to an HSM without needing to deploy a new PingFederate environment to mirror the setup. For more information, see Transitioning to an HSM.


Configuring PingFederate to use an HSM for cryptographic material storage and operations might impact performance. The level of impact depends on the performance of cryptographic functionality provided by the HSM and the network latency between PingFederate and the HSM. Consult with your HSM vendor for performance tuning if you plan to use an HSM in your PingFederate deployment.

Software cryptographic solution

PingFederate supports Bouncy Castle FIPS as the provider of its Java keystore and cryptographic operations.