FIPS 140-2edit

The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2), titled "Security Requirements for Cryptographic Modules" is a U.S. government computer security standard used to approve cryptographic modules. Elasticsearch offers a FIPS 140-2 compliant mode and as such can run in a FIPS 140-2 configured JVM.

The JVM bundled with Elasticsearch is not configured for FIPS 140-2. You must configure an external JDK with a FIPS 140-2 certified Java Security Provider. Refer to the Elasticsearch JVM support matrix for supported JVM configurations. See subscriptions for required licensing.

Compliance with FIPS 140-2 requires using only FIPS approved / NIST recommended cryptographic algorithms. Generally this can be done by the following:

  • Installation and configuration of a FIPS certified Java security provider.
  • Ensuring the configuration of Elasticsearch is FIPS 140-2 compliant as documented below.
  • Setting to true in elasticsearch.yml. Note - this setting alone is not sufficient to be compliant with FIPS 140-2.

Configuring Elasticsearch for FIPS 140-2edit

Detailed instructions for the configuration required for FIPS 140-2 compliance is beyond the scope of this document. It is the responsibility of the user to ensure compliance with FIPS 140-2. Elasticsearch has been tested with a specific configuration described below. However, there are other configurations possible to achieve compliance.

The following is a high-level overview of the required configuration:

  • Use an externally installed Java installation. The JVM bundled with Elasticsearch is not configured for FIPS 140-2.
  • Install a FIPS certified security provider .jar file(s) in Elasticsearch’s lib directory.
  • Configure Java to use a FIPS certified security provider (see below).
  • Configure Elasticsearch’s security manager to allow use of the FIPS certified provider (see below).
  • Ensure the keystore and truststore are configured correctly (see below).
  • Ensure the TLS settings are configured correctly (see below).
  • Ensure the password hashing settings are configured correctly (see below).
  • Ensure the cached password hashing settings are configured correctly (see below).
  • Configure elasticsearch.yml to use FIPS 140-2 mode, see (below).
  • Verify the security provider is installed and configured correctly (see below).
  • Review the upgrade considerations (see below) and limitations (see below).

Java security provideredit

Detailed instructions for installation and configuration of a FIPS certified Java security provider is beyond the scope of this document. Specifically, a FIPS certified JCA and JSSE implementation is required so that the JVM uses FIPS validated implementations of NIST recommended cryptographic algorithms.

Elasticsearch has been tested with Bouncy Castle’s bc-fips and bctls-fips 1.0.17. Please refer to the [Support Matrix] for details on which combinations of JVM and security provider are supported in FIPS mode. Elasticsearch does not ship with a FIPS certified provider. It is the responsibility of the user to install and configure the security provider to ensure compliance with FIPS 140-2. Using a FIPS certified provider will ensure that only approved cryptographic algorithms are used.

To configure Elasticsearch to use additional security provider(s) configure Elasticsearch’s JVM property to point to a file (example) in Elasticsearch’s config directory. Ensure the FIPS certified security provider is configured with the lowest order. This file should contain the necessary configuration to instruct Java to use the FIPS certified security provider.

Java security manageredit

All code running in Elasticsearch is subject to the security restrictions enforced by the Java security manager. The security provider you have installed and configured may require additional permissions in order to function correctly. You can grant these permissions by providing your own Java security policy

To configure Elasticsearch’s security manager configure the JVM property to point a file (example)in Elasticsearch’s config directory with the desired permissions. This file should contain the necessary configuration for the Java security manager to grant the required permissions needed by the security provider.

Elasticsearch Keystoreedit

FIPS 140-2 (via NIST Special Publication 800-132) dictates that encryption keys should at least have an effective strength of 112 bits. As such, the Elasticsearch keystore that stores the node’s secure settings needs to be password protected with a password that satisfies this requirement. This means that the password needs to be 14 bytes long which is equivalent to a 14 character ASCII encoded password, or a 7 character UTF-8 encoded password. You can use the elasticsearch-keystore passwd subcommand to change or set the password of an existing keystore. Note that when the keystore is password-protected, you must supply the password each time Elasticsearch starts.


SSLv2 and SSLv3 are not allowed by FIPS 140-2, so SSLv2Hello and SSLv3 cannot be used for ssl.supported_protocols.

The use of TLS ciphers is mainly governed by the relevant crypto module (the FIPS Approved Security Provider that your JVM uses). All the ciphers that are configured by default in Elasticsearch are FIPS 140-2 compliant and as such can be used in a FIPS 140-2 JVM. See ssl.cipher_suites.

TLS keystores and keysedit

Keystores can be used in a number of General TLS settings in order to conveniently store key and trust material. Neither JKS, nor PKCS#12 keystores can be used in a FIPS 140-2 configured JVM. Avoid using these types of keystores. Your FIPS 140-2 provider may provide a compliant keystore implementation that can be used, or you can use PEM encoded files. To use PEM encoded key material, you can use the relevant \*.key and *.certificate configuration options, and for trust material you can use *.certificate_authorities.

FIPS 140-2 compliance dictates that the length of the public keys used for TLS must correspond to the strength of the symmetric key algorithm in use in TLS. Depending on the value of ssl.cipher_suites that you select to use, the TLS keys must have corresponding length according to the following table:

Table 81. Comparable key strengths

Symmetric Key Algorithm

RSA key Length

ECC key length










Stored password hashingedit

