Why are we introducing new FIPS enforcements?

MuleSoft is continuously improving the security posture of the Anypoint Platform as part of our commitment to providing a secure and compliant platform for our public sector customers. Our FIPS compliance journey is a key part of this effort. 

In 2024, MuleSoft successfully transitioned the underlying virtual machine images for CloudHub runtimes and Dedicated Load Balancers to a new version with a FIPS-validated OpenSSL cryptographic module enabled by default. This was communicated in our April 2024 release. This enhancement ensures that the operating system layer meets federal cryptographic standards.

Our current initiatives are a continuation of this work, and align with broader federal mandates like OMB M-22-09 and NIST SP 800-52 r2, and updated NIST guidance on cryptographic protocols. As we prepare for the industry-wide transition to FIPS 140-3, our forward-looking reviews have identified opportunities to strengthen the runtime by adopting modern protocols like TLS 1.3, removing obsolete algorithms like Triple-DES (3DES), and phasing out the use of SHA-1. Our goal is to ensure every layer of the runtime is robust, compliant, and secure for the future.

Could you explain the benefits of releasing foundational updates with significant changes as a patch version in MuleSoft?

These changes are necessary to ensure our products comply with the latest FIPS 140-2 standards as mandated by FedRAMP requirements. We understand the inconvenience and are committed to providing support during this transition to ensure compliance and security. 

Is there a checklist to help me prepare for this update?

Yes! Please review the guidance below on the steps you need to follow to ensure readiness and compatibility.  

1. Update Components: Review and update your applications. Please use the latest versions of all MuleSoft-provided components, including connectors, modules, and extensions. 

   1. Please note that some assets may have received major changes and will have associated documentation/upgrade guides on their respective pages.  If your applications use any custom-built or partner-built connectors or modules, please ensure that these also adhere to the same FIPS compliance requirements. Please review the following resources to upgrade your components: FIPS reference documentation

2. Keystores and Truststores: Convert any application keystores or truststores (e.g., JKS or PKCS12) to a FIPS-compliant format. Details in the link here.

Our applications are configured to run in FIPS mode and utilize JKS/PKCS12 keystores. Given that the cryptographic algorithms within our keystores are FIPS-compliant, what specific change in the runtime's FIPS enforcement model now makes the BCFKS format a mandatory requirement?

This upgrade transitions us from a FIPS-enabled to FIPS-enforced environment. Previously, cryptographic operations were handled by a FIPS-validated module, but JKS or PKCS12 keystores could still be managed by non-validated providers. With this new upgrade, the FIPS module will be the exclusive provider for all operations, including reading the keystore from disk.

The FIPS-validated module can only read keystores in its native BCFKS format when FIPS is enforced. This ensures that the entire lifecycle of your keys is managed by the FIPS-validated provider, providing a stronger, more verifiable chain of compliance.

This upgrade not only enhances security but also aligns our platform more closely with FedRAMP standards, ensuring we meet stringent federal security requirements and providing you with greater assurance and trust in our platform.

Will the applications stop working due to the Keystore enforcements even though they are technically FIPS compliant?

Yes. Even if your application exclusively utilizes FIPS-approved algorithms (such as AES-256 for data encryption and SHA-256 with RSA for signatures), it will still encounter issues if its keystores are in the JKS or PKCS12 format. The issue arises not from the keys or algorithms within the keystore, but from the keystore format itself. The failure occurs when the application attempts to load the keys and certificates from the keystore file.

According to our Mule logs, we are currently running in mule.security.model=fips-140-2 mode.  What changes are being implemented, and are there any changes at the JVM level affecting the level of enforcement?

Here are the technical details: 

1. Current State: In the current configuration, setting FIPS 140-2 flag tells the Mule Runtime to perform a prioritization of the FIPS-validated cryptographic provider (Bouncy Castle FIPS, or BCFIPS). It modifies the Java security provider list in memory to place the BCFIPS provider at the top. This ensures that for most standard cryptographic calls, the JVM selects the FIPS provider first. However, the other default Java providers (like SunJCE, etc.) are still present in the list, just with a lower priority.

