Compliance Frameworks

Overview

FusionAuth is in the process of conforming with various standards including the Federal Information Processing Standards (FIPS) and FedRAMP.

While full certification is not yet available, FusionAuth conforms and self-certifies compliance as appropriate. Since most compliance frameworks restrict encryption standards, this is currently the primary focus area.

Below you will find the status of FusionAuth’s compliance as well as details about the encryption in use.

Cryptographic and Encryption Functionality

Here is a non-exhaustive list of cryptographic and encryption functionality FusionAuth uses:

  • signing
  • encryption
  • password hashing

Signing

FusionAuth signs the items below using various cryptographic signature algorithms including HMAC, RSA, ECDSA, and EdDSA:

  • JWT signing
  • XML signing for SAML
  • Webhook signing
  • WebAuthN (Passkeys) signing

Encryption

FusionAuth encrypts the items below using various cryptographic algorithms including AES, RSA, and ECDSA:

  • XML encryption for SAML
  • Various encryption of plain-text passwords prior to being hashed
  • Encryption for all cookies that contain data
  • TLS connections to the database and search engine
  • TLS connections to Reactor (advanced threat detection and breached password detection)

Password Hashing

FusionAuth hashes the items below using various cryptographic algorithms including bcrypt, PBKDF2, MD5, SHA, and others:

  • Passwords
  • API keys

FusionAuth allows custom password hashing algorithms to be enabled via our plugin system. These custom algorithms are not checked for compliance.

FusionAuth also allows the password hashing algorithm to be changed per tenant, Application, or User. FusionAuth cannot certify that the algorithms used are secure or conform to any particular compliance framework.

FIPS Compliance

FusionAuth Reactor logo

This feature is only available in the Enterprise plan. Please visit our pricing page to learn more.

Beginning with version 1.62.0, FusionAuth supports a runtime mode that provides compliance with FIPS 140-3 cryptographic module restrictions.

This support is provided by Bouncy Castle’s FIPS compliant library, and is configurable via the fusionauth-app.fips.enabled configuration parameter (i.e. in fusionauth.properties, a command-line parameter, or an environment variable).

Details

The FIPS support in FusionAuth covers the main components of the FIPS 140-3 Level 1 standard. Here’s a list that outlines the main areas within FusionAuth that change when FIPS mode is enabled:

  • Passwords must be a minimum of 14 characters in length
  • The password used to connect to the database must be a minimum of 14 characters in length
  • RSA keys must be a minimum of 2048 bits in length
  • Deprecated algorithms, such as RSA 1024, are not allowed

Some items might provide validation errors, such as creating a Tenant with a password length minimum less than 14 characters. However, there are other features that might result in 500 responses from the API, such as importing invalid keys. Regardless, FusionAuth prevents most non-FIPS compliant configurations (see the note under Limitations for exceptions).

Additionally, FusionAuth is not FIPS certified. We’ve done our best to ensure FusionAuth is using FIPS compliant libraries and implementing the required FIPS validation, such as password lengths. However, we make no guarantees that FusionAuth is fully FIPS compliant or FIPS certified.

Limitations

Running FusionAuth in FIPS compliant mode has limitations:

  • FIPS mode may only be enabled on new installations of FusionAuth. An existing FusionAuth installation cannot be converted to run in FIPS mode.
  • All nodes in a cluster must be running in FIPS mode. Any node that is started in non-FIPS mode will automatically shutdown during the initialization process and write an error to the logs.
  • Customers must use a FIPS compliant database and search engine. FusionAuth does not provide the database or the search engine. It is your responsibility to use a FIPS compliant version of PostgreSQL, MySQL, and/or OpenSearch.
  • Currently, FIPS mode is only available for self-hosted instances.

It’s important to note that the FIPS version of Bouncy Castle doesn’t directly prohibit the use of some weak algorithms, such as MD5. This is in compliance with FIPS 140-3, since in some cases MD5 is allowed. Therefore, FusionAuth is unable to prevent the use of MD5 for password hashing in any meaningful way.

Based on this limitation, it is your responsibility to ensure that the FusionAuth is configured to use algorithms that are FIPS compliant, such as PBKDF2 or BCrypt.