Why is SSH a better choice than FTP or telnet for moving files across untrusted networks?

SSH is better because it encrypts the entire session, including file transfer commands and payloads, through a secure tunnel negotiated with public keys. FTP and telnet send data without comparable protection, which exposes credentials and content to interception. For sensitive data, secure transport is only part of the control set, but it is the essential baseline for reducing exposure.

Why SSH Protects File Transfers Better on Untrusted Networks

SSH is designed to protect both the control channel and the data flowing through it, so file transfer commands, session metadata, and payloads are encrypted in transit. That matters on untrusted networks because an attacker who can observe traffic should not be able to read credentials or reconstruct the transfer contents. FTP and telnet were built for a different trust model and do not provide that baseline protection.

What SSH Adds Beyond Simple File Copying

The practical advantage is not just encryption, but authenticated encryption with a negotiated session key and server identity checks during setup. In a file-moving workflow, that reduces exposure of usernames, passwords, commands, and file contents to passive interception. It also helps preserve integrity, so the recipient can trust that what arrived over the network was not modified in transit.

For file movement, SSH is commonly paired with SFTP or SCP so the transfer uses the same protected transport. That means you are not relying on a separate plaintext protocol for authentication or control. On networks you do not fully trust, this distinction is critical because even a short-lived login or a single sensitive file can create material exposure if the transport is not protected end to end.

Why FTP and telnet Fail the Untrusted-Network Test

FTP and telnet transmit sensitive material in ways that make interception straightforward. Telnet exposes the interactive session in cleartext, while classic FTP exposes credentials and file movement metadata unless it is separately wrapped in a secure transport. In both cases, the issue is not only confidentiality but also the lack of a built-in trust boundary for the session itself.

That gap becomes especially relevant when credentials are reused, when files contain regulated or commercially sensitive data, or when traffic passes through Wi-Fi, guest networks, shared infrastructure, or third-party links. Once the transport is observable, an attacker does not need to defeat the application to gain value from the traffic.

Risk and Threat Considerations

Untrusted networks create interception and tampering risk, and plaintext protocols make that risk easy to exploit. The main threat is passive capture of credentials and file contents, but active manipulation is also possible when the transport does not authenticate the peer or protect the session.

Failure mechanism: The protocol sends authentication material, commands, or payloads without a secure encrypted tunnel, so an observer or man-in-the-middle can read or alter traffic before the transfer completes.

Impact: Attackers can steal credentials, exfiltrate files, replay access, or redirect the workflow into a compromised destination, which turns a routine transfer into a data exposure event.

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 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-2 — Identification and Authentication (Organizational Users)	SSH file transfer relies on authenticated sessions over untrusted networks.
	SC-8 — Transmission Confidentiality and Integrity	SSH protects file commands and payloads in transit across untrusted networks.
	SC-13 — Cryptographic Protection	SSH depends on cryptography to secure the session and transferred data.
Recommendation — Require authenticated sessions for file transfer tools before allowing access. Use protected transport to preserve confidentiality and integrity in transit. Apply cryptographic protection for data and commands moving across networks.
CIS Controls v8	CIS-12 — Network Infrastructure Management	Secure remote transfer depends on controlling exposed network paths and services.
Recommendation — Limit exposed remote transfer services to approved secure protocols.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	SSH is a cryptographic control for protecting data in transit over untrusted networks.
Recommendation — Mandate cryptographic protection for sensitive network transfers.

Practitioner Guidance

What to verify: Make sure the transfer method authenticates the server, encrypts the session, and does not fall back to legacy plaintext behavior. If the tool supports multiple modes, confirm that the secure mode is the default and that operators cannot accidentally use an insecure one.

Common mistake: Treating encrypted transport as the whole control set. SSH is the baseline for untrusted networks, but you still need destination access control, file handling rules, and credential hygiene if the files are sensitive.

Practitioner takeaway: Use SSH when the network cannot be trusted, because the real decision is not file transfer convenience, but whether the session itself can survive exposure to observation and interception.