2. The Change (New Enforced Mode): The new security upgrade makes a fundamental change to the Java security environment. Instead of simply prioritizing the FIPS provider, it removes all other non-validated cryptographic providers from the JVM's security provider list. This change is typically configured in the java.security file within the JVM's directory.

Impact of the JVM level Change: This move from prioritization to exclusivity is the core of the enforcement.

• With the new configuration, the FIPS module becomes the only provider available to handle cryptographic operations.

• It is no longer possible for the JVM to fall back to a non-FIPS provider for operations that the FIPS module doesn't handle.

• This directly impacts keystores. In the new enforced model, that fallback provider is gone, and the attempt to read a JKS/PKCS12 keystore will fail because the only available provider doesn't recognize the format when it is in a FIPS restricted mode of operation.

The JVM level changes modify the list of available cryptographic providers. This ensures a stricter, more verifiable level of enforcement where only FIPS-validated modules are used for the entire lifecycle of a cryptographic operation, from loading keys to performing encryption.

What will happen if I have an application using the Blowfish algorithm for secure property file encryption?

Blowfish is not a FIPS-compliant algorithm; therefore, the runtime will fail when attempting to use it. We request that customers replace the Blowfish algorithm with FIPS-compliant algorithms.

When are we able to test FIPS restrictions using Anypoint Studio?

Effective August 5, 2025, customers utilizing CloudHub 1.0 deployments will have the capability to select and download the FIPS 140-2 compliant runtime patch version. This version is available in Anypoint Studio and can be used to test and deploy their applications. For more details, please refer to the documentation.

What's the current test procedure for these FIPS restrictions?

For the FIPS 140-2 compliant runtime patch version, we perform all the necessary testing to ensure everything works. However, for customer applications, customers will need to make the necessary changes to run properly on the FIPS 140-2 compliant runtime patch version.

Why is the Scripting Module using Groovy engine throwing an MD5 error?

Mule applications that use the Scripting module with Groovy as the scripting engine in versions earlier than 4.0.24 rely on MD5 to hash the compiled cache. However, MD5 is not supported in FIPS-compliant environments.nt. To resolve this, it is needed to upgrade the dependency to a version greater than 4.0.24, and add the system property groovy.cache.hashing.algorithm=sha256 in order to switch from md5 to sha256.

Under shared library, this should now be as:

       <groupId>org.apache.groovy</groupId>
       <artifactId>groovy-jsr223</artifactId>

For the groovy dependency entry, change the groupId per below and use version 4.0.28:

  <dependency>
   <groupId>org.apache.groovy</groupId>
   <artifactId>groovy-jsr223</artifactId>
   <version>4.0.28</version>
  </dependency>

What changes are required if my applications are running in cluster mode?

If your applications are running in cluster mode, you must ensure that the encryption key used for communication between cluster nodes (mule.cluster.network.encryption.key) must be exactly 16, 24, or 32 bytes in length to meet encryption requirements. For more details, please refer to the documentation.

Is there a way to identify all applications that will be impacted by this change? 

Our static analysis tool can be used to review Mule applications that may need modifications to ensure compliance with FIPS 140-2. This tool scans for non-compliant Anypoint connectors and keystores and generates a report. While it may not cover all potential changes required for the application, it serves as an initial step in the compliance process. You can directly use this tool to scan your applications: link.

If your application is deployed on a hybrid / on-premise deployment model, please consider the additional questions in the following section:

Hybrid / On-premise deployments
(Mule runtimes hosted and managed in your own Data Centers or Private/Public Clouds)

What changes do I need to make? 

If you are interested in enforcing stricter FIPS compliance within your MuleSoft environments, please follow these steps:

1. Upgrade your environment and Runtime Version: Upgrade your Mule application to a FIPS-compliant runtime version. Setup your environment to be FIPS-compliant, following the instructions Configuration of a FIPS compliant runtime

2. Use a FIPS-compliant license: 

   1. Download a FIPS-complaint license: You will have 2 licenses - FIPS and non-FIPS compliant versions of Mule runtime license. The FIPS-compliant license (license-fips.lic) will be usable only in FIPS compliant environments. These licenses will be available on August 18th, 2025.

   2. Install the FIPS complaint license following the instructions Install an Enterprise License.

