# mulesoft MuleSoft Government Cloud - Full Documentation --- product: MuleSoft Government Cloud --- # Anypoint VPN Configuration > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use [Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-about) to create a secure connection between your MuleSoft Government Cloud deployment environment inside a Virtual Private Cloud (VPC) and your on-premises network. You can create multiple site-to-site VPNs if required. ## Government Cloud IPsec Settings Anypoint VPN supports the following IPsec settings in the Government Cloud environment: - IKE version 1 - IKE version 2 for route-based VPNs only - AES 128 or 256-bit encryption operating in the CBC and GCM - SHA-2 (256, 384, 512) hashing - Diffie-Hellman Phase 1 groups 14-21 - Diffie-Hellman Phase 2 groups 14-21 - Timeouts for IKEv1 - IKE (Phase 1) Lifetime: 28800 seconds (8 hours) - IPsec (Phase 2) Lifetime: 3600 seconds (1 hour) - Timeouts for IKEv2 - IKE (Phase 1) Lifetime: 28000 seconds (7 hours and 50 minutes) - IPsec (Phase 2) Lifetime: 3000 seconds (50 minutes) ## See Also - [Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-about) --- product: MuleSoft Government Cloud --- # Dedicated Load Balancer Configuration > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A MuleSoft Government Cloud dedicated load balancer enables you to route external HTTP and HTTPS traffic to multiple Mule applications deployed into MuleSoft Government Cloud workers inside a Virtual Private Cloud (VPC). Each MuleSoft Government Cloud dedicated load balancer is assigned to an Anypoint VPC, and that Anypoint VPC runs within a particular service region. The dedicated load balancer routes both external and VPC-internal traffic to MuleSoft Government Cloud workers deployed into that Anypoint VPC. The MuleSoft Government Cloud load balancer redirects requests, where `_myApp_` is the name of the Mule application deployment to MuleSoft Government Cloud: - HTTP requests to `http://myApp.cloudhub.io` redirects to `mule-worker-myApp.cloudhub.io:8081` - HTTPS traffic to `https://myApp.cloudhub.io:443` redirects to `https://mule-worker-myApp.cloudhub.io:8082` The load balancer listens for outside requests over HTTPS and, by default, communicates internally with your worker over HTTP. If you configured your Mule application within the Anypoint VPC to listen on HTTPS, make sure you set `upstreamProtocol` to `HTTPS` when creating the mapping list using the [`load-balancer mappings add`](https://docs.mulesoft.com/anypoint-cli/latest/cloudhub-dlb#cloudhub-load-balancer-mappings-add) command. ## Route External Requests to the Dedicated Load Balancer A MuleSoft Government Cloud dedicated load balancer provides an alternative domain name to route HTTP requests to Mule applications listening on port 8091 and HTTPS requests to Mule applications listening on port 8092. You can also use mapping rules to rename requests to the MuleSoft Government Cloud dedicated load balancer to a different Mule application domain name. The MuleSoft Government Cloud dedicated load balancer exposes an external domain name that resolves to two public IP addresses that are accessible from outside your MuleSoft Government Cloud Anypoint VPC network. `_lb-name_` is the name you gave the load balancer when you created it: \_lb-name.lb-gprod-rt.anypointdns.net ## Rename External Mule Application URLs Through a Dedicated Load Balancer You can create a mapping rule to rename the Mule application, so it can be accessed through a different domain name. For example, suppose you deploy a Mule application named myApp-myCompany-prod.cloudhub.io. MuleSoft Government Cloud domain names must be globally unique among every other MuleSoft Government Cloud customer and Mule application. A dedicated load balancer helps you hide this naming complexity within your corporate DNS domain name. You can set a mapping rule in your dedicated load balancer so external clients can access the Mule application on `http://myApp.lb-name.lb-gprod-rt.anypointdns.net` or `https://myApp.lb-name.lb-gprod-rt.anypointdns.net:443`. In addition, you can set a CNAME record in your corporate DNS nameserver to map the `lb-name.lb-gprod-rt.anypointdns.net` domain to your company’s "vanity" domain. For example, suppose your company owns the DNS domain `example.com`. You can create a CNAME record to route requests to `myapp.example.com` to `myApp.lb-name.lb-gprod-rt.anypointdns.net`. This hides the complexity of the MuleSoft Government Cloud domain name in the `cloudhub.io` domain. ## Route Internal Requests to the Dedicated Load Balancer The Government Cloud dedicated load balancer has an internal domain name that is used by applications and clients within Anypoint VPC. The internal domain uses the following naming convention, in which `_lb-name_` is the name you gave the load balancer when you created it: internal-\_lb-name\_.lb-gprod-rt.anypointdns.net Each Dedicated Load Balancer has a DNS A record `_lb-name_.lb-gprod-rt.anypointdns.net` that resolves to the two public IP addresses of the two instances. Through your DNS provider, you can add a CNAME record pointing to this A record and use your domain names to access it. If you want your load balancer to manage all connections to your application but do not want your default domain name for your application publicly exposed, then each application must listen on HTTP port 8091 or 8092. Alternatively, you can create a custom mapping policy to redirect outside requests from your load balancer to your specific application. The following graphic shows how a load balancer interacts between a VPC and Anypoint Platform. ![Load Balancer](/mulesoft/current/en-us/gov-cloud/_images/pxty-lb.png) Your load balancer listens for outside requests over HTTPS and, by default, communicates internally with your worker over HTTP. If you configured your Mule application within Anypoint VPC to listen on HTTPS, you must set `upstreamProtocol` to HTTPS when creating the mapping list using the `load-balancer mappings add` command. The internal HTTP mode enables you to configure how HTTP requests are managed. They are silently ignored, mapped to HTTPS on the default SSL endpoint, or the URL is mapped directly to the corresponding HTTPS URL. ## Dedicated Load Balancer URL Encoding You can configure the Dedicated Load Balancer to pass request URIs unchanged or decoded: - If you select **Keep URL encoding**, the DLB passes only the %20 and %23 characters as is. - If you deselect **Keep URL encoding**, the DLB decodes the encoded part of the request URI before passing it to the MuleSoft Government Cloud worker. ## See Also - [Virtual Private Cloud](https://docs.mulesoft.com/cloudhub/virtual-private-cloud) - [Mapping Rules](https://docs.mulesoft.com/cloudhub/lb-mapping-rules) --- product: MuleSoft Government Cloud keywords: fips, certifications, security, fips-140-3, government cloud --- # FIPS 140-3 Compliance Support in Government Cloud > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Configure Mule runtime engine (Mule) to run in a Federal Information Processing Standard (FIPS) 140-3 certified environment in MuleSoft Government Cloud. Mule doesn’t run in FIPS security mode by default. To enable it, you must: - Install a certified cryptography module in your Java environment. - Adjust Mule runtime settings to run in FIPS security mode. Follow the migration path that matches your scenario: - [Migrating Mule from FIPS 140-2 to FIPS 140-3](#migrate-fips1402-to-fips1403) - [Migrating Mule from Non-FIPS to FIPS 140-3](#migrate-non-fips-to-fips1403) ## Compatibility FIPS 140-3 support in MuleSoft Government Cloud requires: - Mule runtime engine 4.9 (Government Cloud supported version) - Java 17 or later - FIPS license from the license `.zip` file provided by MuleSoft (the non-FIPS license isn’t valid for FIPS mode) ## Assumptions This document assumes you are familiar with [FIPS 140-3](https://csrc.nist.gov/publications/detail/fips/140/3/final), the US government security standard that requires compliant parties to use only cryptographic algorithms and techniques certified by NIST. These instructions use Bouncy Castle 2.0.0, the recommended FIPS 140-3 certified security provider for Mule runtime. If you use a different [certified security provider](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules), refer to that provider’s documentation for configuration instructions. ## Migrating from FIPS 140-2 to FIPS 140-3 If you are currently running Mule in FIPS 140-2 mode and want to move to FIPS 140-3, apply these cipher and configuration changes. ### Cipher and Protocol Changes - TLS and cipher suites: FIPS 140-3 requires support for TLS 1.3 and TLS 1.2. Earlier TLS versions aren’t supported. Use only the FIPS 140-3 compliant cipher suites listed in the [FIPS 140-3 Compliant Cipher Suites](#fips-140-3-compliant-cipher-suites) section. Remove or replace any custom TLS or cipher configuration that references FIPS 140-2-only or non–FIPS 140-3 cipher suites. - Configuration file: FIPS 140-3 uses the `$MULE_HOME/conf/tls-fips140-3.conf` file for TLS cipher configuration. Ensure your runtime uses this file and that you have removed or replaced references to any FIPS 140-2 TLS configuration file. ### Security Provider and Java Configuration - Bouncy Castle version: Replace the FIPS 140-2 Bouncy Castle provider (typically 1.x FIPS) with Bouncy Castle 2.0.0 FIPS. Install the JARs listed in [Installing Bouncy Castle Security Provider](#set_up_environment) and update `java.security` to use `BouncyCastleFipsProvider` and `BouncyCastleJsseProvider` as shown there. - `KeyManagerFactory` and `TrustManagerFactory`: In `$JAVA_HOME/conf/security/java.security`, set: ssl.KeyManagerFactory.algorithm=PKIX ssl.TrustManagerFactory.algorithm=PKIX ### Runtime Configuration (wrapper.conf) - Security model: Change the Mule security model from FIPS 140-2 to FIPS 140-3: \# Enable FIPS 140-3 security mode (replace fips140-2) wrapper.java.additional.=-Dmule.security.model=fips140-3 - Approved-only mode: Add or ensure: wrapper.java.additional.=-Dorg.bouncycastle.fips.approved\_only=true - Java 17+ module access: Add: wrapper.java.additional.=--add-opens=java.base/sun.security.provider=org.bouncycastle.fips.core ### Keystore Format - BCFKS: FIPS 140-3 requires keystores and truststores in `BCFKS` format. If you are still using `PKCS12` or `JKS` from your FIPS 140-2 setup, convert them to `BCFKS` using the steps in [FIPS 140-3 Compliant Keystore Formats](#fips-140-3-compliant-keystore-formats). Update all TLS contexts in your Mule apps to reference the new keystores and set `type="bcfks"`. ### Connectors and Post-Migration - Use only connectors tagged as `fips-140-3-verified` in Anypoint Exchange. Replace or remove connectors that are only verified for FIPS 140-2. - Restart Mule after all changes and confirm in startup logs that FIPS 140-3 security mode is enabled. ## Migrating from Non-FIPS to FIPS 140-3 If you are running Mule in standard (non-FIPS) mode and need to move directly to FIPS 140-3, complete these steps. ### Prerequisites - Mule runtime engine 4.9 - Java 17 or later - A FIPS license from the license `.zip` file provided by MuleSoft. ### Steps 1. Install the FIPS 140-3 certified cryptography provider: Follow [Installing Bouncy Castle Security Provider](#set_up_environment) to install Bouncy Castle 2.0.0 FIPS and configure `java.security` (providers and `ssl.KeyManagerFactory.algorithm` / `ssl.TrustManagerFactory.algorithm`). 2. Configure Mule for FIPS 140-3 mode: In `$MULE_HOME/conf/wrapper.conf`, add the properties described in [Running Mule in FIPS Security Mode](#running-mule-in-fips-security-mode) (`mule.security.model=fips140-3`, `org.bouncycastle.fips.approved_only=true`, and the `--add-opens` option). For Mule 4.9, set the keystore type explicitly: wrapper.java.additional.=-Dmule.keystore.type=BCFKS 3. Convert keystores and truststores to BCFKS: Standard Mule setups often use `PKCS12` or `JKS`. Convert all keystores and truststores used by your applications to `BCFKS` using the procedure in [FIPS 140-3 Compliant Keystore Formats](#fips-140-3-compliant-keystore-formats). 4. Update TLS configuration in Mule apps: In your Mule configuration files, update every `tls:context` to use the new BCFKS keystores and truststores with `type="bcfks"` as shown in [FIPS 140-3 Compliant Keystore Formats](#fips-140-3-compliant-keystore-formats). 5. Remove non-compliant cipher and protocol usage: Don’t configure custom cipher suites or TLS versions that aren’t FIPS 140-3 compliant. Rely on the default FIPS 140-3 cipher suites (see [FIPS 140-3 Compliant Cipher Suites](#fips-140-3-compliant-cipher-suites)) and ensure no connectors or custom code force non-approved algorithms. 6. Verify connector compliance: Only use connectors tagged as `fips-140-3-verified` in Anypoint Exchange. Replace or remove any connector that isn’t FIPS 140-3 verified (see [Connectors Compatibility](#connectors-compatibility)). 7. Restart Mule and validate: Save all changes, restart Mule, and confirm in startup logs that FIPS 140-3 security mode is enabled. Test connectivity and integrations that use TLS and cryptography. ## Installing Bouncy Castle Security Provider Mule runtime uses Bouncy Castle 2.0.0 as its FIPS 140-3 certified cryptography provider. ### Installation Steps These instructions show how to install and configure the Bouncy Castle security provider with Java 17 or later. 1. Verify that you are using Java 17 or later and `JAVA_HOME` is set. 2. Download the Bouncy Castle 2.0.0 provider files from [the Bouncy Castle website](https://www.bouncycastle.org/fips-java/). 3. Copy the required JAR files to the `$MULE_HOME/lib/boot` folder: bc-fips-2.0.0.jar bctls-fips-2.0.19.jar bcpkix-fips-2.0.7.jar bcutil-fips-2.0.3.jar bcpg-fips-2.0.9.jar bcjmail-fips-2.0.5.jar 4. Configure the security providers in the `$JAVA_HOME/conf/security/java.security` file: security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider security.provider.2=org.bouncycastle.jsse.provider.BouncyCastleJsseProvider fips:BCFIPS security.provider.3=SUN 5. Configure the key manager and trust manager algorithms in the same `java.security` file: ssl.KeyManagerFactory.algorithm=PKIX ssl.TrustManagerFactory.algorithm=PKIX ## Running Mule in FIPS Security Mode After installing the Bouncy Castle provider, configure Mule to run in FIPS 140-3 mode: 1. Open your `wrapper.conf` file (located in `$MULE_HOME/conf`). 2. Add these properties. Replace `` with the next sequential number in your file: \# Enable FIPS 140-3 security mode wrapper.java.additional.=-Dmule.security.model=fips140-3 # Enable Bouncy Castle approved-only mode wrapper.java.additional.=-Dorg.bouncycastle.fips.approved\_only=true # Required for Java 17+ module access wrapper.java.additional.=--add-opens=java.base/sun.security.provider=org.bouncycastle.fips.core # For Mule 4.9: set keystore type to BCFKS wrapper.java.additional.=-Dmule.keystore.type=BCFKS 3. If you are using a clustered environment, also add the cluster encryption key: wrapper.java.additional.=-Dmule.cluster.network.encryption.key={your-encryption-key} 4. Save your changes and start Mule runtime. When Mule launches, the startup logs show that FIPS 140-3 security mode is enabled. Mule automatically restricts protocol negotiations to use only approved cryptographic cipher suites. > [!IMPORTANT] Not all connectors are FIPS 140-3 compliant. Only connectors tagged as > `fips-140-3-verified` in Anypoint Exchange are certified for use in FIPS 140-3 environments. > Always verify compliance in Exchange before deploying. ## FIPS 140-3 Compliant Cipher Suites These cipher suites are enabled by default when running Mule in FIPS 140-3 mode. Use these when planning or validating migrations from FIPS 140-2 or non-FIPS runtimes. ### TLS 1.3 Cipher Suites - TLS\_AES\_128\_GCM\_SHA256 - TLS\_AES\_256\_GCM\_SHA384 - TLS\_AES\_128\_CCM\_SHA256 - TLS\_AES\_128\_CCM\_8\_SHA256 ### TLS 1.2 Cipher Suites - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_DHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384 - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA384 - TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_128\_CBC\_SHA - TLS\_ECDHE\_ECDSA\_WITH\_AES\_256\_CBC\_SHA - TLS\_ECDHE\_RSA\_WITH\_AES\_256\_CBC\_SHA > [!NOTE] These cipher suites are configured in the `$MULE_HOME/conf/tls-fips140-3.conf` file. FIPS > 140-3 requires support for TLS 1.3 and TLS 1.2. Earlier TLS versions aren’t supported. ## FIPS 140-3 Compliant Keystore Formats Keystores or truststores in Mule apps are often formatted as `PKCS12` or `JKS`. These formats aren’t FIPS compliant. For compliance, convert them to `BCFKS` format: 1. Download the `bc-fips-2.0.0.jar` file from the [Bouncy Castle website](https://www.bouncycastle.org/download/bouncy-castle-java-fips/). 2. Use this example command to convert a keystore to `BCFKS` format: BC\_FIPS\_JAR=${BC\_PATH}/bc-fips-2.0.0.jar # Replace with a correct path OLD\_KEYSTORE="keystore.jks" # Replace with the keystore to convert OLD\_PASSWD="changeit" # Replace with the keystore password NEW\_KEYSTORE="keystore.bcfks" # Replace with the new keystore NEW\_PASSWD="changeit" # Replace with the new keystore password keytool -importkeystore \\ -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider \\ -providerpath ${BC\_FIPS\_JAR} \\ -srckeystore ${OLD\_KEYSTORE} -srcstoretype JKS -srcstorepass ${OLD\_PASSWD} \\ -destkeystore ${NEW\_KEYSTORE} -deststoretype BCFKS -deststorepass ${NEW\_PASSWD} > [!NOTE] If the source keystore is `PKCS12`, set `-srcstoretype` to `PKCS12` in the `keytool` > command. 4. Update the TLS configuration in your Mule configuration file to use the new keystore or truststore: ## Connectors Compatibility Only connectors tagged as `fips-140-3-verified` in Anypoint Exchange are certified for use in FIPS 140-3 environments. To check compliance in Exchange before deploying: 1. Open Anypoint Exchange. 2. Search for the connector. 3. Check for the `fips-140-3-verified` tag. ## Tips and Limitations - Not all encryption schemes and signatures are FIPS 140-3 compliant. If your app uses a non-approved algorithm, you might see a runtime error such as: Could not find encryption algorithm ''. You are running in FIPS mode, so please verify that the algorithm is compliant with FIPS. - Different environments can have different security configurations. Test before deploying to production. ## See Also - [Security in MuleSoft Government Cloud](https://docs.mulesoft.com/gov-cloud/gov-cloud-security) - [Government Cloud Overview](https://docs.mulesoft.com/gov-cloud/) --- product: MuleSoft Government Cloud --- # Government Cloud Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft Government Cloud is a secure, Federal Risk and Authorization Management Program (FedRAMP)-moderate certified deployment environment that enables government agencies to use Anypoint Platform in the cloud. Your agency might already use Anypoint Platform on-premises to build applications. With Government Cloud, you can leverage the integration platform as a service (iPaaS) to reduce the infrastructure and management costs associated with legacy on-premises integration. With MuleSoft managing the Anypoint Platform infrastructure, your IT teams can focus on designing integrations. You can manage and monitor all government integration assets from a single secure, cloud-based management console. > [!IMPORTANT] MuleSoft Government Cloud deployment permits deployment of Mule runtime engine > instances into an on-premises environment (standalone Mule instances). Standalone Mule instances, > and MuleSoft support for standalone Mules, are outside the scope of FedRAMP. The customer is > responsible for ensuring that all data shared with Salesforce complies with any and all data and > information protection policies, requirements, and standards. Review the MuleSoft System Security > Plan for FedRAMP scope. ## Features Included in Government Cloud MuleSoft Government Cloud includes the full functionality of the Anypoint Platform runtime plane (services and Mule runtime engine) and a subset of the Anypoint Platform control plane (browser-based management of APIs and Mule runtime engine instances) functionality. Government Cloud supports the full API-led connectivity methodology and end-to-end API lifecycle management.
CategoryFeatureDescriptionNotes

