Onboarding and retiring external file partners securely

Start with the relationship and its owner

First establish why the connection exists. What information is exchanged, which organisation receives it and which business process depends on it? Assign a business owner who can approve access and a technical contact who can implement changes. A name without a deputy creates a problem when someone is absent or changes roles.

This follows the principle in the Dutch NCSC guidance on granting and withdrawing access: permissions should match the work and the period for which access is needed. Applying that principle to file partners also means considering technical accounts, which can continue operating after a named contact leaves.

Separate people, systems and server identity

A person downloading files manually has a different role from an application delivering a file every night. Use identifiable accounts for people and technical connections. For each technical identity, record the application using it, the responsible owner and the purpose for which access is permitted.

Also distinguish the key used to authenticate a partner from the host key used to identify the server. The IETF SSH architecture describes those functions separately. Agree how a new server identity or changed key will be verified. An unexpected change should prompt a check with the agreed contact before the trusted identity is updated.

Test the permissions the partner actually has

A convenient starting folder says little about access elsewhere. In Control-M MFT Enterprise 9.0.22, a user with a specific default folder can also reach other authorised folders. Review the complete allocation, including groups, and distinguish between uploading, downloading, renaming and deleting.

The BMC virtual-folder documentation illustrates why this matters. Where user permissions conflict with group permissions, the broader authorisation takes precedence. That behaviour is specific to the product. Testing should therefore demonstrate that the intended transfer succeeds and that unwanted access is refused.

A fictional supplier example

Suppose a supplier delivers daily stock files. The supplier only needs to upload; an internal application processes the files. A separate contact handles changes. The following agreements form a simple partner record. This is a fictional example, not an account of a customer implementation.

On a narrow screen, scroll the table sideways. With a keyboard, focus the table and use the arrow keys.

Make changes and offboarding repeatable

Review access when the supplier changes applications, a contact leaves or additional information is required. Recheck existing permissions at the same time. Adding new rights without reviewing old ones can leave unnecessary access in place.

When a relationship ends, first identify processes that still depend on the connection. Agree when new deliveries will stop and who will handle remaining files. Withdraw credentials and permissions according to that agreement. Check what happens to existing sessions and alternative access paths: disabling one account does not prove that every route has been closed.

Handle stored files separately. Withdrawing access does not automatically remove data. Record the applicable retention, handover or deletion agreement, together with confirmation that the agreed offboarding steps were completed. That record should identify who approved the closure and who verified it.

What to do and what to avoid

Do: test access from the partner's role and record what that role must be unable to do. Include key replacement in an agreed change process.

Avoid: treating a shared username, recognisable folder name or old contact list as evidence that access remains appropriate. A working connection is not a reason to extend an expired business relationship.

Current context: component versions still matter

Checked on 29 October 2026. OpenSSH 10.5, released on 11 August 2026, includes a correction involving key restrictions. It is an upstream release, not a statement about every MFT product. Establish which SSH component your solution uses and which supplier updates are available. Treat this as maintenance context, rather than a general warning about all partner connections.

Short questions about partner access

Does every partner need its own account? Choose identities whose purpose, owner and permissions can be managed separately. One organisation may have several applications and people with different requirements.

Is a key enough to secure access? A key is an authentication mechanism. Permissions, server verification, ownership and withdrawal still need separate decisions.

When is offboarding complete? When the agreed access has ended, dependent processes have been addressed and the treatment of remaining data has been recorded.

Explore Managed File Transfer or use an MFT Risk & Modernisation Scan as a starting point for discussing the current setup.