Transfer Client Features That Actually Matter (When You Choose for Everyone Else)

"Which client should I install?" is a ten-minute question when the person asking is you. Download the one a colleague swears by, connect, done. It is a different question when the answer lands on two hundred machines you will rarely see. The people in front of them have never heard the phrase "host key". You get the blame the first time the client fails. The download page's feature list was written to sell to the person reading it, not to protect an organization.

A transfer client is the program on the user's side of the connection: it logs in, shows the folders, and moves the file. This article is the checklist for choosing one for everyone else: protocols, keys and certificates, host-key prompts, resume, scripting, logging, and deployability. Each is weighed for you and for the person clicking the buttons. The article ends in a scored table and a thirty-minute lab. It is part of our Client Standardization series, and the rest of the series stands on it.

Two Stakeholders, One Download

Choosing for an organization means serving two people who want different things. The end user wants the client to be obvious: find the server, drag the file, watch it arrive. They will never open a settings dialog on purpose. The administrator, which is you, wants it safe by default, deployable without visiting every desk, diagnosable when it breaks, and boring to keep updated. Nearly everything on your list is invisible to the user.

So every feature here carries an admin weight and a user weight. A drag-and-drop queue is everything to a daily operator and nothing to you; a silent installer is the reverse. Both count. But the features a download page shouts about sit on the user side, and the features that prevent incidents sit on yours. I have scored clients for three organizations, and the winner was never the one with the longest feature page.

Protocols: The Two or Three You Need, and an Off Switch

Protocol coverage is the first line of every feature list, and the number is nearly meaningless. What matters is whether the client speaks the two or three protocols your servers and partners use. It must speak them correctly and let you switch off the rest.

• SFTP — the file transfer subsystem of SSH, one encrypted connection, normally to port 22. Most organizations standardize on it, so the client must do it well. That means key authentication, host-key checking, resume, and clean listings against servers of every flavor. How SFTP works covers the protocol.
• FTPS — classic FTP wrapped in TLS, still required by many partners and older systems. The client must support explicit FTPS (the modern form: connect on port 21, upgrade with AUTH TLS). It must validate the server's certificate rather than accept anything. FTPS also inherits FTP's separate data connections. So passive mode and correct TLS session reuse on those connections are real compatibility features. The article on FTPS client compatibility explains why those two details decide compatibility.
• Plain FTP — unencrypted, credentials in cleartext, supported by every client. The feature that matters is the opposite one: can you disable it, per profile and ideally by policy, so nobody creates a plain-FTP connection by accident? A client with no way to remove that radio button undoes your plain-FTP retirement one click at a time.
• HTTPS and WebDAV — nice to have, rarely decisive. Web transfer usually happens in a browser, a point the next article returns to.

Two protocols done thoroughly beat eight done superficially. The most valuable "protocol feature" on the list is the off switch.

Authentication and Key Handling

Every client can type a password; the differences start beyond passwords. Our comparison of authentication methods covers the server's side; here is the client's.

SSH keys

An SSH key pair is a private key the user keeps and a public key the server holds. The client proves it holds the private key instead of sending a password. Three client-side features matter.

• Key formats. Keys come in more than one on-disk format. Most servers and command-line tools use the OpenSSH format. Some Windows graphical clients prefer the PuTTY format. A client that reads both, or converts between them, saves a hundred tickets. See generating and storing keys.
• Passphrases and agent support. A private key should be encrypted with a passphrase. The client should ideally work with an SSH agent, a background program that holds the unlocked key. That way, the passphrase is typed once per session, not once per connection.
• Per-profile key selection. The client should attach a key to a saved connection, not make the user browse for a file every time.

Less common, and disqualifying when absent: some FTPS and HTTPS servers require a client certificate, the TLS equivalent of an SSH key. If a partner requires one the client must be able to present it. See client certificates and mutual TLS.

Where saved passwords go

This is the feature nobody advertises. Users will save passwords in the client, and you will not stop them. So the question is where the saved password goes. Good answers: the operating system's credential store, or encryption tied to the user's login. Bad answers: a plaintext configuration file, or a lightly obfuscated one that a search engine can decode. If saving can be disabled by policy, note that too.