Platform and Runtime

Mule Runtime Engine

Supports Mule runtime engine versions 4.3, 4.4, 4.6, and 4.9 on the long-term support (LTS) release channel. The Edge release channel is not supported, as it is not FedRAMP-approved. For more information, visit Edge and LTS Releases for Mule.

Self-signed certificates are not supported. Required Mule agent versions:

  • Mule 4: v2.2.0 and later

  • Mule 4.6

Mule runtime 4.3 has entered External Support.

Government Cloud also supports deploying standalone Mule runtime engine instances on-premises. For more information, see Standalone Mule Support.

Java

Supports Java 17. For more information on Java support, see Java Support.

N/A

Anypoint Studio

Use Anypoint Studio offline to build applications and then manually deploy them to Government Cloud.

Anypoint Studio is not part of Government Cloud.

Designing API Specifications

API Designer

Use the API Designer web UI to design API specifications in:

  • RESTful API Modeling Language (RAML) version 0.8 or 1.0

  • OpenAPI Specification (OAS) version 2.0 or 3.0

N/A

Visual API Designer

Use API Designer’s visual API editor to scaffold API specifications in RAML 1.0 or in OAS 2.0 or 3.0 (JSON).

N/A

API Console

As you add descriptions in your specifications and fragments, you can view them in auto-generated, interactive documentation in the text editor.

