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.
Related resources from NHI Mgmt Group
- Why do exposed SSH services and weak telnet exposure increase ransomware risk in public-sector networks?
- Why does remediation fail when sensitive files are spread across OneDrive?
- What breaks when SSH keys are managed manually across many systems?
- How should trading firms make privileged sessions audit-ready across SSH, Kubernetes, databases, and RDP?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