If your application is deployed on CloudHub 1.0, please consider the additional questions in the following section:

CloudHub 1.0 deployments

What changes are coming to Mule Runtimes? 

We are pleased to announce that on August 5, 2025, we released the patch versions for Mule 4.6 LTS and Mule 4.9 LTS runtime versions. These updates will ensure stricter compliance with FIPS 140-2 standards for all CloudHub 1.0 deployments, in alignment with FedRAMP requirements.

Starting September 15, 2025, these enhancements will be automatically applied to the runtime versions hosted within your MuleSoft GovCloud VPCs. 

Please note that this auto-patching will not affect runtimes within your data centers or private cloud-hosted VPCs.

What if I’m not ready to upgrade?

Customers requiring additional time to transition to the compliant version may request an exception to be patched with a non-FIPS compliant version. Before November 1, 2025, exempt customers will be able to use the exception runtime patch versions instead of the new runtime patch version with stricter enforcement of FIPS 140-2 standards. 

Please contact your Account team to request this exception. Please note that we require all customers to update to the latest patch version for Mule 4.6 LTS and Mule 4.9 LTS runtime versions by October 31, 2025. 

What can customers expect if they receive a FIPS exception?

MuleSoft Government Cloud customers with a FIPS exception will see “-exception” at the end of the patch version until October 31, 2025 (e.g., 4.9.8:6-exception). They can choose these “-exception” patch versions in both the UI and API to allow some time to make the necessary changes to onboard the new runtime version with stricter enforcement of FIPS 140-2 standards.

How will these changes impact our environments?

For all applications hosted on MuleSoft Government Cloud, the auto-patching scheduled for August 18, 2025 will be deferred to provide customers with additional time to implement the necessary changes. Starting September 15, 2025, these enhancements will be automatically applied to the runtime versions hosted within your MuleSoft Government Cloud VPCs.

When will the new patch versions be released?

The new Mule 4.9 and 4.6 runtime patch versions ensuring stricter compliance with FIPS 140-2 standards will be available on August 5, 2025 for the customers using CloudHub 1.0 deployment to test and deploy their applications. However, standalone customers using their own data centers or private cloud-hosted VPCs, will be able to use the new runtime version starting on August 18, 2025.

What will the customer experience entail?

The customer experience will remain seamless, with no major changes to the interface or functionality. Starting August 5, 2025, MuleSoft Government Cloud customers will have access to the new runtime patch version. Customers can select this version from the UI as well as from the API and use Anypoint Studio to test and run their applications. There will be no changes in the naming conventions of these versions; they will continue to appear as they currently do, for example, 4.9.8-java17, 4.6.21-java8, 4.6.21-java17, etc.

What is different about this new patch version? 

The previous update addressed OS layer of the FIPS compliance picture, while the new patch focuses on the application layer 

• Previous Changes (OS Layer): The change in Mule 4.4 was focused on the security uplift of the underlying Operating System. We transitioned the virtual machine images for CloudHub runtimes and Dedicated Load Balancers to a new version that uses a FIPS-validated cryptographic module at the kernel level. This ensures the foundational environment where the runtime operates is secure and compliant.

• New Patch (Application Layer): As part of our forward-looking security enhancements, we are strengthening the runtime's cryptographic provider configuration. This update modifies the Mule runtime environment to ensure it exclusively utilizes a FIPS validated cryptographic provider for all cryptographic operations, including key stores. This change prevents the use of deprecated ciphers or non-compliant modules and aligns with the most current FIPS 140-2 security standards.

Will there be an opportunity for patching in sandboxes prior to production? 

Yes, customers can perform necessary testing in their sandbox environments once the 4.6 and 4.9 patch versions are available on August 5, 2025. Also, we will always patch sandbox first before production. Please see the Patching Schedule.

Will this change impact both Prod and Non-Prod environments?

Yes, both prod and non-prod environments along with CH1 hosted shared VPC or Anypoint VPC will be impacted by this change.

Will my environment be auto-updated in August?

No, there will be no automatic updates in August 2025.  

Starting September 2025, we will auto-patch the apps using FIPS 140-2 compliance runtime patches.