SFTP, FTPS or MFT – how do you choose the right secure file transfer solution?

SFTP, FTPS or MFT – how do you choose the right secure file transfer solution?

SFTP is built on SSH, FTPS secures FTP with TLS and MFT is a platform. How to choose based on the number of flows, automation, traceability, partner requirements and availability.

Summary: SFTP, FTPS and Managed File Transfer are often used for the same basic need, moving files between organisations and systems securely, but they are not the same thing. SFTP is built on SSH, FTPS secures FTP with TLS, and MFT is more of a platform for managing and governing many file flows. The choice should therefore be driven by the number of flows, integration needs, traceability, automation, availability and how business critical the transfers are.

File transfer is old technology. But the need has not gone away. Organisations still need to move:

  • payment files
  • production data
  • reports
  • laboratory data
  • customer files
  • invoice data
  • integration files
  • backups
  • large data volumes between systems

What has changed is the requirements. Setting up an FTP server and creating a few accounts is no longer enough. When file transfer is part of a critical business process, the organisation also needs control over authentication, encryption, permissions, automation, logging, traceability, error handling, availability, and keys and certificates.

That is why it helps to understand the difference between the technologies.

Unencrypted FTP should be phased out

Traditional FTP was developed in a completely different era. RFC 2577, FTP Security Considerations from May 1999, states explicitly that all data and control information, including passwords, is sent across the network in unencrypted form by standard FTP, and recommends using a strong encryption scheme whenever possible.

That does not mean all old FTP stops working immediately. It means plain unencrypted FTP is a poor choice for modern, sensitive or internet-facing file flows. Two common safer alternatives are therefore SFTP and FTPS.

SFTP is not FTP over SSH

The names make that easy to assume. But SFTP is its own file transfer protocol used over a secure SSH channel. The SSH architecture provides authentication, confidentiality and integrity over an insecure network.

SFTP is common in system integrations, automated batch flows, exchange with external partners and server-to-server communication. Authentication can use SSH keys, for example.

For many organisations, SFTP is a simple and robust way to handle a limited number of secure file flows.

FTPS is FTP with TLS

FTPS works differently. It builds on FTP and uses TLS to protect the connection. RFC 4217, Securing FTP with TLS from October 2005, describes how FTP can be complemented with TLS for authentication, confidentiality and integrity.

FTPS can be relevant when an existing partner already uses FTP-based solutions, when an older system requires FTPS, or when the organisation needs compatibility with established FTP flows but wants to protect the communication.

So it is not a lesser SFTP. It is a different technical model.

Transport is not always the whole business need

Imagine the organisation has three external partners, five file flows and a few simple schedules. An SFTP server may then be entirely sufficient.

But now imagine 120 partners, 600 automated flows, several business systems, different protocols, and requirements for high availability, traceability, central credential management, reports and SLAs. The problem starts to change.

The question is no longer only how we encrypt the transport, but how we manage the entire file transfer estate. That is where MFT comes in.

MFT is a platform, not another protocol

Managed File Transfer is usually a platform for governing and managing file transfers. An MFT solution can use SFTP, FTPS, HTTPS, APIs and other technologies underneath. The value lies instead in the central management:

  • automation
  • scheduling
  • workflows
  • central logging
  • reporting
  • credential management
  • integrations
  • user portal
  • notifications
  • high availability
  • governance of many partners and flows

It is therefore misleading to ask whether you should have SFTP or MFT. An MFT platform may very well use SFTP as its transport protocol.

A simple comparison

SFTPFTPSMFT
TypeFile transfer protocolFTP secured with TLSPlatform or service
Secure transportYesYes, when the data connection is also protected with TLS (PROT P)Depends on the chosen protocol, normally yes
AutomationPossiblePossibleCore function
Many partnersPossiblePossibleOften easier to manage
Central reportingNeeds surrounding toolingNeeds surrounding toolingUsually a core function
WorkflowsLimited or project specificLimited or project specificCommon
Best suited toSimpler, well-defined flowsLegacy or partner requirementsMany or critical flows

Authentication matters as much as encryption