N/A

Sharing and Discovering APIs

API Developer Portals

Publish assets in private Exchange instances and Exchange public portals.

N/A

API Simulation (Mocking Service)

Simulate data for testing OAS or RAML REST APIs.

N/A

API Notebooks

Create API Notebooks to describe each function in your API and provide a test area so that users can experiment with sending different values to your API and receiving output.

N/A

Building and Testing APIs

APIkit

Use APIkit to build Mule REST or SOAP APIs in one of the following modeling languages:

  • RESTful API Modeling Language (RAML) 1.0 and 0.8 versions

  • Web Service Description Language (WSDL)

N/A

MUnit

Use this testing framework to build automated tests for your integrations and APIs.

N/A

Managing API Communities

Brand and Customize Your API Community

Customize and adjust the exact details of branding, look and feel, and the site structure of your Salesforce Experience Cloud site, using a simple point-and-click approach.

N/A

Publish APIs

Add and publish APIs, API groups, and minor and major updates from Anypoint Exchange into your Salesforce Experience Cloud site.

N/A

Publish Content and CMS Articles

Create, organize, and publish content for your community, including news, tutorials, developer blog posts, and events.

N/A

Moderate Forums

Use the Anypoint API Community Manager forums to ask questions and collaborate with other members of the community.

N/A

