Managed file transfer (MFT) integration security guide: securing connector accounts, keys and tokens

A managed file transfer platform holds the credentials for almost every system it touches, so one compromised MFT server can hand an attacker the keys to your directory, your storage, your partners and your security tooling. MFT platforms connect to an identity provider for sign-in, a directory for user lookups, a SIEM for logs, a ticketing system for failed jobs, internal shares and databases, cloud object storage, and dozens of trading partners over SFTP, AS2 and APIs. Each of those connections runs under a service account, key, certificate or token, and most of them are stored inside the platform. This guide covers how to scope, store, rotate and monitor those integration identities. It is vendor-neutral and written for MFT administrators, identity engineers and security architects. Hardening the platform itself is covered in the Managed File Transfer (MFT) Security Guide; this page goes deeper on the connectors.

Key takeaways

• The MFT database is a credential store. Partner passwords, storage keys, directory bind passwords and API tokens usually sit in the platform's own database, so a web shell on the server reaches all of them at once.
• One identity per connection and direction. A separate account, key or client for each partner, each internal system and each direction lets you revoke one flow without stopping the rest.
• Prefer credentials that cannot be copied and replayed. Certificate-based client authentication, sender-constrained tokens and cloud workload identity beat static passwords and long-lived keys.
• Read-only where the integration only reads. Directory lookups, SIEM pulls and ticket creation need far less than the administrator accounts they are often given.
• Plan the mass rotation before you need it. After an MFT compromise every stored credential must be treated as exposed; a tested rotation runbook turns weeks of work into days.

The MFT integration map

Start with an inventory. Most platforms expose connections in several places: global settings (directory, SSO, SMTP, syslog), workflow or job definitions (shares, databases, storage, partner endpoints) and API client registrations. Export all three. The table lists the usual connections and what a good pattern looks like.

Why connector credentials are the pivot

The MFT exploitation waves of recent years show why integration identities matter as much as patching. All of the following are in the CISA Known Exploited Vulnerabilities catalogue with known ransomware use: CVE-2021-27101 (SQL injection, added 2021), CVE-2023-0669 (remote code execution, added 10 February 2023), CVE-2023-34362 (SQL injection, added 2 June 2023), CVE-2024-50623 and CVE-2024-55956 (unrestricted and unauthenticated file upload, added 13 and 17 December 2024) and CVE-2025-10035 (deserialisation, added 29 September 2025). Each gave attackers code or query execution on the platform that stores the connector secrets.

CISA advisory AA23-158A describes the web shell used in the 2023 campaign. According to the advisory, it could enumerate the platform database, retrieve files, run a query returning the cloud object storage account, key and container settings, and create administrator accounts with random names and the display name "Health Check Service". The advisory notes that rebuilding the web server while keeping the database leaves the attacker's accounts in place. The lessons for integrations:

• Stored secrets are reachable by design: the platform must decrypt connector credentials to use them, so database access plus the application key is enough. Externalise what you can to a secrets manager or to workload identity, so the database holds a reference, not the secret.
• Blast radius is set by scope, not by the exploit: a storage key scoped to one container, or a bind account that can only read one organisational unit, limits what a stolen copy is worth.
• Persistence lives in configuration: new admin accounts, new API clients, new partner keys and changed connector targets survive a rebuild unless you review them.

Mapped to MITRE ATT&CK, the chain is usually T1190 Exploit Public-Facing Application, T1505.003 Web Shell, T1552.001 Credentials In Files, then T1078.004 Cloud Accounts or T1199 Trusted Relationship to reach connected systems, and T1567.002 Exfiltration to Cloud Storage or T1048 Exfiltration Over Alternative Protocol.

Identity provider and directory connections

• SSO for every administrator: put the admin console behind SAML or OIDC so MFA, conditional access and leaver processing come from the identity provider. Keep one local break-glass account, vault its password and alert on every use.
• Authenticate the OIDC client properly: where the platform is an OIDC relying party, prefer key-based client authentication (private_key_jwt or mutual TLS) over a shared client secret. RFC 9700, the OAuth 2.0 Security Best Current Practice (January 2025), recommends asymmetric client authentication. See the JWT Client Authentication (private_key_jwt) Guide.
• Track the signing certificate: SAML signing and encryption certificates expire. Record the expiry in the integration inventory and rotate with an overlap window, so a lapsed certificate does not push admins back to local logins.
• Directory bind accounts: MFT platforms often look up users and groups over LDAP. Use LDAPS (port 636) or StartTLS, a dedicated bind account with read rights on the organisational units that hold MFT users, no interactive logon and no group memberships beyond what lookup needs. A bind password stored in clear in the MFT configuration should be rotated on the same schedule as other service accounts.
• SCIM provisioning: RFC 7644 defines no authentication scheme of its own; bearer tokens are used with TLS, and it says tokens issued on weak or no authentication should not be used. Give the SCIM token to the identity provider only, scope it to the MFT tenant and rotate it on a schedule. See the SCIM Provisioning Guide and the Identity provider (IdP) and SSO platform integration security guide.

