MuleSoft Anypoint Security Guide: Connected Apps and Roles

An integration platform holds the credentials for every system it connects, so one over-privileged connected app or a leaked environment client secret in MuleSoft Anypoint can open the databases, SaaS tenants and APIs behind it. Anypoint Platform is where Mule applications are designed, deployed and governed, and each deployment typically carries database passwords, OAuth client secrets, API keys and certificates for downstream systems. This guide explains how identity and access work in Anypoint (organisations, business groups, roles and connected apps), which credentials the platform itself issues, how to keep application secrets protected, what the audit log records, and a hardening baseline. It is for integration platform owners, MuleSoft architects and identity and security teams. Behaviour is taken from MuleSoft's official documentation; check your control plane and subscription, since some features differ by region and package.

Key takeaways

Connected apps replace service accounts. MuleSoft requires internal connected apps instead of service accounts for programmatic access. Use client credentials connected apps with only the scopes and business groups the job needs.
Client secrets do not expire by default. A connected app's clientSecret has no expiry unless you set one. Set an expiry, record an owner and rotate secrets whenever ownership transfers.
Restrict which apps users can authorise. The default authorisation policy is Unrestricted. Switch to Restricted so only allowlisted apps can act on users' behalf.
Environment client IDs are deployment keys. Each environment has a client ID and secret used to connect customer-hosted runtimes and gateways. Treat them as privileged secrets.
Downstream secrets need runtime protection. Use safely hidden properties or property protection in Runtime Manager and the Secure Configuration Properties module, and never commit plain credentials in application property files.

How identity and access work in MuleSoft Anypoint

Anypoint Platform is organised as a root organisation containing business groups (sub-organisations), each with environments such as Sandbox and Production. People sign in with Anypoint credentials or through an external identity provider (SAML 2.0 or OpenID Connect), and get access through roles (sets of permissions) and teams, both scoped to a business group. External applications get access through connected apps, which use OAuth 2.0 and OpenID Connect.

Identity type	How it authenticates	Lifetime and controls
User with Anypoint credentials	Username, password and MFA	MFA is enabled by default and cannot be turned off at organisation level; session timeout default 60 minutes (15 to 180); optional IP allowlist for these logins.
SSO user	SAML or OIDC from your IdP	MFA enforced by the IdP; IP allowlisting does not apply to SSO logins.
Connected app acting on behalf of a user	Authorization code, JWT bearer or password grant	Gets the intersection of its scopes and the user's access. Refresh tokens expire after 90 days and need `offline_access`; access tokens end with the user's session.
Connected app acting on its own behalf	Client credentials	Works only in the organisation where it was created, in the business groups you select. Secret has no expiry unless configured.
Legacy service account (user)	Username and password	Only certain service account types are MFA exempt; MuleSoft requires internal connected apps instead.
Environment and business group client credentials	Client ID and secret	Used to register customer-hosted Mule runtimes and API gateways; do not expire on their own.

Grant types to avoid

MuleSoft's documentation says the password grant is not recommended because it reveals user credentials to the app and precludes MFA. Use authorization code for interactive apps and client credentials for automation. See the SaaS API Token Security Guide for the general token model.

Admin roles and privileged access

Role or permission	What it controls	Risk view
Organization Administrator (root)	Users, roles, teams, identity providers, security settings, connected apps, business groups	Full control of the tenant, including MFA resets and connected app secrets. Keep to a few named, MFA protected accounts.
Organization Administrator (business group)	The same within one business group, including creating connected apps and choosing their scopes	Can mint credentials for that group.
CloudHub Admin (per environment)	All Runtime Manager functions in that environment, created automatically per environment	Can deploy code and change application properties in Production.
API Versions Owner, API Creators	API Manager policies and API versions	Can remove security policies from a live API.
Exchange Administrators	Exchange assets and portals	Can publish or alter shared assets and templates.
Audit Log Viewer, Audit Log Config Manager	Reading audit logs; setting retention	Retention changes affect evidence; keep config rights with security.