Manage Client Applications and Contracts

Enable your consumer developers to request access to APIs and API Groups in your community and to manage their client applications and contracts.

N/A

Managing Anypoint Platform

Anypoint Access Management

Create Anypoint Platform accounts, configure external identity, and configure access and permissions.

You can’t configure Microsoft Entra ID (formerly Azure AD) as a client provider in MuleSoft Government Cloud.

The Salesforce menu option in Access Management is not available in Government Cloud.

Anypoint MQ

Send messages between different applications or components within an application.

You can’t access or configure some Anypoint MQ features, such as client apps and unencrypted queues. For information, see Anypoint MQ in MuleSoft Government Cloud.

Object Store

Share data and state across Mule runtime workers within a single application.

N/A

API Manager

Manage, govern, and secure the APIs you deploy to Anypoint Platform.

N/A

Runtime Manager

Deploy, manage, and monitor your Mule applications in a sandbox, staging, or production environment from one central location, whether your apps are deployed in the cloud or on-premises.

N/A

CloudHub

Deploy sophisticated cross-cloud integration applications in the cloud, create new APIs on top of existing data sources, integrate on-premises applications with cloud services, and much more.

N/A

Anypoint Monitoring

Aggregate and map metrics across systems, and configure dashboards and alerts.

N/A