SIEM and log forwarding

The SIEM connection is the one that tells you when the others are abused, so it must be reliable and hard to tamper with.

• Push over syslog TLS: RFC 5425 assigns TCP port 6514 to syslog over TLS and requires implementations to support certificate-based authentication on both sides, including authorising peers by certificate fingerprint. It describes unauthenticated configurations as not recommended. Plain UDP syslog on port 514 offers no integrity or confidentiality.
• Pull with a read-only role: if the SIEM collects through the MFT audit API, create a role that can read audit and transfer logs only. A token that can also change configuration lets anyone who steals it from the SIEM rewrite the MFT.
• Forward what investigations need: admin logons and failures, account and API client creation, role changes, connector and partner configuration changes, key and certificate uploads, transfer records (who, which file, size, source IP, destination) and service start and stop events.
• Protect the pipe: alert when the MFT log source goes quiet. Silence after a change window is a common sign of tampering or a broken certificate (NIST SP 800-53 AU-9, AU-6). See the SIEM integration security guide and Securing the SIEM itself.

Ticketing, ITSM and webhooks

• Outbound ticket creation: MFT workflows raise tickets when a transfer fails or a partner certificate is near expiry. The token needs create and update rights in one queue; it does not need to read other queues, where tickets often contain passwords and incident details.
• Inbound triggers and approvals: some organisations let an approved change or ticket trigger a transfer or a partner onboarding. Verify every inbound webhook with a signature over the body and a timestamp, reject replays and accept calls only from the ITSM platform's published egress addresses. See the Webhook Secrets Security Guide.
• Keep secrets out of tickets: partner onboarding tickets are where SSH private keys, PGP passphrases and initial passwords get pasted. Use the secrets manager or the MFT's own key exchange and put only a reference in the ticket. See the ITSM platform integration security guide.

API clients and automation

Business applications and scripts call the MFT API to submit and collect files. These clients multiply quietly and are rarely reviewed.

• OAuth client credentials over static keys: where the platform supports OAuth 2.0, register one client per calling application and grant only the scopes its jobs need. RFC 9700 says access token privileges should be limited to the minimum required and that tokens should be audience-restricted and, where possible, sender-constrained through mutual TLS (RFC 8705) or DPoP (RFC 9449). See the Machine-to-Machine OAuth (Client Credentials) Guide.
• No password grant: RFC 9700 states the resource owner password credentials grant must not be used. Scripts that send a human user's name and password to the token endpoint should be migrated.
• No admin scope for business jobs: an API key that can create users or change partner endpoints should belong to an administrative automation with its own owner and review, never to a reporting script.
• Bind clients to sources: restrict API clients to known source networks where the platform allows it, and log the client identifier on every call.

Storage, share and partner connectors

Cloud object storage

Replace account-wide storage keys with workload identity: an instance or managed identity, or role assumption through federation, issuing short-lived credentials scoped to the specific bucket or container and the actions the flow needs (write only for inbound drops, read only for outbound pickups). Where a static key is unavoidable, store it in a secrets manager, scope it with a shared access policy or bucket policy, and rotate it. See the Cloud Workload Identity Guide.

Internal shares and databases

Use a separate service account per share group or database, deny interactive and remote desktop logon, and use managed passwords (for example group managed service accounts on Windows domains) where the MFT agent runs on a domain host. Grant table-level or procedure-level rights, not schema ownership. See the Service Account Security Guide.

Partner SSH keys, AS2 certificates and OpenPGP keys

• SSH keys: NIST IR 7966 says command restrictions are particularly important for keys that authorise file transfers, and recommends restricting each automated key to approved source addresses, setting a maximum lifetime, rotating when the responsible administrator leaves, and removing keys unused for 6 to 12 months. See the SSH Key Management Guide.
• AS2 certificates: RFC 4130 requires X.509 certificates, allows them to be self-signed, and notes that only the combination of encryption, signing and a signed receipt (MDN) gives the full secure loop; unsigned MDNs make non-repudiation evidence weak. Track partner certificate expiry and verify new certificates out of band. See the EDI and B2B Integration Security Guide.
• OpenPGP keys: keep your decryption private keys in the platform's key store or an HSM-backed service with access limited to the decrypting workflow, set expiry dates, and confirm partner key fingerprints out of band at onboarding.

How to implement

