Choosing the Organization's Standard Clients

"What's our standard client?" "The one everyone uses." "Which one is that?" "It's on the wiki." "The wiki page is from before the merger." That conversation, or one very like it, is how most organizations discover that they do not have a standard transfer client. They have a habit: whichever client the most people happened to install, written down by nobody. A standard has been chosen for reasons, against alternatives, by someone who then took responsibility for it. That means installing it, configuring it, documenting it, and keeping it current. A habit has none of that, which is why habits drift into the sprawl and security problems the previous article in this series describes.

This article is about making the decision properly, and only once. It covers what "standard" should mean, why you need one per client class rather than one client for everyone, and the criteria that separate candidates. It takes an honest look at licensing and maintenance for open-source and commercial options alike, and the special case of the Windows command line. It includes a decision worksheet you can fill in, and the exceptions lane that stops the standard breaking on the first genuine special case. It is part of our Client Standardization series.

What "Standard" Means, and What It Doesn't

A standard client is one the organization commits to in five specific ways. It installs it, silently and on every machine that needs it, so nobody has to go looking for a download. It configures it, so the deployed copy arrives with the right protocols, the right trust, and the right defaults. It documents it, with a guide written for this client and no other. It supports it, meaning the help desk knows its dialogs and its error messages. And it updates it, on a cadence somebody owns. Anything short of all five is a recommendation, and recommendations do not survive contact with a partner's instruction sheet.

A standard is not a ban. On the day the decision is announced, nothing is uninstalled and nobody is in trouble. What changes is that every other client becomes an exception. That is something with an owner, a reason, and a review date, or something scheduled for retirement. That distinction decides adoption. People accept "this is the one we support, and here is how to ask for something else" far more readily than "everything you use is now forbidden". The article on writing rules people follow explains why the framing decides whether a rule is obeyed or routed around. The standard slots into the organization's approved and forbidden methods as the "approved" entry for interactive transfers.

One Standard Per Class

The persona work in GUI clients vs command-line clients leads to a simple structure: not one standard client, but one standard per class.

• The graphical standard, for daily operators and anyone who browses a remote server by hand. This is the decision most people will notice, and the one this article spends the most time on.
• The command-line standard, for power users, administrators, and scripts. On most platforms this decision is nearly made for you, because the OpenSSH sftp client ships with the operating system. On Windows it has a wrinkle, covered in its own section below.
• The browser path, for the occasional uploader. This is not a client decision at all but a server one: does a server with an HTTPS web interface exist for those users? If so, the standard for that persona is "use the link".
• The automation engine, for jobs with no human. This could be a scheduler product, a scripting language with a library, or a batch-mode CLI in a scheduled task. Whichever it is, it should be a deliberate choice with the same five commitments. Unattended jobs are where plain FTP and stored passwords hide longest.

Four decisions sound like more work than one. In practice the command-line and browser decisions are quick. Making them explicitly stops power users and occasional uploaders being handed the graphical standard and going elsewhere. (They go elsewhere politely. You hear about it a year later.)

The Criteria That Decide

The feature-level scoring lives in transfer client features that actually matter. Treat that checklist as the detailed evidence behind one criterion here. At the decision level, seven criteria separate candidates, and the weights below reflect what goes wrong when each is ignored.

Two of these deserve a word. Fit to the estate is the criterion the sprawl register from the client sprawl problem feeds directly. A candidate already on half the machines starts with a real advantage. Adoption is the hardest part of any standard, and it is already done. And persona fit is deliberately separate from features. A client can have every feature and still be the wrong shape for the person using it.

An Honest Look at Licensing and Maintenance

This library is written by a commercial vendor, so it is worth saying plainly: open-source clients are legitimate organizational standards. Many well-run organizations use one. Several of the most widely deployed graphical clients on Windows are open source and have been maintained for a very long time. They provide silent installers and file-based configuration, and score well on every criterion above. If the register shows one of them already on most of your machines, the honest default is to standardize on it. In that case, spend your energy on configuration and deployment rather than on shopping.