Anypoint Visualizer

Explore your application network for architectural review, troubleshooting, and policy compliance.

N/A

AI and Agent Connectivity

A2A Connector

Use the Agent-to-Agent (A2A) Connector to integrate with the A2A protocol, enabling communication between AI agents across platforms and frameworks.

N/A

Agentforce Connector

Integrate with AI agents running in Salesforce’s Agentforce platform to orchestrate experiences for customers, partners, and employees.

N/A

Einstein AI Connector

Connect to large language models (LLMs) via the Salesforce Einstein Trust Layer for AI-powered experiences, including embeddings generation for RAG-based architectures.

N/A

MCP Connector

Use the Model Context Protocol (MCP) Connector to integrate with the MCP protocol, enabling AI models to interact with external tools and data sources.

N/A

MuleSoft AI Chain Connector

Design, build, and manage AI agents with support for LLMs, vector stores, and advanced AI services including chat, RAG, sentiment analysis, and image generation.

N/A

MuleSoft Inference Connector

Access inference offerings for LLMs from multiple providers, enabling integration of AI capabilities such as chat, text generation, image analysis, and toxicity detection.

N/A

MuleSoft Vectors Connector

Access external vector stores and databases for semantic search and Retrieval Augmented Generation (RAG) use cases.

N/A

## Security and Compliance MuleSoft Government Cloud meets all FedRAMP security and compliance standards, including: - Federal Information Processing Standards (FIPS 140-3), for details refer to [FIPS 140-3 Compliance Support](https://docs.mulesoft.com/gov-cloud/gov-cloud-fips-140-3-support). - Transport Layer Security (TLS) 1.2 encryption - National Institute of Standards and Technology (NIST) 800-53 - Center for Internet Security (CIS) benchmarks Government Cloud provides a FedRAMP-compliant control plane hosted in the US GovCloud (West) region. For the full support matrix, see [Support Matrix for Control Plane Hosting Options](https://docs.mulesoft.com/hosting-home/#support-matrix-control-plane). For more information, see [Security in MuleSoft Government Cloud](https://docs.mulesoft.com/gov-cloud/gov-cloud-security). ## Products Not Currently Supported These Anypoint Platform products aren’t currently supported in Government Cloud:
ProductDescription

Anypoint Analytics

API analytics and dashboards for monitoring API performance and usage.

Anypoint Code Builder

Cloud-based IDE for designing, building, and deploying integrations and APIs.

API Data Gateway

Connect Salesforce reports and dashboards to external data sources.

API Governance

Automated API conformance and governance validation.

Anypoint Omni Gateway

Lightweight, high-performance API gateway deployable across any environment.

Anypoint Runtime Fabric

Container-based runtime deployment and management on your infrastructure.

Anypoint Security

Edge security policies including tokenization and encryption.

