Elasticsearch supports the following FIPS compliant modes:

• FIPS 140-2
• FIPS 140-3

Compliance with FIPS 140-2 or FIPS 140-3 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 compliant as documented below.
• Settingxpack.security.fips_mode.enabled totrue inelasticsearch.yml. Note - this setting alone is not sufficient to be compliant with FIPS.

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

Here 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.
• Install a FIPS certified security provider .jar file(s) in Elasticsearch'slib 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).
• Configureelasticsearch.yml to use FIPS mode (refer to the section below).
• Verify the security provider is installed and configured correctly (refer to the section below).
• Review the upgrade considerations (refer to the section below) and limitations (refer to the section below).

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

Elasticsearch has been tested withBouncy Castle FIPS libraries. The required libraries depend on whether you are configuring for FIPS 140-2 or FIPS 140-3 compliance:

For FIPS 140-2 compliance:

• bc-fips 1.0.2.6
• bctls-fips 1.0.19

For FIPS 140-3 compliance:

• bc-fips 2.0.1
• bctls-fips 2.0.22
• bcutil-fips 2.0.5

Refer to the ElasticsearchJVM 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 FIPS compliance. Using a FIPS certified provider ensures that only approved cryptographic algorithms are used.

To configure Elasticsearch to use additional security provider(s) configure Elasticsearch'sJVM propertyjava.security.properties to point to a file (example) in Elasticsearch'sconfig 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.

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 ownJava security policy

To configure Elasticsearch's security manager configure the JVM propertyjava.security.policy to point a file (example)in Elasticsearch'sconfig 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.

FIPS (as specified in 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'ssecure 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 theelasticsearch-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, soSSLv2Hello andSSLv3 cannot be used forssl.supported_protocols.

Keystores can be used in a number ofGeneral TLS settings to conveniently store key and trust material. NeitherJKS, norPKCS#12 keystores can be used in a FIPS-configured JVM. Avoid using these types of keystores. Your FIPS provider can 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 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 ofssl.cipher_suites that you select to use, the TLS keys must have corresponding length according to the following table:

While Elasticsearch offers a number of algorithms for securely hashing credentials on disk, only thePBKDF2 based family of algorithms is compliant with FIPS for stored password hashing. However, sincePBKDF2 is essentially a key derivation function, your JVM security provider may enforce a112-bit key strength requirement. Although FIPS 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 offerspbkdf2_stretch which is the suggested hashing algorithm when running Elasticsearch in FIPS environments.pbkdf2_stretch performs a single round of SHA-512 on the user password before passing it to thePBKDF2 implementation.

You must set thexpack.security.authc.password_hashing.algorithm setting to one of the availablepbkdf_stretch_* values. When FIPS mode is enabled, the default value forxpack.security.authc.password_hashing.algorithm ispbkdf2_stretch. Refer toUser 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 compliance, recreate users or change their password using theelasticsearch-user CLI tool for the file realm and thecreate users andchange password APIs for the native and reserved realms. Other types of realms are not affected and do not require any changes.

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

Either set allcache.hash_algo settings tossha256 or leave them undefined, sincessha256 is the default value for allcache.hash_algo settings. Refer toUser 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.

• Setxpack.security.fips_mode.enabled totrue inelasticsearch.yml. This setting enables all verification and functionality required for FIPS compliance.
• Setxpack.security.autoconfiguration.enabled tofalse. This turns off the automatic configuration of the security settings. Users must ensure that the security settings are configured correctly for FIPS compliance. This is only applicable for new installations.
• Setxpack.security.authc.password_hashing.algorithm appropriately. Refer to thestored password hashing section.
• Other relevant security settings. For example, TLS for the transport and HTTP interfaces. (not explicitly covered here or in the example below)
• Optional: Setxpack.security.fips_mode.required_providers inelasticsearch.yml to enforce the required security providers (8.13+). Refer to theverify security provider section.

xpack.security.fips_mode.enabled: truexpack.security.autoconfiguration.enabled: falsexpack.security.fips_mode.required_providers: ["BCFIPS", "BCJSSE"]xpack.security.authc.password_hashing.algorithm: "pbkdf2_stretch"

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 byjava.security.properties. For example,security.provider.1 is a lower order thansecurity.provider.2
• Setxpack.security.fips_mode.required_providers inelasticsearch.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 fails to start.

Thexpack.security.fips_mode.required_providers setting supports two formats:

• Name only:["BCFIPS", "BCJSSE"] — verifies that the named providers are installed.
• Name and version:["BCFIPS:2*", "BCJSSE:2*"] — verifies both the provider name and version. The version supports simple wildcard patterns (for example,2* matches any version starting with2).

The name-and-version format is useful when you need to verify that a specific version of the security provider is in use, such as distinguishing between Bouncy Castle 1.x (FIPS 140-2) and 2.x (FIPS 140-3) libraries.

Elasticsearch 8.0+ requires Java 17 or later. Elasticsearch has been tested withBouncy Castle's FIPS implementations and is the recommended Java security provider when running Elasticsearch in FIPS mode:

• For FIPS 140-2: Bouncy Castle 1.x libraries (certified)
• For FIPS 140-3: Bouncy Castle 2.x libraries (certified)

Note that Elasticsearch does not ship with a FIPS certified security provider and requires explicit installation and configuration.

Alternatively, consider using Elastic Cloud Hosted in theFedRAMP-certified GovCloud region.

If you plan to upgrade your existing cluster to a version that can be run in a FIPS-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 mode. You can then perform a rolling restart of the nodes, starting each node in a FIPS-configured JVM. During the restart, Elasticsearch:

• Upgradessecure settings to the latest, compliant format. A FIPS-configured JVM cannot load previous format versions. If your keystore is not password-protected, you must manually set a password. Refer toElasticsearch Keystore.
• Upgrades self-generated trial licenses to the latest FIPS compliant format.

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

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

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