What open source asks of you is different, not less. Check four things. First, the license terms: the common open-source licenses permit internal organizational use and redistribution within the company. But a minority of clients ship under terms that treat some uses differently, so read the actual license. Second, who maintains it: a project with several active maintainers and a steady release history is a safer bet than one person's evening work, however excellent. Third, how security fixes are announced, because you need a channel to subscribe to. "Check the website occasionally" is not an update process. Fourth, whether paid support exists for the day you need it. Some open-source clients have a commercial support option. What community support can and cannot do is treated in our Open Source vs Commercial series.

Commercial clients bring the mirror-image questions. Per-seat licensing means the standard's cost scales with headcount. A client licensed per named user behaves differently on shared workstations than one licensed per machine. Ask what the maintenance contract covers and what happens at the end of a version's support life. Ask whether the vendor publishes a silent-install and configuration guide. A commercial client with no deployment story scores no better on deployability than a hobby project. Neither model is the safe choice by default. The criteria table is the safe choice.

Bluewater Bank learned the deployability lesson at scale. They chose a commercial graphical client after a good trial, and it was a good client. Its installer had a wizard and nothing else: no silent switch, no configuration file, settings in a per-user database. Desktop engineering visited four hundred and twelve desks over nine weeks. The decision memo had scored deployability by asking the salesperson. Vendor answers to "can it be deployed silently?" are optimistic documents. Ours included; test it on a clean machine and score what you see.

The operating system's own tools deserve the same honesty. The OpenSSH sftp and scp clients ship with Windows and every Unix-like system. They are maintained with the OS and are an excellent command-line standard for SFTP. The console ftp client that also ships with Windows is plain FTP only and active mode only. It is not a candidate for anything except retirement, as our honest look at built-in FTP clients explains.

The Windows Command-Line Standard: A Special Case

On Unix-like systems the command-line decision is short: the OpenSSH client is the standard. The article SFTP command-line mastery is the manual. On Windows the same client is present and is the right standard for people. But the register almost always contains a second problem: a tail of batch files and scheduled tasks written for the console ftp client. These connect over plain FTP to partners who have long since offered SFTP or FTPS. Those scripts cannot simply be pointed at sftp.exe, because the two programs take different commands and options. The OpenSSH client speaks SFTP only, not FTPS.

There are four honest options for that tail, and the right one depends on how many scripts there are and whether they should survive at all.

1. Rewrite for the OpenSSH client's batch mode. Each script becomes an sftp -b command file, as shown in batch modes and heredocs. Clean, standard, SFTP only, and a genuine rewrite per script.
2. Rewrite in a scripting language. PowerShell with a transfer library gives you error handling and logging the console client never had. See PowerShell SFTP scripting. More work per script, more capability.
3. Swap the executable. A command-line client can accept the console client's style of script file while speaking SFTP and FTPS. That turns the migration into an executable-name change and a protocol setting. sysaxftp.exe, which ships with Sysax FTP Automation, is one such drop-in. Existing batch files keep running, now over an encrypted protocol. This is the fastest route when the tail is long and the scripts are simple.
4. Migrate the job into an automation engine. If a batch file exists only to run a scheduled transfer, the better long-term home is a scheduler with retry, logging, and credential handling built in. That is the automation persona's standard, whether it is a product or a maintained script framework.

Many organizations use option three as the bridge and option four as the destination. They swap the executable now so plain FTP stops tonight. Then they migrate jobs into the automation standard as each one comes up for maintenance. Whatever you choose, the decision belongs in the worksheet as its own row. "The CLI standard" for people and "the fate of the batch-file tail" are separate decisions that happen to share a class.

The Decision Worksheet

Here is the whole decision as one page. Fill in one worksheet per class. The scores are 0 (fails), 1 (partial), 2 (solid), multiplied by the weights from the criteria table. The example is Acme's graphical-client decision from the sprawl article, with candidates labeled rather than named because your candidates will differ.

STANDARD CLIENT DECISION WORKSHEET
Class: Graphical client                  Owner: Desktop engineering
Personas served: daily operator; power user (browsing); administrator (reproduction)
Candidates: A = open-source GUI client already on 212 machines
            B = second open-source GUI client, portable, on 31 machines
            C = commercial GUI client, evaluated on trial