## See Also - [Security in MuleSoft Government Cloud](https://docs.mulesoft.com/gov-cloud/gov-cloud-security) - [Secure Configuration for FedRAMP](https://docs.mulesoft.com/gov-cloud/gov-cloud-secure-configuration-fedramp) - [Set Up Your Government Cloud Account](https://docs.mulesoft.com/gov-cloud/gov-cloud-account-setup) - [Dedicated Load Balancer](https://docs.mulesoft.com/gov-cloud/gov-cloud-load-balancer) - [Anypoint VPN Configuration](https://docs.mulesoft.com/gov-cloud/gov-cloud-anypoint-vpn) - [Standalone Mule Support](https://docs.mulesoft.com/gov-cloud/gov-cloud-standalone) --- product: MuleSoft Government Cloud --- # MuleSoft Government Cloud Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt These release notes describe updates to MuleSoft Government Cloud as from January 10, 2024. ## June 19, 2026 ### What’s New - MuleSoft Government Cloud now supports FIPS 140-3 compliance for Mule runtime engine 4.9. FIPS 140-3 replaces FIPS 140-2 as the supported cryptographic standard in Government Cloud. This update introduces support for Bouncy Castle 2.0.0 as the certified security provider, requires Java 17 or later, and mandates BCFKS keystore format and TLS 1.2 or TLS 1.3. For migration steps and configuration details, see [FIPS 140-3 Compliance Support](https://docs.mulesoft.com/gov-cloud/gov-cloud-fips-140-3-support). ## April 8, 2025 ### What’s New - MuleSoft Government Cloud now supports Mule runtime engine version 4.9.3. ## May 8, 2024 ### What’s New - MuleSoft Government Cloud now supports Java 17. For more information, visit [Java Support](https://docs.mulesoft.com/general/java-support). ## March 12, 2024 ### What’s New - MuleSoft Government Cloud now supports Mule runtime engine version 4.6. The March CloudHub 1.0 release introduces patches for Runtime versions 4.3.0 and 4.4.0 and Runtime 4.6. This update is a breaking change as it enforces compliance with FIPS 140-2 on runtime versions 4.6, 4.4, and 4.3 for CloudHub applications within the MuleSoft Government Cloud. For more details about the impact of this update, check this article: - [GovCloud - March 2024 - Updates on FIPS Enforcement.](https://help.salesforce.com/s/articleView?id=001186489&type=1) ## January 10, 2024 ### What’s New - Trusted domains allowlisting is now available in MuleSoft Government Cloud. For more information, visit [Allowing Trusted Domains for API Platform Proxies](https://docs.mulesoft.com/gov-cloud/gov-cloud-security#allowing-trusted-domains-for-api-platform-proxies). ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: MuleSoft Government Cloud --- # Secure Configuration for FedRAMP (Rev 5) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Federal Risk and Authorization Management Program (FedRAMP) Revision 5 introduces 10 Recommended Secure Configuration (FRR-RSC) requirements that cloud service providers address to help federal agencies secure their cloud environments. MuleSoft Government Cloud aligns with these requirements and provides FedRAMP-specific documentation guidance for MuleSoft services, as well as access to Open Security Controls Assessment Language (OSCAL) formatted documents for consumption into your own tooling. - Coverage: All Administrative guidance requirements - Requirements: All 10 FRR-RSC controls This table lists each FRR-RSC control, how it applies to MuleSoft Government Cloud, and your responsibilities where applicable. In the platform-as-a-service (PaaS) model, MuleSoft is the provider platform; and you administer your organizations, users, roles, and applications. ## FRR-RSC Controls
ControlRequirementDescriptionMuleSoft Solution

SCG-CSO-RSC (FRR-RSC-01)

Top-Level Administrative Accounts Guidance

Providers must create and maintain guidance that includes instructions on how to securely access, configure, operate, and decommission top-level administrative accounts that control enterprise access to the entire cloud service offering.

Note: This guidance should explain how top-level administrative accounts are named and referred to in the cloud service offering.

Applicable

MuleSoft fulfills this requirement in this PaaS model. MuleSoft documents how to create accounts, manage access, and use organization-level admin—including the "Organization Administrator" permission, "organization owner," and "Organization Administrators" roles, as well as access (sign-in, single sign-on (SSO), multi-factor authentication (MFA)), configuration (users, business groups, roles), operation (managing users, roles, permissions), and decommissioning (deleting accounts, migrating owners). The documentation explicitly names the "Organization Administrators" and "organization owner" roles and "Organization Administrator" permission.

For details, refer to:

SCG-CSO-RSC (FRR-RSC-02)

Administrative Security Settings

Providers must create and maintain guidance that explains security-related settings that can be operated only by top-level administrative accounts and their security implications.

Applicable

MuleSoft documents security-relevant settings that only top-level (organization) administrators can change. MuleSoft documentation covers security-related actions that require the Organization Administrators (or equivalent) role—for example, trusted domains (Gov Cloud security), user and role management, MFA and identity provider (IdP) configuration, client applications, virtual private cloud (VPC) and load balancer permissions, and organization details. The security and Access Management documentation describes these implications (for example, trusted domains, MFA).

For details, refer to:

SCG-CSO-RSC (FRR-RSC-03)

Privileged Accounts Security

Providers should create and maintain guidance that explains security-related settings that can be operated only by privileged accounts and their security implications.

Applicable

MuleSoft documents privileged (non–top-level) roles and their security-relevant capabilities. MuleSoft documentation lists default roles (for example, API Versions Owner, CloudHub Admin, Exchange Administrators, Audit Log Viewers) and their permission scopes, and explains custom roles. MuleSoft documentation describes security implications so you can understand what each role can do and how to manage privileged-account settings.

For details, refer to:

SCG-CSO-SDF (FRR-RSC-04)

Secure Defaults on Provisioning

Providers should set all settings to their recommended secure defaults for top-level administrative accounts and privileged accounts when initially provisioned.

Applicable

MuleSoft sets platform-level secure defaults (for example, Government Cloud requirement for two-factor authentication (2FA) for all users, password rules, documented Federal Information Processing Standards (FIPS), Transport Layer Security (TLS), and secure hosting). MuleSoft creates default roles automatically when you create an organization or business group. You provision organizations and users, assign roles, and enable MFA or IdP per your policy. You can align admin and privileged accounts with recommended secure defaults by following MuleSoft guidance when provisioning.

For details, refer to:

SCG-ENH-CMP (FRR-RSC-05)

Comparison Capability

Providers should offer the capability to compare all current settings for top-level administrative accounts and privileged accounts to the recommended secure defaults.

Applicable

MuleSoft doesn’t provide a built-in capability to compare current settings to recommended secure defaults for admin or privileged accounts in this PaaS model. You can view current roles and permissions in the UI and via the Access Management API. You are responsible for fulfilling the intent (for example, comparing to internal baselines) using exported data or internal processes.