Northgate Retail learned this the slow way. Their store-support team chose a client for its drag-and-drop queue, and everyone saved their passwords in it. When a support laptop was replaced, its old profile was copied to a team share "for a few days" and stayed for a year. It included fourteen supplier passwords, readable by anyone with a login. Nobody had used it, as far as anyone could tell. Fourteen suppliers still got a password-rotation email that fortnight. The client was replaced the month after.

Host-Key and Certificate Prompts Written for Humans

The most important security feature of a transfer client is not its cipher list. It is what the client does when it cannot be sure it is talking to the right server. Every SSH or SFTP server has a host key, a key pair that identifies the server itself. On the first connection the client asks: "this server presents fingerprint SHA256:...; do you trust it?" Say yes and it records the key and checks it silently from then on. If the key ever changes, it warns loudly, because a changed key is what a man-in-the-middle attack looks like. Host keys and known hosts explains the mechanism. The stakes are in MITM and trust failures.

Now picture that prompt in front of someone in accounts payable. A good client shows the fingerprint clearly and says in one sentence what it is. It offers "accept once" and "accept and save" as separate choices. A bad client shows a wall of hexadecimal and a "Yes" button. I know which kind I once deployed, because within a month every user clicked Yes on reflex. They were still clicking it the day the key really did change. Look for:

• Readable fingerprints in the modern SHA-256 form, so a user can compare against one you publish.
• Pre-seeded trust. Can you ship the known host keys with the deployed configuration, so users never see the prompt for your standard servers? Deploying standard configurations shows how.
• A hard warning on a changed key that cannot be dismissed with one reflexive click, and no global "always trust" option.

For FTPS and HTTPS the equivalent is certificate validation: checking the server's certificate against a trust store, ideally the operating system's. That way, a private certificate authority you distribute once is trusted by every client on the machine. Ask whether the client uses the OS store or its own, and whether "accept any certificate" can be locked off. Self-signed certificates and private CAs covers distributing that trust.

What Users Feel: Resume, Sync, and Integrity

These are the features end users notice, and they decide whether the client gets used or worked around. Lose a two-hour upload at the ninety-minute mark and the user goes back to whatever worked last time. That is the friction problem behind making the secure path the easy path.

• Resume. When a large transfer is interrupted, can the client pick up where it left off? FTP has a REST command and SFTP can write at an offset, so the protocols allow it. The question is whether the client implements it well, including for uploads. On a poor link it is the difference between a two-hour job and a two-day one.
• Directory synchronization. Comparing a local folder with a remote one and transferring only what differs. Operators love it; it also creates the classic accident of syncing the wrong way and deleting things. A client that previews changes first earns extra points.
• Overwrite rules and timestamps. Overwrite, skip, rename, or ask when the file exists? Are remote timestamps preserved? Trivial until a downstream job sorts by modification time.
• Integrity checks. A few clients compare a checksum after transfer when the server supports it; most compare sizes, which is usually adequate. See verifying transfers end to end for what a client can and cannot promise.
• Transfer queue and parallelism. Moving several files at once is useful and is also the feature most likely to trip a server's connection limit. So a configurable cap matters to you as much as the queue does to users.

The Admin's Side of the Ledger: Scripts, Logs, and Deployment

The rest of the checklist sits entirely on your side. None of it will ever appear in a ticket. All of it decides how many tickets there are.

Scripting and batch modes

Sooner or later someone wants the client to run without a person. Graphical clients often include a scripting interface: a command language, a console, or a "generate script from this session" button. Command-line clients are scriptable by nature, through a batch mode that reads commands from a file. Either way, four things matter.

• Meaningful exit codes, so a scheduled task can tell success from failure without parsing text.
• Non-interactive authentication, keys or credentials from a store, so the script never stalls on a password prompt at two in the morning.
• Behavior when a host key is unknown. A script cannot answer a prompt. The client must run against pre-seeded trust and fail cleanly, never "auto-accept", when the key is not already known.
• Logging to a file with timestamps, so an unattended failure can be reconstructed.

