Authenticating With 2FA via FTP, SFTP, or WebDAV

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, and each code is valid for one connection at a time.

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.

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 stores a dedicated API key for the session. 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 leave transfer parallelism available, which 2FA over FTP, SFTP, and WebDAV rules out.

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.

Disable parallelism in your client. Each code authenticates one connection, so a client opening several at once will fail on all but the first. Elsewhere we recommend maximizing parallelism for throughput, and this is the case where that is unavailable.

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.