CSG-ENH-EXP (FRR-RSC-06)

Export Capability

Providers should offer the capability to export all security settings in a machine-readable format.

Applicable

MuleSoft provides programmatic access to some security-relevant data via the Access Management API (organizations, business groups, users, roles, permissions) and API Manager (export of API instances). MuleSoft doesn’t offer a single machine-readable export of all security settings (identity and access management (IAM), policies, audit config, and so on) in one format. You can use the APIs to export or script identity and access security settings and to build your own export.

For details, refer to:

SCG-ENH-API (FRR-RSC-07)

API Capability

Providers should offer the capability to view and adjust security settings via an API or similar capability.

Applicable

MuleSoft supports viewing and adjusting security-relevant settings via API. MuleSoft provides the Access Management API for programmatic access to user and client management, organizations, business groups, roles, and permissions. MuleSoft provides API Manager and related APIs for API and configuration management. The platform satisfies this requirement for the access and API-management settings it exposes.

For details, refer to:

SCG-RSC-MRG (FRR-RSC-08)

Machine-Readable Guidance

Providers should provide recommended secure configuration guidance in a machine-readable format that can be used by customers or third-party tools to compare against current settings.

Applicable

MuleSoft doesn’t provide a machine-readable secure-configuration baseline (for example, Security Content Automation Protocol (SCAP), Open Vulnerability and Assessment Language (OVAL), or JSON schema) for admin or privileged account settings in this PaaS model. MuleSoft provides human-readable guidance in documentation. You can use the Access Management API response formats for your own tooling. You are responsible for fulfilling the intent (for example, comparing to internal baselines) using exported data or internal processes.

For details, refer to:

SCG-CSO-PUB (FRR-RSC-09)

Publish Guidance

Providers should make recommended secure configuration guidance available publicly.

Applicable
MuleSoft makes recommended secure-configuration and operational documentation guidance publicly available. MuleSoft publishes Government Cloud and security guidance publicly, including Government Cloud overview, security (FedRAMP, FIPS, TLS, National Institute of Standards and Technology (NIST), Center for Internet Security (CIS)), Access Management, roles, permissions, MFA, audit logging, and account lifecycle.

For details, refer to:

SCG-ENH-VRH (FRR-RSC-10)

Versioning and Release History

Providers should provide versioning and a release history for recommended secure default settings for top-level administrative accounts and privileged accounts as they are adjusted over time.

Applicable

MuleSoft provides product and documentation versioning. MuleSoft does not maintain a dedicated release history for recommended secure default settings for admin or privileged accounts.

For details, refer to MuleSoft Release Notes.