While Elasticsearch offers a number of algorithms for securely hashing credentials on disk, only the PBKDF2 based family of algorithms is compliant with FIPS 140-2 for stored password hashing. However, since PBKDF2 is essentially a key derivation function, your JVM security provider may enforce a 112-bit key strength requirement. Although FIPS 140-2 does not mandate user password standards, this requirement may affect password hashing in Elasticsearch. To comply with this requirement, while allowing you to use passwords that satisfy your security policy, Elasticsearch offers pbkdf2_stretch which is the suggested hashing algorithm when running Elasticsearch in FIPS 140-2 environments. pbkdf2_stretch performs a single round of SHA-512 on the user password before passing it to the PBKDF2 implementation.

You can still use one of the plain pbkdf2 options instead of pbkdf2_stretch if you have external policies and tools that can ensure all user passwords for the reserved, native, and file realms are longer than 14 bytes.

You must set the setting to one of the available pbkdf_stretch_* values. When FIPS-140 mode is enabled, the default value for is pbkdf2_stretch. See User cache and password hash algorithms.

Password hashing configuration changes are not retroactive so the stored hashed credentials of existing users of the reserved, native, and file realms are not updated on disk. To ensure FIPS 140-2 compliance, recreate users or change their password using the elasticsearch-user CLI tool for the file realm and the create users and change password APIs for the native and reserved realms. Other types of realms are not affected and do not require any changes.

Cached password hashingedit

ssha256 (salted sha256) is recommended for cache hashing. Though PBKDF2 is compliant with FIPS-140-2, it is — by design — slow, and thus not generally suitable as a cache hashing algorithm. Cached credentials are never stored on disk, and salted sha256 provides an adequate level of security for in-memory credential hashing, without imposing prohibitive performance overhead. You may use PBKDF2, however you should carefully assess performance impact first. Depending on your deployment, the overhead of PBKDF2 could undo most of the performance gain of using a cache.

Either set all cache.hash_algo settings to ssha256 or leave them undefined, since ssha256 is the default value for all cache.hash_algo settings. See User cache and password hash algorithms.

The user cache will be emptied upon node restart, so any existing hashes using non-compliant algorithms will be discarded and the new ones will be created using the algorithm you have selected.

Configure Elasticsearch elasticsearch.ymledit

  • Set to true in elasticsearch.yml. This setting is used to ensure to configure some internal configuration to be FIPS 140-2 compliant and provides some additional verification.
  • Set to false. This will disable the automatic configuration of the security settings. Users must ensure that the security settings are configured correctly for FIPS-140-2 compliance. This is only applicable for new installations.
  • Set appropriately see above.
  • Other relevant security settings. For example, TLS for the transport and HTTP interfaces. (not explicitly covered here or in the example below)
  • Optional: Set in elasticsearch.yml to ensure the required security providers (8.13+). see below. true false ["BCFIPS", "BCJSSE"] "pbkdf2_stretch"

Verify the security provider is installededit

To verify that the security provider is installed and in use, you can use any of the following steps:

  • Verify the required security providers are configured with the lowest order in the file pointed to by For example, security.provider.1 is a lower order than security.provider.2
  • Set in elasticsearch.yml to the list of required security providers. This setting is used to ensure that the correct security provider is installed and configured. (8.13+) If the security provider is not installed correctly, Elasticsearch will fail to start. ["BCFIPS", "BCJSSE"] are the values to use for Bouncy Castle’s FIPS JCE and JSSE certified provider.

Upgrade considerationsedit

Elasticsearch 8.0+ requires Java 17 or later. Elasticsearch 8.13+ has been tested with Bouncy Castle's Java 17 certified FIPS implementation and is the recommended Java security provider when running Elasticsearch in FIPS 140-2 mode. Note - Elasticsearch does not ship with a FIPS certified security provider and requires explicit installation and configuration.

Alternatively, consider using Elasticsearch Service in the FedRAMP-certified GovCloud region.

Some encryption algorithms may no longer be available by default in updated FIPS 140-2 security providers. Notably, Triple DES and PKCS1.5 RSA are now discouraged and Bouncy Castle now requires explicit configuration to continue using these algorithms.

If you plan to upgrade your existing cluster to a version that can be run in a FIPS 140-2 configured JVM, we recommend to first perform a rolling upgrade to the new version in your existing JVM and perform all necessary configuration changes in preparation for running in FIPS 140-2 mode. You can then perform a rolling restart of the nodes, starting each node in a FIPS 140-2 JVM. During the restart, Elasticsearch:

  • Upgrades secure settings to the latest, compliant format. A FIPS 140-2 JVM cannot load previous format versions. If your keystore is not password-protected, you must manually set a password. See Elasticsearch Keystore.
  • Upgrades self-generated trial licenses to the latest FIPS 140-2 compliant format.

If your subscription already supports FIPS 140-2 mode, you can elect to perform a rolling upgrade while at the same time running each upgraded node in a FIPS 140-2 JVM. In this case, you would need to also manually regenerate your elasticsearch.keystore and migrate all secure settings to it, in addition to the necessary configuration changes outlined below, before starting each node.


Due to the limitations that FIPS 140-2 compliance enforces, a small number of features are not available while running in FIPS 140-2 mode. The list is as follows:

  • Azure Classic Discovery Plugin
  • The elasticsearch-certutil tool. However, elasticsearch-certutil can very well be used in a non FIPS 140-2 configured JVM (pointing ES_JAVA_HOME environment variable to a different java installation) in order to generate the keys and certificates that can be later used in the FIPS 140-2 configured JVM.
  • The SQL CLI client cannot run in a FIPS 140-2 configured JVM while using TLS for transport security or PKI for client authentication.