Encrypted traffic does not automatically mean a secure solution. The organisation also needs to know:

  • Who is allowed to connect?
  • How is the system or user identified?
  • Which directories may the account use?
  • Can the account only read, or also write?
  • How are keys and certificates rotated?
  • What happens when a partner relationship ends?

An old SSH key left active for ten years can be a bigger problem than the choice between two modern transport protocols.

Credential management quickly becomes a management problem

A small number of SSH keys can be handled manually. Hundreds of keys, passwords and certificates are something else. The organisation then needs control over owners, validity periods, rotation, storage, decommissioning and incident handling.

This is one reason centralised MFT solutions can become valuable even when the actual file transport still uses SFTP.

Logging and traceability

For business-critical flows it should be possible to answer:

  • Which file was sent?
  • When?
  • To whom?
  • Did the transfer succeed?
  • Who started it?
  • Was the file modified?
  • What happened when the transfer failed?

That kind of information matters for troubleshooting, audit, incident analysis and business follow-up alike. “The file should have gone out” is not a particularly good control model.

What happens when the file does not arrive?

This is perhaps the most important question. Imagine a file flow containing payments, orders, patient information or production data. What happens if the transfer fails at 02:00? Is there:

  • automatic retry
  • alerting
  • escalation
  • a manual fallback procedure
  • a check that the recipient actually processed the file

This is where secure file transfer starts to become a question of operational resilience.

Cloud or on-premises?

Both models can be relevant. Factors to weigh include information classification, regulatory requirements, internal integration needs, availability, competence, operational responsibility, exit, data locality and cost model.

We work with both cloud-hosted and on-premises setups, and treat implementation, automation, credential management and monitoring as parts of the delivery rather than separate projects.

When is SFTP enough?

SFTP can be a very good choice when:

  • the number of flows is limited
  • the integrations are relatively simple
  • partners support SFTP
  • the organisation has control over keys and accounts
  • monitoring and automation can be handled reasonably

There is no reason to buy a large MFT platform simply because MFT sounds more advanced.

When does MFT become interesting?

MFT becomes more interesting when:

  • the number of partners grows
  • many business-critical flows need coordinating
  • several protocols need supporting
  • central traceability is required
  • administering accounts and keys becomes heavy
  • the business needs workflows and automation
  • high availability matters
  • audit and reporting take a lot of time

At that point it is mainly the management and governance that justify the platform.

How Kristensson i Skåne can help

Kristensson i Skåne works with secure file transfer solutions and MFT both as projects and as an ongoing service. We can help with, for example:

  • current-state mapping
  • migration from legacy FTP
  • choosing between SFTP, FTPS and MFT
  • design and implementation
  • automation
  • integrations and APIs
  • identity and access
  • key and certificate management
  • logging
  • monitoring
  • high availability
  • cloud or on-premises
  • ongoing operations and management

The goal is not to pick the most advanced platform. The goal is to pick the simplest solution that still meets the business requirements for security, traceability and availability.

An adjacent topic is how access to the transfer servers themselves is restricted within the network, which we covered in our insight on network segmentation for businesses.

Frequently asked questions

Is SFTP the same as FTPS?

No. SFTP is based on SSH-based secure communication, while FTPS is based on FTP complemented with TLS.

Is SFTP secure?

The protocol uses a secure SSH channel, but overall security also depends on configuration, authentication, key management and access rules.

Is MFT a protocol of its own?

No. MFT is normally a platform or service category that can use SFTP and FTPS, among others, for the actual transport.

When do you need MFT?

Mainly when the number of flows, partners, automation, traceability and management needs make individual SFTP or FTPS solutions hard to handle.

Do you need to review how files move in and out of your business? Read more about our secure file transfer and Managed File Transfer services or contact us for an informal conversation.

Sources: RFC 2577, FTP Security Considerations (May 1999); RFC 4217, Securing FTP with TLS (October 2005); RFC 4251 on the SSH protocol architecture. Verified 9 September 2026.

This text is general information. The right solution always depends on the individual environment, partner requirements and business risks.