How should organisations secure mainframe file transfers when FTP is still in use?

Organisations should replace legacy FTP with encrypted file transfer controls that protect credentials and data in transit. FTP was never designed for secure transport, so it remains exposed to password sniffing and man-in-the-middle attacks. A practical programme should prioritise authenticated, encrypted transfers, minimise manual handling, and preserve operational continuity when large or mission-critical files move between systems.

Why FTP Is the Wrong Trust Model for Mainframe Transfers

FTP is still common in mainframe environments because it is operationally familiar and easy to automate, but its trust model is weak for modern file movement. The protocol sends credentials and payloads without built-in encryption, so the transfer path must be treated as exposed unless another control layer is added around it. That makes the real design question not convenience, but how to preserve batch reliability without leaving credentials and data readable on the network.

For teams that cannot change every dependent workflow immediately, the security goal is to reduce exposure in the transport layer first, then remove the legacy pathway over time. That usually means replacing plain FTP with managed encrypted transfer services, tightening network reachability, and making sure the transfer endpoint is authenticated before any file exchange is allowed.

Controls That Matter When FTP Cannot Disappear Overnight

The safest transition path is to wrap the file movement in controls that secure both the session and the operator workflow. Use encrypted protocols or secure gateways for all new transfers, enforce authenticated endpoints, and keep credentials out of scripts, job logs, and shared directories. Where operational compatibility still forces FTP in a narrow exception path, segment it heavily and make the exception visible, time-limited, and owned.

Mainframe file transfer also depends on reliability, so security controls should be chosen with throughput, restart behaviour, and error handling in mind. Large or mission-critical files often fail badly when teams bolt on ad hoc encryption or manual re-entry steps. Good practice is to preserve automation, but move the trust boundary so that encryption, authentication, and monitoring happen before data crosses the network.

For organisations managing long-lived transfer accounts and shared integration secrets, the most relevant identity risks are overprivilege, weak rotation, and hidden credential sprawl. NHIMG’s Ultimate Guide to Non-Human Identities is useful here because file-transfer accounts often behave like machine identities, with the same exposure to excess privilege and poor lifecycle control. The practical lesson is to treat transfer credentials as governed secrets, not as static configuration.

Risk and Threat Considerations

Plain FTP creates two immediate exposure paths, credential interception and session tampering. If the transfer crosses any untrusted or shared network segment, an attacker who can observe traffic may recover reusable credentials or alter the data stream in transit, which turns a routine batch job into a compromise path.

Failure mechanism: The protocol lacks native confidentiality and strong integrity protection, so the organisation relies on the surrounding network being trusted and the endpoint configuration being perfect. Any weak link in that chain, such as a sniffable segment, reused password, or misrouted transfer, can expose both the file contents and the access path itself.

Impact: Stolen transfer credentials can be reused for lateral access, data exfiltration, or unauthorised job execution, while tampered files can corrupt downstream processing or create false business records. In mainframe environments, where transfers often feed financial, operational, or regulated workflows, that can become an availability and integrity problem as much as a confidentiality problem.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 6 — Access Control Management	Covers limiting and revoking access used by transfer accounts and exceptions.
	CIS 8 — Audit Log Management	Supports monitoring file-transfer activity and detecting misuse or tampering.
	CIS 13 — Network Monitoring and Defense	Applies to observing exposed FTP traffic and unusual session behaviour on transit paths.
Recommendation — Restrict FTP exception accounts to minimum required access and revoke unused transfer paths promptly. Log transfer authentication and file movement events so anomalous FTP use is detectable. Inspect transfer network paths for unencrypted FTP sessions and isolate any residual legacy routes.
NIST CSF 2.0	PR.AC — Access Control	Directly addresses authenticated, least-privilege access for transfer mechanisms.
	PR.DS — Data Security	Covers protecting file contents in transit and at rest during transfer workflows.
	DE.CM — Continuous Monitoring	Supports detection of residual FTP exposure and abnormal transfer activity.
Recommendation — Enforce authenticated transfer access and remove unnecessary reusable credentials. Protect transferred files with encryption so data remains confidential during movement. Monitor legacy transfer flows for cleartext sessions and unexpected account use.
NIST Zero Trust (SP 800-207)	SC-7 — Boundary Protection	Relevant because legacy FTP should not be trusted across open network boundaries.
	IA-2 — Device/User Authentication	Applies where transfer endpoints must be authenticated before exchange occurs.
	AC-6 — Least Privilege	Fits transfer accounts that should be limited to the exact files and hosts needed.
Recommendation — Place legacy transfer services behind tightly controlled boundaries and segmentation. Require strong authentication for every transfer endpoint before allowing file exchange. Limit each transfer identity to the smallest file and host scope needed for the workflow.
OWASP Non-Human Identity Top 10	NHI-01 — Discovery and Inventory	Transfer accounts and automation credentials are non-human identities that must be found and governed.
Recommendation — Inventory all file-transfer identities and remove any unknown or orphaned credentials.

Practitioner Guidance

What to prioritise: Replace the highest-volume and highest-sensitivity FTP flows first, especially where the same account is reused across schedules, environments, or partner links. That is where exposure and blast radius are usually highest.

What to verify: Confirm that the replacement control actually encrypts both the session and the stored artefacts, and that authentication is tied to a managed identity or vaulted secret rather than a hard-coded password. If the new method still leaves credentials visible in jobs or logs, the migration is incomplete.

Common mistake: Treating “FTP over a restricted network” as equivalent to secure transfer. Network segmentation helps, but it does not remove the protocol’s inherent weakness if credentials or payloads are still exposed anywhere along the path.

Practitioner takeaway: The right objective is controlled transition, not perfect protocol purity, so secure the transfer path first, then eliminate legacy FTP only after the replacement has proved it can match the mainframe’s operational reliability.