Use custom roles: roles are business group specific. Build custom roles per job (deployer for one environment, read only support) rather than handing out Organization Administrator. CloudHub Developer and CloudHub Support are deprecated.
Federate administrators: map IdP groups to teams so joiner, mover and leaver changes flow from your directory, and keep one or two break glass Anypoint credential accounts with MFA.
Watch MFA resets: an Organization Administrator can reset another user's MFA, which is a takeover path; alert on it.
Restrict logins by network: enable IP allowlisting for Anypoint credential logins where available (US and EU commercial clouds), remembering it does not cover SSO users.

Integrations, API tokens and service accounts

MuleSoft concentrates two layers of non-human identity: credentials that act on Anypoint (connected apps, environment client IDs, runtime registration) and credentials that Mule applications use to reach downstream systems. See the Non-Human Identity (NHI) Guide.

Credentials that act on the platform

CI/CD connected apps: pipelines deploying with the Mule Maven plugin or the Anypoint CLI should use a client credentials connected app scoped to the target business group and environments, with deploy scopes only. Store the secret in the CI secret store, set an expiry, and use one app per pipeline so you can revoke one without breaking others.
Ownership transfer: when the creator of a connected app is deleted, leaves the root organisation or loses admin rights, ownership moves to the root organisation owner. MuleSoft advises rotating the client secrets of all connected apps after such a transfer; secrets can also be reset through the Access Management API.
Allowlisting and scopes: under the Restricted policy, apps that later request new scopes must be re-approved before users can grant them. Internal apps are auto approved unless you disable that.
Runtime registration: customer-hosted runtimes are registered with Runtime Manager using the amc_setup command and environment level credentials. Limit who can see these values and re-register servers if they leak.

Downstream credentials inside Mule applications

Mechanism	Where it applies	Notes
Safely hidden application properties	CloudHub and hybrid deployments via Runtime Manager	Names visible, values not displayed or retrievable; declared in `secureProperties` in `mule-artifact.json`. MuleSoft notes that for hybrid deployments the values remain visible after redeployment, so check what your deployment target actually protects.
Property protection	CloudHub 2.0 Properties tab	Masked values are not viewable after being set and are encrypted in the Anypoint Security secrets manager.
Secure Configuration Properties module	Any deployment, inside the application	Encrypted property files (AES default, CBC mode, `useRandomIVs` option); the decryption key is supplied at runtime, so protect the key as the real secret.
External secrets manager	Any deployment	Fetch at runtime from a vault with a workload identity, which supports rotation without redeployment.

Integration platforms are attractive because one breach yields many tenants' credentials: in the Salesloft Drift breach attackers took the OAuth tokens an integration held for customers' Salesforce tenants and then mined the data for further keys. Scope downstream OAuth clients tightly, rotate them on any suspicion, and keep an inventory of which Mule application holds which credential. See the Secrets Management Guide.

Logging and detection

The Anypoint audit log records user and app actions with time, objects, action type and an optional payload, queryable in Access Management or through the Audit Log Query API by Organization Administrators and Audit Log Viewers. It is business group aware. Default retention is one year (six years for organisations created before 10 July 2023), configurable from 30 to 2,190 days. Audit logs can be exported with Telemetry Exporter on Anypoint Integration Advanced or Titanium; otherwise poll the API into your SIEM. Entries marked Anypoint Staff are actions by people outside your organisation, such as entitlement changes.

Event	Why it matters	ATT&CK
Connected app created, scopes changed, secret reset	New or broader machine credential	T1098.001 Additional Cloud Credentials
Role or team membership changes, new Organization Administrator	Privilege escalation	T1078 Valid Accounts
Identity provider, MFA exemption or MFA reset changes	Authentication bypass or takeover	Valid Accounts
Application property changes in Production, unexpected deployments	Credential theft or code change through the platform	T1528 Steal Application Access Token
API policy removed or changed in API Manager	Exposes a backend without authentication	Defence weakening
Downstream token use from unusual locations	Stolen integration tokens used outside the runtime	T1550.001 Application Access Token

The last row depends on the downstream system's logs, not Anypoint's, so feed SaaS and database sign-in logs for Mule service identities into the same detections. See the Detection Engineering for Non-Human Identities Guide.

Metrics

