Securing integrations: a practical guide

Integrations are where your systems trust each other. The e-shop writes orders into the ERP, the ERP pushes invoices to the tax platform, the CRM reads customer balances, the warehouse system receives picking lists. Each of those connections holds credentials, moves personal data and opens a path into a system that matters. In many audits, the integration layer turns out to be the weakest point: a shared admin password in a config file, a token that never expires, a log full of customer addresses.

This guide covers the building blocks of integration security, the mistakes we see most often, and how to compare the tools that help.

Systems have identities too

Most security thinking is about users: who logs in, with which password, with which second factor. Integrations are different. The caller is usually a system, running unattended at 3 a.m., and nobody is there to type a code.

That changes the questions you ask:

• Which system is calling? Not “which person”. The order-sync process, the BI extractor and the partner’s middleware are three different identities, even if the same consultant built them.
• On whose behalf? Sometimes a system acts for itself (sync all new orders). Sometimes it acts for a user (show this salesperson’s customers). The two need different authentication flows.
• What is it allowed to do? A process that reads stock levels should not be able to post journal entries.

Service accounts and least privilege

Give every integration its own service account in every target system, and give that account only the rights the integration needs.

Integration	Bad practice	Good practice
E-shop to ERP orders	ERP admin user	svc-eshop-orders: create sales orders, read items
BI nightly extract	DBA account	svc-bi-read: read-only on selected views
Partner order status	Shared partner login	One client per partner, read-only on their orders

Least privilege limits the damage when a credential leaks, and dedicated accounts make audit trails readable: when the ERP log says svc-eshop-orders changed customer C-1042, you know where to look.

OAuth 2.0 for system-to-system calls

Most SaaS APIs (CRMs, e-invoicing platforms, marketplaces, payment providers) now use OAuth 2.0. The specification defines several grant types, and picking the right one matters:

• Client credentials. The integration authenticates as itself with a client ID and secret (or a certificate) and gets a short-lived access token. This is the normal choice for unattended system-to-system integrations.
• Authorization code. A user signs in once and grants the integration access to their data. The integration then keeps a refresh token and renews access tokens without the user. Use it when the API only grants access on behalf of a user, or when the data really belongs to a user.
• JWT bearer / private key JWT. The client proves its identity with a signed assertion instead of a shared secret. Stronger than a secret, because the private key never leaves your side.
• Resource owner password. The integration sends a username and password to get a token. It is deprecated in current OAuth guidance; avoid it unless a legacy API leaves no other option.

Ask for the narrowest scopes the API offers, and remember that access tokens are short-lived on purpose. Your integration must handle expiry and renewal, not just the first call. We walk through both main flows in OAuth 2.0 connections in Boomi.

Certificates and mutual TLS

TLS certificates do two jobs in integrations:

1. Server certificates prove that you are talking to the real API and encrypt the traffic. Your integration must validate them, and must never be configured to “trust all certificates” outside a lab.
2. Client certificates (mutual TLS) prove who the caller is. They are common in B2B (AS2, banking, tax authorities) and between a gateway and its backends.

Certificates expire, usually after one or two years, and an expired certificate fails with no warning at the worst possible moment. Keep an inventory with expiry dates and owners, and alert well before the date.

Secrets management and rotation

A secret is anything that grants access: passwords, client secrets, API keys, private keys, connection strings. The rules are simple to state and easy to break:

• Never in source code, scripts or shared documents. Not in Git, not in a wiki page, not in an email to the partner.
• Different per environment. Test credentials must not work in production, and production credentials must not be known to the people who only build in test.
• Stored in one controlled place, with access logging: a secrets vault, or the encrypted credential store of your integration platform.
• Rotated, on a schedule and immediately when someone with access leaves. Rotation is only realistic if changing a secret is a configuration change, not a code change and a redeployment of twenty processes.

Encryption in transit and at rest

• In transit: TLS 1.2 or later for everything, including “internal” calls. Internal networks are where attackers move once they get in.
• At rest: integration platforms write documents to disk: queues, retry stores, execution history, temp files. Know where those are, how long they are kept, and whether they are encrypted.
• Message-level: for files that travel through intermediaries (SFTP drop-offs, EDI), consider PGP or similar encryption of the payload itself, so the file is protected even where the transport is not.

Logging without leaking

Good integration logs are essential for troubleshooting. Bad ones are a data breach waiting to happen. Common leaks:

