Boomi Security: Secure Runtimes, Roles, Tokens and Connection Credentials

A Boomi account holds the credentials for every system it integrates, so a single over-privileged user, token or runtime can reach a large part of the business. This guide explains how to secure the Boomi Enterprise Platform from the customer side: platform roles and privileges, account groups, SAML single sign-on and two-factor authentication, Platform API tokens, environments and environment extensions, connection credential storage, runtime (Atom, Molecule and runtime cloud) hardening and API Management authentication. It is for integration architects, platform owners and security teams; every setting named comes from Boomi's own documentation.

This is an independent guide from NHI Mgmt Group, based on Boomi's public documentation as of November 2026. It is not sponsored or reviewed by Boomi. Product features change, so confirm settings against Boomi's current documentation.

Key takeaways

• Integration platforms are credential vaults. Connection components, environment extensions and runtime properties hold passwords, keys and certificates for downstream systems, so access to Boomi is access to those systems.
• Build custom roles from privileges. Keep the Administrator role to a small named group, prefer User Management - Limited over User Management, and split build, deploy and runtime management across roles.
• Use environments as a security boundary. Restrict each production environment to named roles through Roles with Access, and keep production connection values in environment extensions rather than in components.
• Treat Platform API tokens as non-human identities. Each token is tied to a user, carries that user's privileges and is shown only once: give automation its own user, inventory tokens and revoke them when owners leave.
• Harden the runtime and keep secrets outside the platform. Run runtime clouds with the HIGH security policy, protect local runtime hosts like any server holding credentials, and use Boomi Secrets Management to reference AWS, Azure or Google Cloud secret stores.

How identity and access work in Boomi

