Only for narrow legacy cases with compensating controls and a defined retirement plan. In most environments, SFTP or FTPS is the better operational choice because it encrypts authentication and content, improves auditability, and reduces the chance that a routine transfer becomes a breach path.
When FTP stops being a reasonable default
ftp is best treated as a legacy protocol, not a normal choice for routine file transfer. The decision is not just about convenience, it is about whether the transfer channel protects credentials, content, and session metadata well enough for the data being moved. If a transfer traverses shared networks, partner links, or any environment with audit and compliance expectations, plain FTP usually creates avoidable exposure.
By contrast, SFTP and FTPS add encryption to the transport, which changes the risk profile immediately. That matters because file transfer is often an operational background task, but from a security standpoint it can become a direct path to credential theft, content disclosure, or unauthorized replay if the protocol leaves traffic in cleartext.
That is why organisations should keep FTP only where a narrow legacy dependency makes it unavoidable and where the business has accepted the residual risk. For everything else, the better question is not whether FTP still works, but whether its remaining use is justified against a secured alternative such as NIST SP 800-53 Rev 5 Security and Privacy Controls and routine hardening guidance such as CIS Benchmarks.
What SFTP and FTPS change in practice
SFTP and FTPS are not interchangeable, but both solve the core weakness of FTP by protecting the transfer path. SFTP runs over SSH, while FTPS adds TLS to FTP. In both cases, organisations gain encryption in transit, better protection for usernames and passwords, and a safer basis for passing regulated or operationally sensitive data.
The practical improvement is not only confidentiality. Encrypting the control channel also improves trust in the transfer session itself, because credentials are no longer exposed to passive interception and the content is not available to anyone who can observe network traffic. This is especially important when transfers occur between partners, from automated jobs, or through infrastructure that is not fully under one team’s control.
That security gain becomes more compelling when a file transfer system is integrated with authentication, access control, or key management practices that already exist elsewhere in the environment. In other words, once the organisation has to manage authorised access anyway, it is usually cleaner to anchor transfer security in stronger controls than to preserve FTP as an exception, as reflected in NIST SP 800-63 Digital Identity Guidelines and NIST SP 800-57 Key Management.
How to decide whether FTP is still allowed
The decision should be based on dependency, not habit. Keep FTP only if there is a documented legacy system, partner limitation, or embedded workflow that cannot yet move, and only if the exception has a retirement date. If the transfer carries credentials, regulated data, or anything that would be painful to disclose, the burden of proof for keeping FTP should be high.
Where FTP remains temporarily necessary, organisations should treat it as a controlled exception with compensating safeguards: network isolation, strict source and destination allow lists, monitoring of every session, and explicit ownership for remediation. The transfer should also be scoped so that the exception is as small as possible, because the longer FTP survives, the more likely it is to become permanent by default.
For teams that need a formal control anchor, the governance expectation is simple: if there is a secure alternative, legacy plaintext transfer must be justified like any other risk acceptance. That aligns with control thinking in NIST Cybersecurity Framework 2.0 and with the access control and audit expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Risk and Threat Considerations
Plain FTP turns routine file movement into an easy interception point. The main risk is that credentials and content can be exposed in transit, and once that happens, the transfer path can become a foothold for unauthorized access, data theft, or abuse of trusted exchange processes.
Failure mechanism: FTP sends authentication and data without transport encryption, so any actor able to observe or manipulate the network path can capture credentials, read content, or tamper with sessions.
Impact: A single transfer account can expose many files, many downstream systems, or a partner integration, which makes the blast radius larger than the protocol looks on paper.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | FTP exception handling hinges on protecting and rotating credentials used for transfer access. |
| AU-2 — Event Logging | Transfer protocols need auditability so legacy FTP use can be monitored and reviewed. | |
| SC-8 — Transmission Confidentiality and Integrity | The question is fundamentally about encrypting file transfers in transit. | |
| Recommendation — Limit FTP credentials, rotate them promptly, and replace plaintext transfer paths with stronger authentication wherever possible. Log file-transfer sessions and review them for unauthorized or unexplained FTP use. Use encrypted transfer protocols to protect confidentiality and integrity across the network path. | ||
| NIST CSF 2.0 | PR.DS-02 — Data in transit is protected | Replacing FTP with SFTP or FTPS is a direct data-in-transit protection decision. |
| Recommendation — Move routine transfers to protocols that protect data in transit. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | FTP vs SFTP/FTPS is a cryptography-in-transit choice for file transfer protection. |
| Recommendation — Require encrypted transfer mechanisms where files cross networks. | ||
| CIS Controls v8 | CIS-3 — Data Protection | The issue is protecting transmitted files and credentials from exposure. |
| Recommendation — Encrypt sensitive transfers and retire plaintext file-transfer paths. | ||
Practitioner Guidance
What to prioritise: Start by inventorying every FTP endpoint and separating true legacy dependency from convenience. If a system can move to SFTP or FTPS without breaking a critical workflow, make that migration the default remediation path.
What to verify: For any temporary FTP exception, verify who owns it, what data traverses it, whether the session is network-restricted, and what evidence exists for planned retirement. If you cannot produce those answers quickly, the exception is too loose.
Practitioner takeaway: FTP is rarely the right long-term answer when encrypted alternatives exist; if it remains, it should be a consciously managed exception with a retirement clock, not an inherited transport standard.
Related resources from NHI Mgmt Group
- What breaks when organisations keep using plaintext FTP for sensitive transfers?
- Which IAM control matters most when organisations need to keep access available during identity provider outages?
- Why do organisations pay for SFTP when the protocol is available for free?
- How can organisations keep AI briefings useful for IAM and NHI operations?