• full request and response bodies with names, addresses, VAT numbers, IBANs,
• Authorization headers and tokens printed in debug mode,
• passwords in connection strings written to error messages.

Log identifiers and outcomes (order SO-58812 for customer C-1042 created in ERP, 412 ms), not payloads. If you must keep payloads for reprocessing, keep them in a protected store with a short retention period, not in the general log.

GDPR considerations

Integrations copy personal data between systems, so they fall squarely under GDPR:

• Data minimisation: map only the fields the target needs. If the warehouse needs a delivery address, it does not need the customer’s date of birth.
• Retention: execution history and archived documents count as processing. Set retention periods and make sure they are enforced.
• Processors and location: a cloud integration platform is a processor. Check where it stores and processes data, and that your data processing agreement covers it.
• Erasure requests: when a customer asks to be deleted, can you find their data in integration archives too?

Network controls

Authentication answers “who are you”. The network answers “can you even reach me”. Use both:

• IP allowlists on APIs and SFTP servers, limited to the addresses of your integration runtime or gateway.
• Private connectivity (VPN, private endpoints, peering) for traffic between your cloud runtime and on-premises systems, instead of exposing the ERP to the internet.
• Runtimes close to the data: an on-premises runtime that makes only outbound connections is often safer than opening inbound firewall ports.
• Backends reachable only through the gateway, as described in our API management guide.

Common mistakes

• One “integration” user with admin rights everywhere. Convenient on day one, impossible to audit or rotate later.
• Secrets copied into each process. Twenty processes, twenty places to change on rotation day, and someone always misses one.
• Disabled certificate validation left over from testing.
• Long-lived tokens or keys that never change, sometimes for years.
• Debug logging in production that captures full payloads and headers.
• Nobody owns certificate expiry, so the first warning is a failed nightly run.

How to compare tools

Questions to ask of your integration platform and your secrets tooling:

1. Where are credentials stored and how are they encrypted? Can people who build processes see production secrets?
2. Can credentials and certificates differ per environment without changing the integration itself?
3. Which OAuth 2.0 grant types are supported natively, including token refresh and certificate-based client authentication?
4. Does it integrate with your identity provider for user login, roles and single sign-on to the platform?
5. Can it read secrets from an external vault, if your policy requires one central vault?
6. What is logged, for how long and where, and can you mask sensitive fields?
7. What audit trail exists for who changed a connection, a certificate or a deployment?

Tools in this space

Integration security is a combination of tools: an identity provider, a secrets store and the integration platform’s own credential handling. These are the ones we come across most often, in alphabetical order.

• AWS Secrets Manager. Managed secrets store for AWS workloads, with built-in rotation for several AWS databases and fine-grained access through IAM. A natural fit when most of your runtime lives on AWS.
• Azure Key Vault. Stores secrets, keys and certificates for Azure workloads, with access through Microsoft Entra ID and support for certificate lifecycle with certain certificate authorities. The obvious choice for Microsoft-centred organisations.
• Boomi. In the Boomi integration platform, credentials live in connection components and are stored encrypted in the platform; certificates are separate Certificate components. Environment extensions let each environment (test, production) have its own credentials and certificates without changing the process, and the platform supports single sign-on and role-based access for its users. It fits best when your integrations already run on Boomi and you want credential handling and environment separation built into the same tool.
• HashiCorp Vault. A widely used, cloud-neutral secrets platform, available self-managed or as a managed service. Strong on dynamic secrets (short-lived database credentials generated on demand) and policy-based access, and popular in multi-cloud and Kubernetes environments.
• MuleSoft Anypoint. Uses secure configuration properties to encrypt sensitive values per environment in Mule applications, alongside Anypoint’s own role-based access and API policies. A good fit for teams already building on Anypoint.
• Okta and Microsoft Entra ID. The two identity providers we see most often. Both can act as the OAuth 2.0 authorization server that issues tokens for your APIs and as the single sign-on source for your integration platform’s users. Entra ID is the default in Microsoft 365 organisations; Okta is popular as a vendor-neutral choice.

Most organisations end up with an identity provider, one central vault for the secrets that live outside the integration platform, and the platform’s own encrypted store for connection credentials. What matters is that each secret has one home and one owner.

Where to go next

Two practical articles apply this guide in Boomi:

• OAuth 2.0 connections in Boomi: client credentials and authorization code on the HTTP Client connector, token refresh, scopes and common errors.
• Managing secrets and certificates across environments in Boomi: environment extensions, Certificate components, rotation and expiry tracking.