Boomi separates the hosted platform (the web interface and Platform API, run from Boomi's data centres) from the runtimes that execute integration processes. Runtimes are Atoms (a single runtime), runtime clusters (formerly Molecules) and runtime clouds, and they can run on your own hosts or be hosted by Boomi. People and automation authenticate to the platform; runtimes authenticate to the platform with a certificate created at registration; and integration processes authenticate to target systems with the credentials stored in connection components and environment extensions.

Two factors shape the design. First, Boomi requires two-factor authentication on all accounts, and administrators can enforce it at account level so users must enrol before they sign in to or switch into that account. Users choose Email Verification or an Authenticator App (TOTP). Second, single sign-on is part of Advanced User Security, which Boomi includes in the Enterprise and Enterprise Plus editions and offers as an add-on for Professional and Professional Plus. Boomi supports identity provider and service provider initiated SAML 2.0 sign-in for Integration, Data Hub and API Management.

• Connect SSO to your identity provider: map each user's federation ID exactly (it is case sensitive) and drive joiner, mover and leaver changes from the identity provider group that grants Boomi access. See the SAML Security Guide.
• Prefer authenticator apps: Boomi's 2FA page describes Email Verification and Authenticator App methods; choose the app method for administrators, because email codes inherit the security of the mailbox. See the MFA Guide.
• Set session controls: under Settings, Security Options, administrators can turn on inactivity timeouts (session locks after 15 minutes and ends after 30), limit users to two concurrent sessions, and ask Boomi to enable a fixed four-hour session time-out.

Admin roles and privileged access

Boomi ships four default platform roles: Administrator, Standard User, Production Support and Support (the last two require Advanced User Security). The user who registers an account receives Administrator by default. Administrators can build custom roles by combining privileges, and environment and runtime privileges can be limited to specific environments. Only administrators can manage users, environments and support access, so the Administrator role is the main privileged identity in Boomi.

Separating duties

1. Clone Standard User into a developer role without Packaged Component Deployment for production environments.
2. Create a release role with Packaged Component Deployment and Environment Management for production only.
3. Create an operations role with Runtime Management No Extensions or Runtime Management Read Access so operators can restart runtimes without seeing credentials.
4. Keep View Data off every role that does not need payload access, because process data can include personal and payment information.

Account groups and support access

Partners and multi-account customers use account groups, managed from the Account Groups tab of a primary account, to grant users roles across many accounts. Boomi documents three access types: Direct Access through the User Management tab, Account Group Access through the group's user list, and SSO. When a user holds both Direct and Account Group access, the Direct Access role takes precedence at login, so review both paths. Boomi has replaced the older parent and child inheritance model with account groups.

For Boomi's own support teams, set the Support Access Role to No access on the Account Information panel and use Temporary Elevated Access Management: an administrator chooses the access role, sets an expiry date, and can extend or expire the access early. See the Third-Party Access Guide.

Integrations, API tokens and service accounts

Every Boomi deployment has two layers of non-human identity: the tokens that automate the platform, and the credentials that processes use to reach other systems. Both need owners, rotation and an inventory. See the Service Account Security Guide.

Platform API tokens

• How they work: a user with the API Access privilege creates tokens on the Platform API Tokens page under My User Settings. Each user can hold up to five tokens, names are unique, and the token value is shown once at creation.
• Whose rights they carry: a token is tied to the user who created it and acts with that user's privileges. Create a dedicated automation user per pipeline or system with a narrow custom role, rather than issuing tokens from an administrator's account.
• SSO and 2FA users: Boomi documents tokens as the way SSO users and 2FA users call the Platform and Partner APIs. For ad hoc calls, a TOTP code can be sent in the X-Boomi-OTP header instead.
• Lifecycle: users can revoke, disable, enable and rename their tokens, and account administrators can manage all tokens in the account. Review tokens quarterly and when a user changes role or leaves.
• Network restriction: turn on Trusted IP Addresses (Settings) to limit Platform and Partner API calls to listed addresses. The list holds up to 25 entries as single addresses, dash ranges or trailing wildcards; add runtime cloud addresses first so connector browsing keeps working.

Connection credentials and environment extensions

When a developer enters a connection password, Boomi encrypts it with the account's public X.509 key, generated when the account was activated. Environment extensions let you override connection settings, operation settings, trading partner settings, process properties, cross-reference tables, PGP certificates and data maps per environment at deployment time, so production credentials never sit in the component a developer builds.

To use secret references, the account needs the SECRETS_MANAGEMENT feature. Tick Use Secrets references under Environment extensions, then point each field at a secret. On local runtimes, set the advanced property for the relevant provider to true and configure that provider's default credential method on the host; runtime clouds need the properties set by the cloud owner. Boomi holds retrieved secrets in memory only, caches them for up to one hour, and provides the refreshSecretsManager API to clear the cache after a rotation. See the Secrets Management Guide.

Logging and detection

The Boomi audit log records platform activity, and the Platform API exposes it through the AuditLog object (POST /AuditLog/query and /AuditLog/queryMore, up to 100 results per page). Reading it requires the API privilege and View Audit Logs. Boomi keeps entries for 12 months and then purges them, so export to your SIEM if you need longer retention.

Boomi's AuditLog reference notes that failed sign-in attempts are not part of the audit log, so watch failed authentication at your identity provider when SSO is in use. Each entry carries source (API, UI, INTERNAL, MOBILE, UNKNOWN), userId and containerId, which lets you separate token-driven changes from interactive ones.

Metrics that show the controls work:

• Number of users with the Administrator role or Account Administration privilege (target: three or fewer per account).
• Percentage of Platform API tokens owned by dedicated automation users rather than people.
• Tokens older than your rotation period, and tokens owned by disabled users (target: zero).
• Percentage of production connections using environment extensions or secret references.
• Production deployments made outside the approved release role (target: zero).

Hardening baseline

Runtime security

Runtimes always open the connection to Boomi: outbound HTTPS on port 443 with TLS 1.2, authenticating the platform during the TLS handshake. No inbound firewall ports are needed for platform communication, and production data stays on a local runtime's network unless a process sends it elsewhere. That makes the runtime host the most sensitive asset in a self-hosted deployment, because it holds decrypted connection values while processes run.

• Security policy: Boomi applies the HIGH security policy by default to multi-tenant runtime clouds. HIGH denies access to local network resources and to file system locations outside the account directory. LOW applies no restrictions and is intended only where you control every tenant. Change the level under Runtime Management, Properties, Advanced, Security Policy, and add narrow exceptions through the Atom Security Policies object rather than dropping to LOW.
• Single-tenant clusters: forked processing is off by default, and without it processes run in the main runtime JVM with full permissions. Treat every process deployed to such a cluster as trusted code and restrict who can deploy to it.
• Host hardening: run the runtime under a dedicated non-administrative service account, restrict file permissions on the installation directory, patch the operating system and keep the runtime on Boomi's update schedule.
• Egress: allow outbound traffic only to Boomi and your integration targets.

Account and API baseline

API Management

For APIs published through the Boomi API Gateway, attach an authentication source to every deployment. Boomi's documentation recommends OAuth 2.0 with OpenID Connect, validated as JWT at the Gateway, for external consumers, client certificate (mutual TLS) authentication for system-to-system calls, and basic authentication for prototypes or internal APIs. Add the IP Filtering, Resource Filtering and Role-Based Access Control policies where relevant, and use plans with API keys to apply rate limits per application. Keyless plans should be reserved for APIs that are genuinely public. See the API Gateway Security Guide and the JWT Security Guide.

Phased rollout

The sequence below is NHI Mgmt Group guidance, not a vendor requirement; adjust it to your environment.

1. Inventory (week 1): export users, roles, tokens and environments through the Platform API; list connections and which use extensions or secret references.
2. Identity (weeks 2 to 3): enforce account-level 2FA, enable SSO where licensed, and test with a pilot group before enforcing for everyone. Keep one break-glass administrator with an authenticator app and a sealed recovery process.
3. Roles (weeks 3 to 5): build custom developer, release and operations roles, move users into them, and set Roles with Access on production environments. Keep the old role assignments documented for rollback.
4. Credentials (weeks 4 to 8): move production credentials into environment extensions, then into Secrets Management, one integration at a time, testing each in a test environment first.
5. Runtime and monitoring (weeks 6 to 10): confirm security policies, harden hosts, turn on Trusted IP Addresses, and ship audit logs to the SIEM with the alerts above.

Small and large organisations: a single account with one runtime can rely on custom roles, environment extensions and 2FA. Multi-account estates should add account groups, SSO, Secrets Management and central logging.

Common misconfigurations

• Everyone is an administrator: early adopters often keep the default Administrator role for every developer. Move them to custom roles and keep Administrator for platform owners.
• Tokens on personal accounts: pipelines that use a token from an engineer's account break or keep working inappropriately when that engineer leaves. Create dedicated automation users and record the owner of every token.
• Production credentials in components: passwords typed into connection components travel with every copy and deployment. Use environment extensions or secret references for production.
• LOW policy on shared runtimes: lowering a runtime cloud's security policy to reach an internal resource removes tenant isolation. Add a specific exception through the Atom Security Policies object instead.
• Standing vendor access: leaving the Support Access Role at a permissive level gives open-ended access. Use No access with time-bound temporary credentials.

Framework mapping

Practitioner checklist

• Account-level 2FA is enforced and administrators use the Authenticator App method.
• SAML SSO is enabled where licensed, with federation IDs driven from the identity provider.
• No more than three users hold Administrator or Account Administration in each account.
• Developer, release and operations roles are separate, and View Data is granted only where needed.
• Every production environment has Roles with Access set.
• Every Platform API token belongs to a dedicated automation user with a recorded owner, and tokens are reviewed quarterly.
• Trusted IP Addresses is on for Platform and Partner API access.
• Production credentials use environment extensions or Secrets Management references.
• Runtime clouds use the HIGH security policy, and local runtime hosts are hardened and patched.
• Audit logs are exported to the SIEM with alerts on role grants, token creation and out-of-window deployments.

Standards and references

• Boomi: User roles and privileges
• Boomi: Platform API Tokens
• Boomi: Two-factor authentication
• Boomi: Secrets Management Service
• Boomi: Runtime communication security
• Boomi: Security policies for runtime clouds and clusters
• Boomi: Platform API reference, AuditLog
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Secrets Management Guide · Service Account Security Guide · API Key Management Guide · Least Privilege Techniques Guide