2FA and File Transfer Clients

Files.com accepts a 2FA code appended to your password when you connect over FTP, SFTP, or WebDAV. It works, but it is rarely the right choice. These protocols have no way to prompt for a second factor, so the code has to travel inside the password field.

Whether to use 2FA with these protocol-based transfers depends on whether a person or a machine is connecting. For a machine, the answer is to use key-based authentication instead because a machine can't easily supply a second factor during authentication. When a person is connecting, 2FA is more appropriate, but using the Files.com Desktop App or CLI App rather than FTP, SFTP, or WebDAV will offer the best experience.

Enabling 2FA for Existing FTP/SFTP/DAV Users

Once 2FA is required, either site-wide or for their account, a user who authenticates with a password or an SFTP/SSH key cannot connect over FTP, SFTP, or WebDAV until they log into the Files.com web app and set up a 2FA method. Enabling the bypass for these protocols does not avoid that, because the per-user bypass option is only selectable during that same setup.

Users who authenticate with an API key are unaffected, because those logins never involve 2FA.

Plan for this before turning on a mandate. Move the affected accounts to API keys, exempt them from the mandate, or expect every password and key user to need a web login before their transfers resume.

Authenticate Automation With a Key

Scripts, integrations, and scheduled transfers cannot answer a verification prompt, so 2FA does not belong on these accounts at all. Authenticate them with an SFTP/SSH key for SFTP, or with an API key for FTP, SFTP, or WebDAV.

To use an API key, set the login name to @api- followed by either the key's ID or the key's name, for example @api-5373469 or @api-botsync, and use the API key itself as the password. The value after @api- identifies the key, not the user who owns it.

Keep machine accounts separate from the people who sign in interactively, and apply the Shared/Bot user setting so the account authenticates without an interactive challenge.

Move Human Users to the Desktop App or the CLI

A person who needs 2FA and needs file transfer is better served by a client built to handle both.

The Files.com Desktop App signs in the same way as the web interface, including your 2FA method, then keeps an app session governed by the site's Desktop App Session Lifetime. The CLI App prompts for the second factor once after your password and keeps you logged in until you log out or the session expires.

Both answer the second factor once, at login, instead of on every connection. Both offer improved transfer speeds because they transfer even a single file over parallel connections.

When a Third-Party SFTP Client Is Required

Some connections cannot move to a Files.com client. A trading partner's IT policy may mandate a particular SFTP application, or an established workflow may be built around one. Two options give you a second factor without appending codes.

An ed25519-sk or ecdsa-sk SSH key enforces the second factor at the key itself, using a hardware token the user touches before the private key will work. Files.com never sees that exchange, so the account does not show as 2FA Enabled, and the protection is real.

The Combination of Password and SFTP/SSH Key (SFTP only) authentication method requires both a password and an SSH key on every SFTP connection. Two independent credentials are not the same as a changing second factor, so this is a two-factor model rather than true 2FA, but it satisfies policies that call for a key and a password together.

If neither fits, bypass 2FA for FTP, SFTP, and WebDAV on those accounts and keep the 2FA mandate for web and API access, where it works properly.

Appending a Code to Your Password

When none of the above applies, a user with a supported 2FA method authenticates by typing their password and then the current 2FA code, with no separator, into the password field. With a Yubikey in native mode, insert the key and press its button immediately after typing the password, and it enters the code itself.

Only three methods work this way: Yubikey native, authenticator apps, and SMS. Yubikey WebAuthn, other FIDO hardware keys, and email verification cannot be used over these protocols at all.

Do not choose SMS for an account that connects this way. Files.com sends an SMS code in response to a web sign-in, not an SFTP connection, so the user has to start a login in the web interface every time they want to connect with a file transfer client. Use an authenticator app instead.

File transfer clients routinely open several connections at once, and these protocols cannot ask for a new code on each one. Once your password and code authenticate a connection, Files.com accepts the same password and code for more connections over the same protocol, from the same source IP address, to the same Files.com server address. That holds until the session from the first sign-in ends under your site's Session Expiration setting.

A connection from any other IP address cannot use a code that has already been used. Someone who sees your code after you connect cannot use it to sign in from their own address.

Files.com hostnames resolve to several server addresses. A connection that reaches a different server needs a new code.

Hardware-Backed SSH Keys

The ecdsa-sk and ed25519-sk SSH/SFTP key types enforce a second authentication factor at the key itself, using a FIDO/U2F hardware token such as a YubiKey. When a user connects over SFTP with one of these keys, their SSH client prompts them to physically interact with the hardware token before the private key can be used. This is supported by Files.com but controlled entirely by the user's hardware. Because Files.com has no visibility into this second factor, a user with one of these key types will not show as 2FA Enabled in their settings, the 2FA is on the key, not the account.

This approach suits organizations that require 2FA on SFTP connections for human users and need it enforced at the key level rather than at login. It works when the SFTP client does not support appending a one-time code to the password, or when a hardware-enforced second factor is required by policy.

2FA for SSH/SFTP Keys cannot be implemented with other key types.

An SSH/SFTP key used on its own does not satisfy Files.com's account-level 2FA requirement. For supported password-based SFTP logins, Files.com reads the one-time code appended to the password; a key-only login does not send that value. To use key-only authentication on an account that requires 2FA, configure 2FA to be bypassed for SFTP connections.

Support for ecdsa-sk and ed25519-sk type keys is intended for human users and never for automated processes or scripts. These keys are designed for the 2nd factor of authentication to be provided interactively by a human user.

Bypassing 2FA for FTP, SFTP, and WebDAV

Site Administrators can allow FTP, SFTP, and WebDAV connections to skip the second factor while 2FA still applies to the web interface and the API. When this is enabled, affected user profiles gain an option to bypass 2FA for those protocols as part of configuring a 2FA method.

Bypassing 2FA on the protocols that cannot prompt for it is not the same as abandoning 2FA for the account. The account still gets challenged on the web interface and the API, so knowing the password alone does not grant access through those interfaces. That makes this a reasonable configuration rather than a last resort.

An account that authenticates with an SFTP/SSH key needs the bypass, because SFTP/SSH keys cannot authenticate an account that requires Files.com-managed 2FA. A counterparty locked to a third-party SFTP client may also have no workable second factor for that connection, and the bypass plus a strong credential beats a 2FA mandate they cannot satisfy.

Use a key rather than a password on any account you bypass. Removing the second factor leaves one credential protecting the connection, and an API key or SFTP/SSH key is far stronger than a password.

Enabling the Bypass

The site-wide setting has to be enabled before a user configures their 2FA method, because the per-user option only appears during that setup. Users cannot edit a 2FA method after the fact, so for an account that has already enrolled, an Administrator resets the user's 2FA and the user sets it up again.

Enable the sitewide setting before you turn on a 2FA mandate, so the bypass option is available the first time each user configures 2FA. If the mandate goes first, those users enroll without it, and an Administrator has to reset each one so they can enroll again.

Enabling it early does not spare anyone the setup itself. A user who authenticates with a password or an SFTP/SSH key still cannot connect over these protocols until they finish configuring 2FA in the web app. To avoid interrupting protocol transfers at all, move those accounts to API keys or exempt them from the mandate first.