TL;DR: Legacy FTP transmits usernames, passwords, and file contents in plain text, leaving sessions exposed to interception and brute-force abuse while SecurityScorecard’s article recommends encrypted alternatives such as SFTP, FTPS, and managed file transfer controls. Plaintext file transfer is now a governance problem, not just a protocol flaw, because exposed transfer paths can become an identity and data exfiltration entry point.
At a glance
What this is: This article says traditional FTP transmits credentials and file contents in plain text, making legacy file transfers vulnerable to interception and brute-force abuse.
Why it matters: For IAM, PAM, and NHI teams, insecure file transfer is an access-path problem as much as a data-protection problem, because exposed credentials and weak authentication can become an entry point into broader systems.
Context
FTP is a legacy file transfer protocol that was designed before modern encryption and identity controls became standard. Its core weakness is that control messages, login material, and file contents can travel in clear text, which makes the transfer path itself part of the attack surface rather than a neutral transport layer.
The governance gap is not just protocol choice. When organisations keep FTP in production, they often inherit weak authentication, poor visibility, and inconsistent network segmentation, which turns a simple transfer utility into an identity exposure point and a data exfiltration route.
This is a familiar pattern in legacy integration environments, where operational convenience delays migration even after the security model has clearly aged out of its original assumptions.
Key questions
Q: What breaks when organisations keep using plaintext FTP for sensitive transfers?
A: Plaintext FTP breaks confidentiality and weakens accountability at the same time. Attackers who can observe the network may capture credentials, session commands, and file contents, then reuse those secrets for broader access. It also creates hidden dependencies on service accounts and vendor integrations that security teams may not be reviewing as part of normal identity governance.
Q: Why does unencrypted file transfer create identity risk?
A: Because the authentication step is part of the traffic itself. If usernames and passwords travel in clear text, the transfer channel becomes an identity exposure point, not just a data channel. That is why file transfer governance has to include credential protection, account scope, and monitoring, not only encryption in transit.
Q: What are the signs that FTP is failing as a control?
A: Repeated failed logins, anonymous access, weak passwords, and file transfers from unexpected networks are all signs that FTP is no longer operating as a controlled service. If the protocol cannot prove strong identity or produce useful audit evidence, the control boundary has already weakened and should be treated as a migration priority.
Q: Should organisations keep FTP when SFTP or FTPS is available?
A: 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.
Technical breakdown
Why FTP exposes credentials and content in transit
Traditional FTP separates the control channel from the data channel, but neither is encrypted by default. That means usernames, passwords, commands, and file contents can be read by anyone able to observe traffic on the path. Because the protocol predates modern transport security, it has no native protection against packet sniffing, session replay, or inline interception. In practice, the lack of confidentiality is not a side effect but a design property. Once an attacker can see the session, they can often capture authentication material and reuse it to access the server or pivot into adjacent systems.
Practical implication: remove plaintext FTP from any path that carries credentials, sensitive records, or regulated data.
How weak FTP authentication becomes an access problem
FTP commonly relies on username and password authentication without stronger identity assurance. If those credentials are weak, reused, or exposed, attackers can brute force them or reuse them elsewhere. Anonymous access and default logins increase the risk further because they reduce the amount of resistance needed to reach stored files. The problem is not only password weakness. FTP implementations often lack certificate-based authentication or multi-factor support, which leaves the account lifecycle poorly protected and makes detection harder when legitimate and malicious access look the same at the protocol level.
Practical implication: treat FTP accounts as high-risk identities and remove any configuration that allows anonymous or weakly verified access.
Why secure alternatives change the control model
SFTP and FTPS change the security posture because they encrypt transport and reduce the chance of interception. SFTP rides over SSH and uses a single encrypted channel, while FTPS adds TLS protection to FTP-style workflows. Managed file transfer platforms go further by pairing encryption with audit trails, access governance, and integration to identity systems. That matters because the security problem is not only whether files move, but whether the transfer process is governed like an access-controlled workload. Modern file transfer therefore shifts the control point from passive monitoring to managed authentication, logging, and encryption enforcement.
Practical implication: standardise secure file transfer protocols and retire legacy FTP where governance, encryption, and auditability are required.
Threat narrative
Attacker objective: The attacker aims to capture credentials and files from a legacy transfer path, then use that access to steal data or expand into connected infrastructure.
- Entry occurs when an attacker positions themselves on the network path or otherwise gains visibility into plaintext FTP traffic.
- Credential access follows when usernames and passwords are captured from the unencrypted control session and reused against the FTP server or adjacent services.
- Impact occurs when intercepted file contents, stored credentials, or server access enable data theft, unauthorized downloads, or broader compromise of connected systems.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Plaintext transfer is an identity exposure problem, not only a protocol problem. FTP turns login material into network traffic, which means access control depends on the absence of observers rather than on a governed authentication boundary. That is a weak model for any environment that handles sensitive data, and it becomes harder to defend when credentials are reused elsewhere. Practitioners should treat insecure transfer paths as part of identity attack surface.
Legacy file transfer creates governance debt that outlives the protocol itself. Teams often retain FTP because migration is operationally awkward, not because the risk is misunderstood. The real issue is that unencrypted transfer paths keep delivering business utility while silently bypassing modern expectations around verification, logging, and data protection. Practitioners should inventory where FTP persists and classify it as an unmanaged access channel.
Secure file transfer is now a control-design question. The market conversation should move from whether FTP still works to whether the organisation can justify any workflow that cannot enforce encryption, strong authentication, and auditable access. That aligns more closely with NIST-CSF access control expectations and with NIST SP 800-53 IA-5 for authenticator management. Practitioners should retire legacy transfer patterns wherever identity and data governance matter.
Encrypted transport is the minimum, not the finish line. SFTP and FTPS reduce interception risk, but they do not by themselves solve overexposed service accounts, unmanaged third-party paths, or weak privilege design. The durable control objective is to govern file transfer like a workload with explicit identity, scope, and logging. Practitioners should connect transfer tooling to the same governance standards applied to other sensitive access paths.
What this signals
FTP persistence is a governance gap that many identity programmes still overlook. The security issue is not limited to transport confidentiality. It also includes unmanaged transfer identities, weak account scope, and third-party workflows that sit outside normal IAM review, so organisations need to treat file transfer endpoints as governed assets rather than background infrastructure.
Secure file transfer should be folded into access governance, not left with infrastructure teams alone. When credentials, files, and logs are all tied to the same workflow, the control model should include identity lifecycle, logging, and segmentation. That is the point where IAM, data protection, and network control stop being separate conversations and start functioning as one programme.
For practitioners
- Replace plaintext FTP with encrypted transfer controls Move sensitive workflows to SFTP, FTPS, or managed file transfer services that enforce encryption for both credentials and content.
- Inventory every FTP endpoint and account Identify all servers, integrations, vendors, and automation jobs still using FTP, then classify the data and identities they expose.
- Disable anonymous access and weak authentication Remove default logins, require strong passwords or key-based authentication where available, and review whether any FTP account still needs to exist.
- Segment legacy transfer services from core systems Isolate any remaining FTP server in a restricted network zone so a compromise does not create a direct path to sensitive repositories.
- Log and review transfer activity continuously Track authentication attempts, file transfers, and unusual source locations so insecure transfer use becomes visible before it turns into exfiltration.
Key takeaways
- Legacy FTP exposes both credentials and file contents, which makes interception a live risk rather than a theoretical weakness.
- The biggest issue is governance drift, because unencrypted transfer paths create identity exposure, weak auditability, and a potential exfiltration route.
- Security teams should prioritise encrypted alternatives, remove anonymous or weakly authenticated access, and isolate any remaining legacy transfer services.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | FTP transmits credentials in clear text, making authentication itself vulnerable to interception. |
| NHI-07 — Long-Lived Secrets | FTP accounts and passwords often persist long after their original operational need. | |
| Recommendation — Eliminate plaintext authentication paths for any transfer workload that still relies on FTP. Retire long-lived FTP credentials and replace them with shorter-lived, governed transfer identities. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | FTP access must be governed through explicit permissions and authentication boundaries. |
| Recommendation — Apply PR.AA-05 to restrict FTP access to the minimum identities and networks that still require it. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Weak FTP authentication and password reuse map directly to authenticator lifecycle controls. |
| Recommendation — Use IA-5 to enforce stronger authenticator management for any remaining file transfer accounts. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The main threat described is capture of FTP credentials from unencrypted traffic. |
| Recommendation — Treat plaintext FTP as a credential-access exposure and prioritise it in detection and remediation. | ||
Key terms
- Plaintext Transfer: Plaintext transfer means data is sent across the network without encryption. For identity and data security teams, that creates exposure of usernames, passwords, commands, and file contents to anyone who can observe the traffic path, whether on the endpoint, network, or a compromised intermediary.
- SFTP Service: An SFTP service is the secure file transfer component that handles authenticated file movement over SSH. In enterprise environments it often sits on the edge of sensitive data exchange, which makes any authentication weakness especially serious. A flaw in this service can expose files, accounts, and connected workflows at once.
- FTP: 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.
- Managed File Transfer Platform: A managed file transfer platform is software used to move sensitive files securely between systems, partners, and business units. In practice, it becomes a high-value target because it concentrates trusted data flows, often sits in production for years, and can expose many organisations if a single vulnerability is exploited.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is designed for practitioners who need to connect identity controls to the broader security programmes they run.
Published by the NHIMG editorial team on July 12, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org