Connected app hygiene: percentage of connected apps with an owner, an expiring secret and scopes reviewed in the last quarter.
Service account retirement: remaining user based service accounts used for automation (target zero).
Admin footprint: number of root Organization Administrators and the share using SSO with IdP MFA.
Secret protection: percentage of Production applications whose credentials are hidden, protected or fetched from a vault.
Audit export: audit events reaching the SIEM within one hour, with alerts tested.
Rotation: median age of connected app and downstream integration secrets.

Hardening baseline

Inventory first: list business groups, environments, connected apps (owned and authorised), user based service accounts, MFA exemptions and Production applications with their downstream credentials.
Federate sign-in: configure SAML or OIDC, map IdP groups to teams, enforce MFA at the IdP, and keep break glass accounts on Anypoint credentials with MFA.
Set session and network controls: shorten the default session timeout if your policy requires (minimum 15 minutes), and enable IP allowlisting for credential logins where available.
Migrate service accounts: replace each user based automation account with a client credentials connected app scoped to one business group and the environments it needs; then remove the MFA exemption and the account.
Restrict connected apps: switch the authorisation policy to Restricted, review the allowlist and consider disabling auto approval of internal apps so every app is reviewed.
Expire and rotate secrets: set an expiry on connected app secrets, rotate after ownership transfers or staff changes, and rotate environment client secrets if exposed.
Protect application properties: mark sensitive properties hidden or protected, encrypt property files with the Secure Configuration Properties module using random IVs, and keep the key out of the repository.
Separate Production: give Production its own deployer identity and custom role; developers deploy to Sandbox only.
Export audit logs: set retention to meet your policy and send events to the SIEM via Telemetry Exporter or the Audit Log Query API.
Test and roll back: trial the Restricted policy and service account migration in a non-production business group, keep the old credential disabled rather than deleted for a short window, and roll back by re-enabling it if a pipeline fails.

Small and large estates

A small team with one business group can run a handful of connected apps with clear owners, SSO for people and hidden properties for downstream secrets. Large enterprises with many business groups should centralise connected app approval with the security team, use per environment custom roles, pull downstream secrets from an enterprise vault, and review audit events for every Production change.

Common misconfigurations

Service accounts with MFA exemptions: user accounts kept for automation and exempted from MFA, with passwords in pipeline variables.
Organization Administrator scopes on CI apps: a deploy pipeline's connected app holding admin scopes across all business groups, so one CI leak compromises the tenant.
Non-expiring secrets with departed owners: connected apps whose creator left, ownership silently moved to the root owner and the secret never rotated.
Unrestricted authorisation policy: any user can grant a third party app access to Anypoint on their behalf.
Plain credentials in property files: database and SaaS passwords committed in config.yaml or .properties files in Git, or visible in hybrid Runtime Manager properties.
Password grant connected apps: apps collecting Anypoint usernames and passwords, bypassing MFA.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1
Connected app and service account management	AC-2, IA-5	PR.AA-01	5.5, 5.6
Least privilege roles and scopes	AC-6	PR.AA-05	6.8
MFA and federated sign-in	IA-2	PR.AA-03	6.3, 6.5
Protection of application secrets	SC-28, IA-5	PR.DS-01	3.11
Audit logging and retention	AU-2, AU-11, AU-12	PR.PS-04	8.2, 8.10

Practitioner checklist

People sign in through SSO with IdP enforced MFA; break glass accounts are few and monitored.
No user based service accounts remain for automation, and no MFA exemptions are left without a reason.
Every connected app has an owner, minimal scopes, the right business groups and an expiring secret.
The connected app authorisation policy is Restricted with a reviewed allowlist.
Environment client IDs and secrets are known to few people and rotated if exposed.
Production applications keep downstream credentials hidden, protected or in a vault, never in Git.
Custom roles separate Production deployment from development.
Audit logs reach the SIEM with alerts on connected app, role, IdP and MFA changes.
Downstream OAuth clients used by Mule applications are inventoried and can be rotated quickly after a vendor or platform incident.

Standards and references

Related NHI Mgmt Group resources: SaaS API Token Security Guide · Salesforce Security Guide · Secrets Management Guide · Service Account Security Guide

MuleSoft Anypoint Security Guide: Connected Apps, Roles and Integration Secrets