The command-line side is covered in depth elsewhere. See SFTP command-line mastery for the interactive client and batch modes and heredocs for running it unattended. One Windows wrinkle: many organizations carry a tail of old batch files built around the console ftp client that ships with Windows. That client speaks plain FTP only. A command-line client that accepts the same style of script turns "rewrite every batch file" into "change one executable name". One such client, sysaxftp.exe, ships with Sysax FTP Automation. It drops into existing batch files in place of the console client while adding SFTP and FTPS. Whether that is the answer or a bridge to a proper scheduler is a question for the standard-client article.

Logging

When a user says "it doesn't work", the session log is how you find out what "it" is. A good client logs the protocol conversation at a verbosity you can raise, to a file whose location you know. Check that the log holds no passwords and that logging can be on by default in the deployed configuration.

Where the configuration lives

This decides whether you can deploy the client at all. Configuration in a plain file (INI, XML, or similar) in a predictable location can be templated and pushed to every machine. Configuration in the registry can be pushed too. Configuration in an opaque database inside the user's profile can only be created by clicking. So every "it works on my laptop" profile stays on that laptop. Also ask for a per-machine policy layer that overrides user settings such as "no plain FTP". Ask for a portable mode you can disable, because portable executables in user folders are how clients escape your inventory. The client sprawl problem counts what that costs.

Installation, updates, and proxies

A silent installer, no dialogs, all users on the machine, standard package format, is mandatory for any client you intend to standardize on. So is a clean download from the publisher. Free clients have periodically been redistributed by download sites that wrap them in unwanted software. Then ask how updates happen. A self-updating client is convenient on a laptop and a problem on a managed fleet where you test first. A client that never updates is security debt with a desktop icon. The answer you want is "either, under your control". Finally, if users sit behind an outbound proxy, the client must traverse it. Test it; proxy support is often listed and rarely exercised. The deployment article makes this a checklist.

The Scored Checklist

The whole article, as a table. Each feature carries an admin weight and a user weight from 1 (barely matters) to 5 (decisive). Copy it, and for each candidate score every row 0 (missing), 1 (partial), or 2 (solid). A candidate's total is the sum over rows of score × (admin weight + user weight). For a command-line standard, drop the user column and double the scripting row. For a graphical standard, both columns count in full.

A worked example: a candidate that scores 2 on the host-key row earns 2 × (5 + 3) = 16 points there. One that scores 1 earns 8. Across fourteen rows the totals separate quickly, on the security and deployability rows, because those carry the heaviest weights. If a candidate wins on drag-and-drop and loses on trust handling, you want the arithmetic to say so before the steering committee does.

A thirty-minute feature lab

Feature lists describe intent. A hands-on test reveals behavior. Run each candidate through this sequence against a test server you control.

1. First connection. Connect over SFTP and read the host-key prompt as a new hire would. Is the fingerprint readable? Are "once" and "always" separate? Can the key be pre-loaded so the prompt never appears?
2. Changed key. Regenerate the test server's host key and reconnect. The client must refuse or warn hard; if it connects with a mild notice, score the row 0.
3. Certificate check. Connect over explicit FTPS to a server with a self-signed certificate; the client should complain. Install your private CA root into the OS store and reconnect; if the complaint disappears, the client uses the OS store.
4. Plain FTP off. Find the setting or policy that removes plain FTP. If there is none, note it.
5. Unattended run. Script a single download and run it from a scheduled task under a different account. Check the exit code for a success and a deliberate failure.
6. The log and the install. Find the session log and confirm it holds no passwords. Then install the client silently on a clean machine and locate the configuration you will template later.

Features that look important and aren't

To keep the checklist honest, these features do not matter: protocol breadth beyond your needs and built-in editors. Each extra cloud connector is another way for data to leave. Speed claims do not matter either: throughput is set by the network and the server. And encryption adjectives like "military-grade" describe nothing the lab above does not check better. Themes are worth exactly zero points, however nice the dark one looks.

Turning the Checklist Into a Decision

The checklist tells you what to score, not how many clients to choose or for whom. That depends on the people behind the requests, the subject of GUI clients vs command-line clients: who needs what. Then choosing the organization's standard clients applies the scores inside a decision worksheet. The article on deploying standard client configurations cashes in the deployability rows. The short version: the features that matter most are the ones users never see. Those are trust handling, protocol control, credential storage, and a configuration you can push. The arithmetic is weighted to say so. The longest feature page still will not win. That is the point of the math.

Frequently Asked Questions