FTP, or File Transfer Protocol, is a legacy method for moving files between systems. It was designed for function, not security, so it does not inherently protect credentials or data in transit. In regulated environments, that makes it unsuitable for sensitive mainframe file exchanges unless wrapped in additional controls.
FTP as a legacy transfer protocol
FTP is a protocol for moving files between systems, but its original design prioritized basic transfer functionality over confidentiality and integrity. That means the protocol itself does not protect the session, the credentials used to log in, or the contents being transferred.
In practice, FTP is best understood as a transport mechanism that depends on the surrounding environment for protection. If an organisation uses it at all, the real security posture comes from compensating controls such as network segmentation, strong access control, and secure replacement paths for sensitive transfers.
What FTP does and does not provide
FTP separates control traffic from file data and was built for interoperability across older systems. That legacy design is why it still appears in constrained environments, but it also explains the protocol’s core weakness: the protocol does not natively encrypt either authentication or payloads.
For that reason, FTP is not a safe default for regulated or sensitive exchanges. Even when the business need is just moving a file, the security question is whether the transfer path exposes credentials, file names, data content, or session metadata to interception or misuse. When that answer matters, a secure alternative or a wrapped transport becomes the relevant control decision.
Where FTP still appears in real environments
FTP persists because older mainframe, batch, and integration workflows can be deeply coupled to it. In those cases, the protocol is often present not because it is preferred, but because replacing it requires coordination across application owners, operations, and partner systems.
That makes FTP a governance problem as much as a technical one. The protocol may survive in a narrow file-exchange lane while the organisation layers compensating measures around it, but the longer it remains in place, the more the environment inherits legacy risk from weak encryption, broad trust boundaries, and difficult monitoring.
Where transfers involve sensitive data, organisations often compare FTP with better protected options through the lens of the protocol’s NIST Cybersecurity Framework 2.0 functions, especially protect, detect, respond, and recover, and may use NIST Privacy Framework thinking when personal or regulated data is involved.
Safer ways to think about file transfer security
The useful question is rarely whether FTP can move a file, because it can. The real question is whether the transfer method fits the sensitivity of the data, the trust boundary between systems, and the organisation’s ability to observe, control, and revoke access.
That usually means preferring encrypted transfer protocols, restricting legacy use to tightly governed exceptions, and treating any FTP dependency as something to inventory and review. For file exchange programs, the protocol choice should be evaluated alongside logging, authentication strength, endpoint hardening, and partner trust assumptions, not in isolation.
For a broader governance view of protocols and controls, many teams align decisions with CIS Benchmarks on the systems that host transfer services and with SOC 2 Trust Services Criteria when confidentiality and processing integrity are part of the control expectation.
Risk and Threat Considerations
FTP creates exposure because cleartext credentials and data can be intercepted if the network path is observable or if a transfer endpoint is compromised. That makes the protocol especially risky in shared, regulated, or partner-connected environments where file movement can reveal both sensitive content and reusable login material.
Failure mechanism: An attacker or intermediary captures login details, session contents, or transfer metadata, then reuses that access to read, alter, or redirect files.
Impact: The result can be data exposure, tampering, unauthorized file retrieval, or a broader compromise of adjacent systems that trust the same credentials or network segment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | FTP exposes credentials and file access paths, so protect functions must govern transfer access. |
| PR.DS — Data Security | FTP moves data without inherent encryption, so data protection controls directly apply. | |
| DE.CM — Continuous Monitoring | Legacy file transfer services need visibility to detect misuse, exposure, and anomalous transfers. | |
| Recommendation — Restrict FTP use to explicitly approved access paths and monitor transfer endpoints for unauthorized exposure. Protect transferred files with encryption and integrity controls before allowing legacy FTP use. Monitor FTP services and network flows for unexpected logins, file movement, and cleartext exposure. | ||
| CIS Controls v8 | 6 — Access Control Management | Legacy FTP depends on tightly controlled accounts and transfer permissions. |
| 13 — Network Monitoring and Defense | FTP traffic and services need monitoring because the protocol can expose credentials and data in transit. | |
| Recommendation — Remove unused FTP accounts and enforce least-privilege access for remaining transfer users. Detect FTP usage, alert on cleartext transfer paths, and investigate unexpected file exchange patterns. | ||
Practitioner Guidance
Why practitioners should care: FTP is not just an old protocol, it is a legacy trust decision. If it remains in use, the burden shifts to surrounding controls, and those controls must be specific enough to cover authentication exposure, transport exposure, and file integrity.
What to watch for: The biggest warning signs are persistent use for sensitive transfers, shared credentials, unclear ownership of exceptions, and lack of a documented replacement path. In mature environments, FTP should usually be a managed exception with a retirement plan, not an unexamined default.
Related resources from NHI Mgmt Group
- What breaks when organisations keep using plaintext FTP for sensitive transfers?
- How do security teams know whether FTP has become a hidden control gap?
- Should organisations prioritise FTP replacement before adding more monitoring around it?
- What do teams get wrong about insecure protocols like HTTP and FTP in application code?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
