Integration Security Best Practices

Security in enterprise integration estates is the discipline most consistently underfunded and most frequently exposed when something goes wrong. Most of the audits we participate in find the same patterns: credentials in configuration files, shared service accounts with too much access, certificates that expired three years ago and were silently replaced with skip-validation flags, audit trails that exist on paper but were never actually wired in.

This guide is a field perspective on the security practices that hold up under regulator scrutiny and the ones that fall apart on first inspection. It is not exhaustive; it is the subset we keep coming back to.

Treat integration credentials as production secrets

The most common finding in security audits of integration estates is that credentials live in configuration files. Sometimes encrypted, sometimes not. Sometimes in version control history, sometimes only in the deployment pipeline. The credentials authenticate the integration platform's own service accounts to the systems it integrates with — typically high-privilege accounts because integration needs broad access.

The remediation is not optional and not negotiable: every integration credential lives in a secrets manager (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, IBM Secrets Manager, or equivalent), is rotated on a schedule, is audited on access, and is never persisted in configuration that engineers can see. The integration platform retrieves the secret at runtime via a short-lived token.

The implementation discipline:

• Secrets are categorised by sensitivity and rotation cadence. Trading partner credentials might rotate every 90 days; database service accounts might rotate every 30 days; signing certificates rotate on a schedule that matches their validity period.
• Service accounts are scoped to the minimum operation set the integration needs. The integration platform's service account in a downstream system should not be a system administrator; it should have CRUD only on the specific tables or APIs the integration actually uses.
• Access to retrieve a secret is logged with sufficient detail to reconstruct who or what retrieved it and when. Operations engineers can read the log; nobody else can read the secrets directly.

This work is unglamorous and frequently deferred. The integration platforms we audit that fail this discipline are the ones that have credentials in source-controlled config files dating back four years.

OAuth 2.0 is the default; pick the right grant

For service-to-service API calls inside the enterprise estate, the default is OAuth 2.0 with the client credentials grant. This is well-documented and well-supported by every modern API gateway and identity provider. The tradecraft is in picking the right grant for each scenario:

• Client credentials — service-to-service calls. The integration platform authenticates to an authorisation server and receives a short-lived access token. Default for everything machine-to-machine.
• Authorisation code with PKCE — user-context calls where a human is initiating the request. The token represents the user, not the service. Used when the integration needs to act on behalf of a specific user.
• JWT bearer / assertion grants — federated scenarios where another identity provider has already authenticated the caller. Common in B2B integration where the partner has their own identity provider.

What is not the default and where we see misuse: long-lived bearer tokens stored in configuration. The whole point of OAuth's short-lived access tokens is that compromise has a bounded blast radius. Hard-coding a long-lived token in a config file recreates the password-in-config problem with extra steps.

mTLS where the network boundary matters

For trading partner connectivity, partner-to-cloud integration, and any cross-organisation traffic, mutual TLS (mTLS) is the right default. Both ends present a certificate; both ends verify the other. The trust relationship is explicit and certificate-based, not network-based.

mTLS done well requires:

• A certificate management process that is not manual. Certificates expire. The estates we audit that fail their next audit are the ones where expiry tracking lived in a spreadsheet that nobody owned.
• Certificate authority decisions made consciously. Public CA, private CA, or partner-provided CA — each has different trust implications and different operational consequences.
• A revocation strategy. CRLs, OCSP stapling, or short certificate lifetimes (the ACME / Let's Encrypt model) — pick one and operate it. "Revocation is hard" is not an answer.
• Monitoring for impending expiry, ideally with 60-day, 30-day, and 7-day alerts. The integrations that break in production because a certificate expired are nearly always integrations where the alerting was never wired up.

mTLS is operationally heavier than bearer tokens. For high-volume internal service-to-service traffic, the operational cost of mTLS may not be justified. For cross-organisation traffic, the alternative (trust boundaries enforced only at the network layer) does not hold up under scrutiny.

JWT signing, not just JWT carrying

JWT tokens are commonly used as bearer credentials. The pattern works if the validating party actually validates the signature. We have audited several estates where JWTs were accepted as bearer credentials without signature verification — the validating service trusted that any caller presenting a token with the right claims was authorised. This is a particularly hazardous pattern because it looks secure: tokens are present, claims are checked, audit records show "JWT-authenticated request." The actual security is no better than no authentication at all.

The discipline:

• Every JWT-validating endpoint validates the signature against the expected issuer's public key, not just the claims.
• The public keys are retrieved from a well-known endpoint (JWKS) and cached with appropriate TTL.
• Issuer, audience, and expiry are all validated.
• Tokens are short-lived (minutes to hours, not days).
• Algorithm allow-listing is enforced — no alg: none accepted, no automatic acceptance of HS256 when expecting RS256.

The "validate JWTs properly" checklist is well-published. Most of the estates that fail it do so not from ignorance but from the validating service having been written by a team that did not know JWT validation was their responsibility.

Audit trail is a first-class deliverable

Integration security audits ask for the same things: who accessed what, when, from where, with what authentication, with what outcome. The estates that pass this audit fluently are the ones that designed the audit trail as a first-class deliverable rather than relying on platform-default logs.

What we recommend the audit trail capture, per integration call:

• Correlation ID that follows the call across services
• Authenticated principal (the caller — service identity, user identity, or partner identity)
• Operation invoked (the business meaning, not just the URL)
• Source IP / network identity
• Outcome (success, business error, system error)
• Timestamp at high resolution
• Reference to any payload archive (rather than the payload itself, which may contain sensitive data)

This information should land in a tamper-resistant store with a defined retention policy. Most regulated industries require seven years of audit trail; the operational systems that produced the audit are not the right place to retain it for that long.

Defence-in-depth, not perimeter-only

A pattern we still see in 2022 is integration security that depends primarily on network position — the integration platform is inside the corporate network, therefore traffic to it is assumed safe. This was a workable model when corporate networks were genuinely isolated. It is no longer workable when integrations involve cloud platforms, SaaS systems, mobile clients, and partner connections that all cross the perimeter daily.

The defence-in-depth posture we recommend:

• Every endpoint authenticates every caller, regardless of network position
• Every internal-to-internal call authenticates the same way external calls do
• Network segmentation is a control, not the only control
• Egress is restricted to known destinations
• Lateral movement between integration components is prevented by service-level authentication, not just network reachability

The argument against this posture is operational overhead. The argument for it is that every credential compromise, every partner integration that turns out to be more accessible than intended, every cloud integration that opens an unexpected ingress path — all of these scenarios are common, and a perimeter-only posture has no defence against them.

What to fund first

Most integration estates we audit have known security gaps that have been catalogued in previous audits and deferred because the remediation work is unglamorous. The investment priorities we typically recommend, in order:

1. Secrets management — move every credential out of configuration and into a managed secrets store. Six to twelve weeks of focused work.
2. Certificate lifecycle — bring every certificate under managed lifecycle with expiry alerting. Four to eight weeks plus ongoing.
3. Service account scope review — audit every service account, remove unneeded permissions. Two to six weeks of focused work plus stakeholder discussions.
4. Audit trail consolidation — make sure every integration produces the audit shape above. Six to twelve weeks plus tooling.
5. Authentication tightening — confirm every JWT is validated, every OAuth flow is using the right grant, every mTLS handshake is verifying. Ongoing work.

The estates we have helped through their first proper integration security audit have all needed at least the first three. The estates we have helped through their second audit (after a breach or near-miss) have invested in all five. The work is not optional indefinitely; the question is whether it happens before or after an incident makes it urgent.