## See Also - [Security in MuleSoft Government Cloud](https://docs.mulesoft.com/gov-cloud/gov-cloud-security) - [Government Cloud Overview](https://docs.mulesoft.com/gov-cloud/) --- product: MuleSoft Government Cloud --- # Security in MuleSoft Government Cloud > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft Government Cloud meets the security requirements of FedRAMP (Federal Risk and Authorization Management Program) and other security protocols. ## FedRAMP Compliance MuleSoft Government Cloud meets all FedRAMP security and compliance standards. FedRAMP provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by the U.S. government. For additional information, refer to [MuleSoft Government Cloud FedRAMP Authorization](https://marketplace.fedramp.gov/#/product/mulesoft-government-cloud?sort=productName). Mule 4 connectors that are verified for FIPS compliance can be found in Anypoint Exchange at [Assets provided by MuleSoft](https://anypoint.mulesoft.com/exchange/?search=tag:%22fips-140-verified%22&type=connector&type=extension). The following modules are FIPS compliant: - [Compression](https://docs.mulesoft.com/compression-module/latest/) - [Crypto](https://docs.mulesoft.com/cryptography-module/latest/) - [Java](https://docs.mulesoft.com/java-module/latest/) - [JSON](https://docs.mulesoft.com/json-module/latest/) - [OAuth](https://docs.mulesoft.com/oauth-module/latest/oauth-module-reference) - [OAuth2 Provider](https://docs.mulesoft.com/oauth2-provider-module/latest/oauth2-provider-module-reference) - [Scripting](https://docs.mulesoft.com/scripting-module/latest/) - [Spring](https://docs.mulesoft.com/spring-module/latest/) - [Validation](https://docs.mulesoft.com/validation-connector/latest/) - [XML](https://docs.mulesoft.com/xml-module/latest/) A partial list of FIPS 140-2 compliant cipher suites supported by MuleSoft Government Cloud is provided in [FIPS 140-2 Compliance Support](https://docs.mulesoft.com/mule-runtime/latest/fips-140-2-compliance-support). A Third-Party Assessment Organization (3PAO) performs the security assessments following guidance in the National Institute of Standards and Technology (NIST) 800-37 publication. The security assessment validates management, operational, and technical security controls used to protect the confidentiality, integrity, and availability of MuleSoft Government Cloud and the data it stores, transmits, and processes. MuleSoft obtained the FedRAMP Agency Authority to Operate (ATO) at the **Moderate Impact Risk** level. ## Security Protocols In addition to FedRAMP compliance, MuleSoft Government Cloud adheres to these security protocols: - **Federal Information Processing Standards** (FIPS 140-2) Complies with hardware and software encryption standards for all data at rest (stored data). You must configure Mule runtime engine to run in FIPS-compliant mode. See [FIPS 140-2 Compliance Support](https://docs.mulesoft.com/mule-runtime/latest/fips-140-2-compliance-support). - **Transport Layer Security (TLS) 1.2 encryption** Implements encryption for all external and internal data transmission to block “man in the middle” attacks. - **NIST 800-53** Enhances physical and logical security. - **CIS benchmarks** Hardens instances to address the Center for Internet Security checklists. ## Secure Hosting Platform MuleSoft Government Cloud is hosted in Amazon Web Services (AWS) High Authorized GovCloud. AWS GovCloud: - Supports compliance with United States International Traffic in Arms Regulations (ITAR) - Has achieved Department of Defense (DoD) Provisional Authorization at IL (Impact Level) 2, 4, and 5 ## Cloud Security and Data MuleSoft Government Cloud provides a highly secure environment for government entities to perform sensitive data manipulations. Mule runtime engine transmits but does not inspect, permanently store, or otherwise interact directly with government data. Government agencies always maintain control over their data, configuration, and workers. ## Support and Maintenance MuleSoft supports MuleSoft Government Cloud with dedicated support personnel located in the United States. MuleSoft provides continuous monitoring services to protect confidentiality, integrity, and availability of government data managed in MuleSoft Government Cloud. The MuleSoft Compliance and Information Security teams: - Work directly with FedRAMP agencies to address all vulnerabilities as required by FedRAMP ATO standards. - Follow industry best practices for security, including password enforcement, multi-factor authentication (MFA), and user education. - Maintain security policies related to operations, data security, passwords and credentials, facilities and network security, and secure connectivity. - Perform internal security audits to ensure compliance with security policies. ## Allowing Trusted Domains for API Platform Proxies Every HTTP request you make to an external resource goes through the API Console Proxy. By default, proxy requests are blocked for external domains on authenticated requests. For security reasons, you must register the domain as an allowed domain in Anypoint Platform. To add a new domain: 1. Log in to Anypoint Platform using an account that has the Organization Administrator permission. 2. In the navigation bar, click **Access Management**. 3. Click **Trusted domains**. 4. Click **Add domain**. The domain must not match an existing domain, must not be a domain or subdomain of MuleSoft or Anypoint Platform, and must be written in the format `exampledomain.com`. > [!NOTE] Regular expressions are not supported. 5. Type the domain name and click **Add domain**. The domain is added to your list of trusted domains. You are redirected to the trusted domains page, where you can edit or delete your domains. If you register a domain on a parent organization, the domain is allowlisted for all of your business groups. ## See Also - [Features Included in MuleSoft Government Cloud](https://docs.mulesoft.com/gov-cloud/#features-included-in-government-cloud) - [AWS GovCloud](https://aws.amazon.com/govcloud-us/) - [FedRAMP](https://www.fedramp.gov/) --- product: MuleSoft Government Cloud --- # Set up Your Government Cloud Account > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you set up your account, Government Cloud works with your identity provider (IdP) to enable single sign-on (SSO) for users in your agency. Instead of using the Anypoint Platform sign-in page, your users sign in to the SSO system to access Anypoint Platform. When you purchase Government Cloud, your Customer Success Manager sends you onboarding instructions and access to the [Salesforce Help](https://help.salesforce.com). To configure your IdP to work with Government Cloud: 1. Verify that you have access to the Support Portal. If not, contact your Customer Success Manager for credentials. 2. In the Support Portal, click **Create New Case**. 3. Enter your Support Center credentials and click **Log in**. 4. Request to configure the connection to your external identity provider for your organization to enable SSO. 5. Provide the required information about your IdP and any additional information, if applicable. For the required information, see the documentation that applies to the SSO standard you use: - [OpenID Connect](https://docs.mulesoft.com/access-management/conf-openid-connect-task) - [SAML](https://docs.mulesoft.com/access-management/conf-saml-sso) Using the information you provide, MuleSoft Support configures the connection to your IdP to enable SSO for your organization. > [!IMPORTANT] Government Cloud does not support the configuration of local users, for which > usernames and encrypted passwords are stored outside of Government Cloud. --- product: MuleSoft Government Cloud --- # Standalone Mule Support in MuleSoft Government Cloud > For the full documentation index, see: https://docs.mulesoft.com/llms.txt MuleSoft Government Cloud deployment permits deployment of Mule runtime engine instances into an on-premises environment (standalone Mule instances). Standalone Mule instances, and MuleSoft support for standalone Mule instances, are outside the scope of FedRAMP. The customer is responsible for ensuring that all data shared with Salesforce complies with any and all data and information protection policies, requirements, and standards. Review the MuleSoft System Security Plan for FedRAMP scope. Rigorous internal security and compliance reviews were performed on services that support standalone Mule deployments in MuleSoft Government Cloud. The Significant Change Request Form and updated System Security Plan were approved by our FedRAMP sponsoring agency. For FIPS compliance, Mule Runtime version 4.1.x or later and runtime agent version 2.4.9 or later are required. Standalone Mule support enables federal, state, and local government customers to deploy Mules inside their private cloud or on-premises environment and manage them using the MuleSoft Government Cloud control plane. Key features include: - Mule Management - Unified view of applications, servers, and APIs - Application deployment and management across all environments - Integration with continuous deployment pipelines - [Anypoint Runtime Manager](https://docs.mulesoft.com/runtime-manager/) capabilities - Anypoint Runtime Manager monitoring - Dashboards for apps, servers, and server groups - Visibility into usage and performance metrics - Email alerts and notifications - Performance metrics for flows - [Ability to Monitor Applications and Servers](https://docs.mulesoft.com/runtime-manager/monitoring) ## Mule Version Support The following Mule versions are supported for standalone Mule support in MuleSoft Government Cloud: - 4.1.x - 4.2.x - 4.3.x - 4.6.x To get started, refer to the [Anypoint Runtime Manager](https://docs.mulesoft.com/runtime-manager/) documentation.