Criterion                    Weight    A     B     C
Security posture               5       2     2     2
Deployability                  5       2     1     2
Supportability                 4       2     1     2
Longevity and maintenance      4       2     2     1
Licensing                      3       2     2     1
Fit to the estate              4       2     1     0
Persona fit                    4       2     2     2
Weighted total (score x weight)       58    45    43

Decision:  A
Reasons:   already the de facto standard; silent installer; file-based
           configuration we can template; policy setting removes plain FTP
Rejected:  B has no per-machine policy layer and is portable-only;
           C would force 212 people to migrate for no security gain
Conditions: pin the version; deploy configuration per the deployment
           checklist; pre-seed host keys for all standard servers first
Review:    eighteen months from adoption, or sooner on a security advisory
Approved by / date: ______________________

The bottom half is the part people skip and the part that matters most. "Rejected because" stops the same debate restarting in a year, in the same room with the same slides. "Conditions" turns the decision into work items for the deployment article. "Review" admits that the decision has a shelf life without pretending to know when it expires.

The Exceptions Lane

Every standard meets a case it does not fit, usually within the first month. A partner's server rejects the standard client's TLS behavior. A team works on a platform the standard does not run on. A workflow needs a feature the standard genuinely lacks. A legacy job cannot be migrated before its owner retires. If there is no sanctioned way to handle these, people handle them unsanctioned, and the sprawl returns with better camouflage. The exceptions lane is the sanctioned way. The same logic keeps consumer sharing tools from creeping back, as keeping shadow sharing from returning describes.

It works like this. A request names the client, the reason, the machines, and an owner. You check the reason; often the standard client does work once configured correctly, and the exception evaporates. If it stands, the exception is granted with a security baseline identical to the standard's. That means plain FTP disabled, trust checking on, credentials in protected storage, logging on, and a pinned version somebody updates. The exception gets a review date, usually a year out, and an exit condition. And it is recorded in the register, so the audit question "what can move files out of here?" still has a complete answer. The mechanics of running such a process without it becoming a bottleneck are in the exceptions process.

EXCEPTION RECORD
Client:         partner-supplied FTPS uploader
Requested by:   EDI team                      Owner: EDI team lead
Machines:       6 (listed in the register)
Reason:         partner Bluewater's server requires TLS session reuse the
                standard client mishandles; partner will not change its side
Baseline:       plain FTP disabled; certificate validation on; credentials in
                the OS store; logging on; version pinned and updated by owner
Review:         twelve months, or when the partner upgrades its server
Exit condition: standard client connects to the partner without error

What is not an exception: preference. "I like the other one better" is a request to change the standard. That is welcome through the feedback loop in supporting the standard client. But it is not a reason to run a second client on the estate. Holding that line politely and consistently is most of what keeps the standard a standard. I once held it badly and said yes to the first three people who asked nicely. By the fourth I was running a second standard with no owner.

Making the Decision Stick

The worksheet is a decision; a few further steps make it a standard. Write a short decision memo, the worksheet plus a paragraph, and get it approved by whoever owns the transfer policy. That gives the standard authority behind it. Publish the approved list: one graphical client, one command-line client, the browser path, the automation engine, and the exceptions lane. Put it on the page people will actually find. Fix a timeline in plain words: the standard is deployed over the next quarter. Non-standard clients are retired over the following two quarters. Exceptions must be requested before then. And name the review cadence, so the decision is revisited on purpose rather than by crisis.

Then stop deciding and start deploying. A standard that exists only as a memo is a wiki page, and we have established what happens to wiki pages. It becomes real when the client arrives on the desktop already configured, the subject of deploying standard client configurations. And if the standard turns out to be more steps than the habit it replaces, expect the habit to win. The article on why transfer policies get ignored explains the arithmetic.

The decision in one paragraph: choose one standard per class, not one client for everyone. Score candidates on security posture, deployability, supportability, longevity, licensing, fit to the estate, and persona fit, with the sprawl register supplying the evidence. Take open source seriously as a standard and commercial options seriously as a cost. Treat the operating system's own SFTP client as the default command-line answer. Handle the Windows batch-file tail as its own decision. Write the worksheet, including why the losers lost, and open an exceptions lane before the first special case arrives. Then deploy it, because the features that made the decision only protect anyone once the configuration is on the machine.

Frequently Asked Questions