SFTP or a transfer link? They are not competing

Plenty of industries still move files over SFTP, and the reflex reaction from outside — that it is legacy and should be replaced — is usually wrong. It is also often the wrong tool for what it is being used for.

The two are good at genuinely different jobs. Here is how to tell which one you are actually doing.

What each is for

SFTP is a protocol for systems to exchange files on a schedule. A nightly export lands in a directory, a process at the other end collects it, and nobody is involved. It is credentialed, scriptable, and has no opinion about people.

A transfer link is for a person to hand something to another person, once. It is a URL, it works in a browser, and it expires.

The friction appears when one is used for the other's job: a finance team manually dragging files into an SFTP client because that is what exists, or an automated pipeline scraping download links because someone set it up that way.

The comparison

	SFTP	Transfer link
Recipient needs	Credentials and a client	A browser
Setup per new partner	Account, keys, firewall rules	None
Automation	Excellent	Poor by design
Access ends when	Somebody revokes the account	The clock runs out
Who can read the file	Whoever runs the server	Nobody, if end-to-end encrypted
Audit trail	Server logs, if kept	Download counts and receipts
Ongoing cost	A server and someone to run it	A subscription

Where SFTP is genuinely better

• Recurring machine-to-machine transfers. A nightly feed should not involve a human clicking anything.
• Data that must not leave your infrastructure. If policy says the bytes stay on hardware you control, a hosted service is not an option regardless of its encryption.
• Very large, very regular volumes, where a per-seat subscription stops making sense.
• An existing integration that works. Replacing a functioning pipeline because it feels old is how outages happen.

Where it quietly fails

One-off external hand-offs. Creating an account, issuing credentials and adding a firewall exception so that a client can receive one PDF is disproportionate, and it usually ends with someone emailing the file anyway.

Access that never ends. This is the real risk. SFTP accounts are created for a project and outlive it by years. Nobody revokes them because nobody owns the list. Every dormant account is a live credential, and the shared ones — a single login used by a whole partner organisation — are worse, because the password is in a wiki somewhere and there is no way to know who used it.

Plain FTP. Worth saying explicitly: FTP without the S sends credentials and data in the clear. It should not cross the internet. If you have one running, that is the thing to fix first.

Non-technical users. Handing someone a hostname, a port, a username and a key file, and asking them to install a client, is a support ticket with a delay attached.

A reasonable split

Most organisations end up wanting both, divided by whether a person is involved:

• Scheduled, systematic, internal, high-volume — SFTP or an equivalent.
• Ad hoc, external, one person to another — a transfer link with an expiry.

The mistake is forcing everything down one path. An SFTP server used for occasional client hand-offs accumulates dormant accounts; a transfer service used for a nightly feed becomes a fragile script pretending to be a browser.

If you are moving off SFTP for the human cases

Three things to check, because they are what SFTP was giving you implicitly:

1. Expiry that deletes, so access ends without anyone maintaining a list.
2. A record of who downloaded what — download counts, and delivery receipts if the service mails the link.
3. Encryption you can describe. "The provider cannot read it" is a stronger sentence in a security review than "it is encrypted".

Related: choosing a file transfer service, how to send files securely, and file sharing and GDPR.