A Security Guide to Data Transfer Protocols: FTP (File Transfer Protocol), SFTP (SSH File Transfer Protocol), and More

Choosing the right data transfer protocol is one of the most important decisions a security architect makes. Get it right and you’re building a foundation for compliant, efficient data exchange. Get it wrong and you’re creating gaps that auditors and regulators will find.

This guide covers the protocols that matter most in government, defence, and critical national infrastructure (CNI) environments, how they compare on security and performance, and where protocol choice alone isn’t enough.

A data transfer protocol is a standardised set of rules that governs how data moves between two systems or networks. Think of it as the agreed language and procedure that both sender and receiver follow so that data arrives intact, in the right format, and to the right destination, including rules for how data is structured and handled during transmission, such as at the packet level.

The choice of protocol affects far more than connectivity. It determines whether data is encrypted in transit, how both parties authenticate each other, what audit trail is available, and whether the transfer method will satisfy your compliance obligations under frameworks like NIS2 or ISO 27001. For organisations handling sensitive or classified data, these questions directly shape what your security architecture can and can’t do.

FTP is one of the oldest file transfer protocols in use, defined in RFC 959 (the protocol’s official specification document) and designed for straightforward file movement between client and server. It transmits data, including credentials, in plaintext with no encryption. Its primary use case today is legacy system integration, where replacement isn’t yet operationally feasible.

• No encryption on data or credentials

• Username/password authentication only

• Still common in older OT and industrial environments

• Not suitable for regulated or classified environments

It is sometimes used for basic file sharing and legacy file transfer workflows across different operating systems, but not in secure environments.

SFTP (SSH File Transfer Protocol) runs over Secure Shell (SSH) and provides encrypted file transfers with strong authentication mechanisms. Because it uses a single connection channel, it is generally easier to manage through firewalls than FTPS. SFTP also supports public key authentication, which improves security and enables automated, passwordless connections.

• AES encryption over SSH tunnel

• Supports password and public key authentication

• Preferred for secure file transfer in enterprise and government environments

• Aligns well with ISO 27001 and NCSC guidance on data in transit

It is commonly used for secure large file movement and enterprise file sharing.

FTPS adds Transport Layer Security (TLS) to the standard FTP protocol. It supports certificate-based authentication and encrypts both the command and data channels, but its use of multiple ports can complicate firewall configuration.

• TLS encryption for command and data channels
• Certificate-based and password authentication
• More complex firewall management than SFTP
• Used in financial services and regulated commercial environments

HTTPS is HTTP operating over Transport Layer Security (TLS), providing encrypted communication between clients and servers. It is the standard protocol for secure web traffic and API communication.

Our TrustedFilter® SECUREcommand module can terminate TLS connections, inspect the decrypted HTTP traffic, and then re-establish HTTPS connections. This is particularly useful at cross-domain boundaries where traffic inspection, policy enforcement, or protocol translation is required.

• TLS 1.2 or 1.3 encryption

• Certificate-based server authentication; mutual TLS available

• Widely used for API integration and web application data exchange

• Suitable for regulated environments when properly configured

SCP transfers files over SSH, providing encrypted point-to-point copy between hosts. It’s fast and simple, but offers limited functionality compared to SFTP. It doesn’t support directory listings, file management, or resuming interrupted transfers.

• SSH-based encryption

• Password and public key authentication

• Best for simple, one-off file transfers in trusted environments

• Limited audit capability compared to managed file transfer solutions

Applicability Statement 2 (AS2) and AS4 are messaging protocols designed for secure business-to-business data exchange. They support digital signatures, encryption, and non-repudiation receipts, making them well-suited to supply chain and regulated commercial data exchange.

• HTTPS transport with S/MIME encryption and digital signatures

• Certificate-based authentication with delivery receipts

• Common in defence supply chains and financial services

• AS4 adds WS-Security and is preferred in newer deployments

The dividing line is encryption. FTP, HTTP, and Trivial File Transfer Protocol (TFTP) all transmit data in plaintext, including credentials and file contents. These protocols have no place in environments subject to NIS2, ISO 27001, or NCSC guidance.

Yes, gradually. Major browser vendors have removed FTP support, and NCSC guidance consistently recommends encrypted alternatives. In practice, FTP persists in operational technology (OT) and industrial control system (ICS) environments because the devices using it are decades old and can’t be patched or replaced without significant operational disruption.

If that describes your environment, the answer isn’t to ignore the risk. Isolate the FTP traffic, monitor it closely, and layer additional controls at the network boundary. The protocol doesn’t have to change for the architecture to be defensible.