1. Inventory (weeks 1 to 2): export global settings, workflow connectors, partner accounts and API clients. For each record the target system, credential type, where the secret is stored, scope, owner, created date, last used date and expiry.
2. Turn on visibility first: forward MFT audit logs to the SIEM over TLS, with alerts on admin and API client creation, before you change any credential. You need a baseline of normal connector use.
3. Remove what is unused: disable connectors, partner accounts and API clients with no use in 90 days (confirm with the owner), and delete after a further 30 days. Disabling first is the rollback path.
4. Re-scope the high-value connections: start with cloud storage, directory bind and admin API clients. Create the new narrow credential beside the old one, switch one flow, run it through a full business cycle (including month-end jobs), then revoke the old credential.
5. Externalise secrets: move connector secrets to a secrets manager or workload identity where the platform supports it. Test retrieval failure: a flow should fail closed and raise a ticket, not fall back to a cached secret.
6. Pilot partner changes with friendly partners: source restrictions, key replacements and certificate renewals affect external parties. Agree a window, keep the old key valid during an overlap period, and remove it once the partner confirms.
7. Write and test the mass-rotation runbook: list every stored credential with the steps and contact to rotate it. Rehearse it on a non-production instance at least once a year. See If your managed file transfer (MFT) is compromised.

Decision guidance

• Small organisations: with one MFT server and a handful of partners, focus on three things: SSO for admins, per-partner keys with source restrictions, and a vaulted, scoped storage credential. Most of the risk sits there.
• Large organisations: with hundreds of partners and several MFT nodes, treat the MFT as a privileged access tier, put connector inventory into the identity governance platform, and require an owner and expiry on every partner account and API client.
• SaaS MFT: the provider runs the platform, but you still own the connectors: directory sync, storage connections, API clients and partner keys. Ask how connector secrets are encrypted and who at the provider can read them.

Detection and measurement

• New identities: creation of admin accounts, API clients, partner accounts or keys outside a change ticket.
• Connector changes: any change to a connector's target host, bucket, container or credential, especially followed by a large outbound transfer.
• Credential use from the wrong place: a storage key, bind account or partner key used from an address that is not the MFT server or the approved partner range (NIST IR 7966 recommends detecting use of an authorised key from unapproved hosts).
• Volume anomalies: downloads by one account or API client well above its baseline, or bulk reads of many partner folders in a short window (T1020 Automated Exfiltration).
• Log source health: loss of the MFT syslog stream or a drop in event volume.

Framework mapping

Common failure patterns

• Rebuild without rotation: the server is reimaged after an exploit but the database, the admin accounts the attacker created and every stored connector secret are restored as they were, which CISA AA23-158A specifically warns about.
• One storage key for everything: an account-wide object storage key that can read, write and delete every container is retrievable with a single database query.
• Shared partner credentials: one SSH key or password used for many partners, so a single leak forces an outage for all of them or, worse, is never rotated. The GoDaddy managed WordPress breach showed how one compromised access path exposed customers' sFTP and database credentials together.
• Integration tokens nobody watches: a token issued to a connected service outlives the project and is stolen from the third party. The Salesloft Drift breach shows how stolen integration tokens open every customer that trusted them.
• Admin API keys in business scripts: a reporting script holds a key that can create users and change partner endpoints, and the script sits on a file share.
• Quiet log forwarding failure: the syslog certificate expires, events stop, and nobody notices until an investigation needs them.

Practitioner checklist

• Export every connector, partner account and API client, with owner, scope, storage location of the secret and last use.
• Put all administrator access behind SSO with MFA and keep one vaulted break-glass account.
• Scope the directory bind account to read-only lookup over LDAPS.
• Replace account-wide storage keys with workload identity or container-scoped, short-lived credentials.
• Forward audit logs over syslog TLS with mutual authentication, and alert when the source goes quiet.
• Limit ticketing tokens to one queue and verify signatures on every inbound webhook.
• Issue one OAuth client or key per calling application, with no admin scope for business jobs.
• Give each partner its own key or certificate with source restrictions, expiry and an owner.
• Disable integrations unused for 90 days and review the rest quarterly.
• Rehearse the mass-rotation runbook at least once a year.

Standards and references

• CISA: Advisory AA23-158A, CL0P Ransomware Gang Exploits CVE-2023-34362
• CISA: Known Exploited Vulnerabilities Catalog
• IETF: RFC 9700, Best Current Practice for OAuth 2.0 Security
• IETF: RFC 5425, Transport Layer Security (TLS) Transport Mapping for Syslog
• IETF: RFC 4130, MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP (AS2)
• IETF: RFC 7644, System for Cross-domain Identity Management: Protocol
• NIST: IR 7966, Security of Interactive and Automated Access Management Using Secure Shell (SSH)
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Managed File Transfer (MFT) Security Guide · Secrets Management Guide · Third-Party Access Guide · Managed file transfer (MFT) health check · ERP platform integration security guide