TFTP is faster in constrained environments because it uses UDP rather than TCP, which eliminates the connection overhead of a TCP handshake. That speed comes at a cost: TFTP has no authentication, no encryption, and no error recovery beyond basic retransmission. It’s used almost exclusively for bootstrapping network devices and firmware updates in isolated networks.

Speed is rarely the deciding factor when you’re operating across security boundaries. Integrity and policy enforcement are.

In a multi-classification environment, where data needs to move between networks operating at different security levels, the protocol is only one part of the picture. A secure protocol like SFTP encrypts data in transit and authenticates the endpoints. But it tells you nothing about what’s inside the files being transferred.

A well-formed SFTP transfer can carry malware, policy-violating content, or data that simply shouldn’t cross that boundary. The TLS handshake completes successfully. The transfer succeeds. The problem arrives silently.

Content inspection operates at a different layer from the transport protocol. Where protocol security confirms that a transfer is encrypted and authenticated, content inspection confirms that what’s being transferred is authorised, clean, and compliant with the policy for that boundary. That means syntactic and semantic verification of file formats, malware scanning, content disarm and reconstruction, and quarantining of non-compliant data before it crosses the domain boundary.

This is what 4Secure’s TrustedFilter® platform does, working alongside your existing protocol infrastructure rather than replacing it.

OT environments introduce a different set of protocols entirely. Modbus, DNP3 (Distributed Network Protocol 3), and OPC-UA (Open Platform Communications Unified Architecture) govern communication between sensors, controllers, and supervisory systems in energy, rail, manufacturing, and water treatment environments.

They weren’t designed with security in mind. Modbus has no authentication and no encryption. OPC-UA is the most security-aware of the three, with built-in support for authentication and encryption, but many OT deployments still run older versions without those features enabled.

The practical implication is that you can’t simply swap in an encrypted IT file transfer protocol and call the OT environment secure. You need protocol validation at the boundary, unidirectional enforcement where appropriate, and content inspection for data flowing from OT to IT.

For IT-to-OT data flows, SFTP or HTTPS with mutual TLS (mTLS) authentication are the preferred options where the OT system supports them. For OT-to-IT telemetry and monitoring data, a unidirectional gateway enforcing one-way data flow provides a stronger assurance model than any protocol-level control alone. The hardware design prevents return traffic regardless of software configuration.

Compliance frameworks don’t ask whether you used an encrypted protocol. They ask whether you can demonstrate that data in transit was protected, that access was controlled and auditable, and that the integrity of the transfer can be verified.

NIS2 requires organisations to implement appropriate technical measures for data security. ISO 27001 requires documented controls and evidence of their effectiveness. Neither framework is satisfied by “we used SFTP.”

Data diodes, cross-domain solutions (CDS), and content inspection tools are the controls that sit alongside protocol selection to provide that demonstrable assurance. A data diode enforces one-way data flow at the hardware level.

A CDS provides policy-enforced, content-validated transfer across classification boundaries. These aren’t alternatives to choosing the right protocol. They’re the next layer of the architecture once you’ve made that choice.

NIS2 requires that organisations in scope implement measures proportionate to the risk, including encryption of data in transit. Using plaintext protocols like FTP in a regulated environment would be a straightforward compliance gap.

But NIS2 also requires incident detection, audit logging, and supply chain security controls. Protocol selection feeds into all of these: encrypted protocols support audit trails, and protocol validation at network boundaries supports detection of anomalous data flows.

The right protocol depends on four things: the security classification requirements of the networks involved, your compliance obligations, whether you’re operating in an IT or OT context, and the performance demands of the transfer.

For most enterprise and government environments, SFTP or HTTPS with mTLS will be the right starting point. For defence supply chain data exchange, AS4 provides non-repudiation and digital signatures that SFTP can’t match. For OT environments with legacy devices, the answer is often to isolate the legacy protocol and enforce controls at the network boundary rather than on the device itself.

Protocol selection is the foundation, not the finished architecture. Getting secure data transfer right means thinking across the full stack: the right protocol for the transfer type, content inspection at the boundary, unidirectional enforcement where classification demands it, and audit capability that satisfies regulators.

If you’re working through that architecture for a classified, OT, or cross-domain environment, the team at 4Secure has been doing exactly this since 2003. Speak to a specialist to talk through your specific requirements, or explore our cross-domain solutions to see how high-assurance data transfer works in practice.

If you’d like to talk through your environment and get a clear recommendation, request a free architecture consultation with our team. We’re happy to start a conversation.