Two-Factor Authentication (2FA)

Two-factor authentication (2FA), often referred to as multi-factor authentication (MFA), adds a second verification step during sign-in in addition to a password. It reduces the risk of account takeover when passwords are stolen, reused, or obtained through phishing.

2FA requires two distinct forms of identification: something you know, such as a password, and something you have, such as a phone or hardware token. This additional layer of verification helps prevent unauthorized access because a stolen password alone is not sufficient to sign in. It protects sensitive data and helps organizations meet security and regulatory requirements.

In most environments, 2FA provides the greatest benefit for interactive user logins, particularly for Site Administrators and external users. Automation and integrations typically rely on API keys or SSH/SFTP keys instead of 2FA.

What 2FA Protects Against

2FA reduces the risk of account takeover when a password becomes compromised.

Passwords are commonly compromised through phishing, password reuse, credential stuffing, keylogging, or leaked password vaults. Requiring a second authentication factor significantly reduces the impact of stolen credentials because attackers cannot sign in with a password alone. This additional verification step also helps mitigate brute-force and credential-stuffing attacks.

What 2FA Does Not Solve

2FA is not a general-purpose security control for every risk. It applies only during authentication and only in login flows that support a second verification factor.

2FA does not protect against:

• A compromised endpoint, for example malware on a user’s laptop.
• A leaked API key, SSH/SFTP key, or other non-interactive credential.
• Shared accounts or shared credentials, which reduce accountability and complicate auditing.
• Session hijacking, for example stealing a valid session cookie after the user has already authenticated with 2FA.

Use 2FA for Humans, Not for System or Machine Accounts

Mandating 2FA without disrupting integrations requires separating human identities from automation identities and applying different controls to each.

System and Machine Accounts

Create dedicated accounts for automation and restrict those accounts to the minimum folders and protocols required for the workflow. Scripts, integrations, and scheduled transfers cannot respond to interactive verification prompts. For accounts used programmatically, apply the Shared/Bot user setting so the account can authenticate without interactive 2FA challenges.

Human Users

Enforce 2FA for Site Administrators and other interactive users. Password authentication and Single Sign-On support two-factor authentication and provide stronger protection for users who sign in interactively including internal and external (partner users).

Considerations for Accounts Connecting via FTP, SFTP and WebDAV

Users connecting through FTP, SFTP, or WebDAV can still authenticate with 2FA when using password authentication. During login, the user appends the 2FA code to the end of the password. This allows human users to continue using these protocols while maintaining the additional verification step.

Automation systems use non-interactive authentication methods instead of password-based 2FA. API keys or SSH/SFTP keys authenticate scripts, integrations, and system workflows without requiring an interactive challenge.

SSH/SFTP keys cannot authenticate accounts that require Files.com-managed 2FA. Site Administrators can allow SFTP connections to bypass 2FA when SSH keys are required.

When SFTP access requires additional security but Files.com 2FA cannot be used, configure the Combination of Password and SFTP/SSH Key (SFTP only) authentication method. This configuration requires users to present both a password and an SSH/SFTP key when connecting with an SFTP client. Requiring two independent credentials creates a two-factor authentication model for SFTP connections and provides stronger protection for environments with strict SFTP security requirements.

Maintain strict separation between human identities and automation identities. Use automation accounts only for automated processes and never for interactive login. Do not allow users to rely on automation accounts to bypass 2FA requirements.

Recommended account patterns: Human Users and Machine Accounts. Broader account-structure guidance: User Onboarding and Offboarding.

2FA Configuration Considerations

There are many considerations to keep in mind when configuring 2FA for your site, be sure to take this into account before configuring 2FA.

When 2FA Is Recommended

2FA is usually a good fit when a person is signing in interactively and you want stronger protection than “password only.”

Common scenarios where 2FA is recommended include:

• Site Administrators.
• Users with broad access or access to sensitive folders.
• External users (vendors, clients, trading partners), especially if they use the Password authentication method.
• Environments where users sign in from untrusted networks or unmanaged devices.

If you use SSO, it’s common to enforce MFA in your identity provider. Use Files.com 2FA for users who are not covered by your IdP policies.

Choosing a 2FA Method

Choose the strongest method your user population can realistically adopt. In general, phishing-resistant hardware keys are strongest, followed by authenticator apps, with SMS and email being weaker fallbacks.

Supported 2FA Methods has method-specific details and protocol support.

Limiting Allowed 2FA Methods

Site Administrators can control which 2FA methods are available to users. All methods are enabled by default. If the site’s security policy does not allow a specific method (for example, SMS), administrators can disable it.

2FA and Single Sign-on

If Single Sign-On (SSO) is enabled, you can still configure 2FA requirements within Files.com.

In your SSO provider configuration under User Access & Security, you can set how Files.com 2FA applies to users provisioned through that provider. You can follow the site-wide policy, always require 2FA, or never require it.

This setting applies to users provisioned through SCIM or JIT provisioning.

If your organization prefers to enforce MFA in the identity provider, configure it in your SSO platform. That MFA happens before the user reaches Files.com. You can use IdP MFA alone, or combine it with Files.com 2FA.

When switching a user’s authentication method to SSO, Site Administrators can also remove Files.com-managed 2FA in the same step. This avoids redundant prompts when the IdP already enforces MFA.

Mandating 2FA

Sites with a Power or Enterprise plan can mandate 2FA for their users. The mandate can apply to all users, or only Site Administrators.

Users flagged with the Shared/Bot user setting are exempt from 2FA mandates.

Before enabling a mandate, enroll at least one 2FA method for your own user. This prevents you from locking yourself out.

Setting Up 2FA has enrollment steps.

You can select whether to make 2FA required for All users, or Site Administrators only. Once set, the applicable users will be required to set up and verify a 2FA method upon their next login before they are able to proceed using their account.

How To Decide Whether To Mandate 2FA

If you’re unsure, start small and expand after you’ve separated human users from machine or system accounts:

• Start with Site Administrators. This protects high-impact accounts with minimal friction.
• Make sure automation accounts are modeled as machine or system accounts (not people).
• Expand to all interactive users when most access is human-driven.

If you need policy-driven enforcement, use SSO and enforce MFA and conditional access there.

Removing a 2FA mandate has a 7 day waiting period. During this period, users cannot remove their last 2FA method, and new users must still enroll at least one 2FA method.

Operational Considerations When Mandating 2FA

2FA is recommended as a strong security measure, however 2FA and mandating it can introduce friction and operational overhead. This is most noticeable when you have a mix of interactive users and machine integrations.

Common tradeoffs to plan for:

• Automation breakage: FTP/SFTP/WebDAV scripts and unattended jobs cannot reliably complete a second factor.
• Onboarding friction: users must enroll a method before they can work.
• Support overhead: lost devices and method resets create admin work.
• Exception management: if you mandate too broadly, you end up with many exemptions.

If you have many service accounts, separate human and machine/system identities before mandating 2FA broadly.

Exempting Individual Users From Mandate

Site Administrators can exempt specific users from a site-wide 2FA requirement. Treat exemptions as a deliberate risk decision, not a convenience setting.

Exemptions are reasonable when the account is truly non-interactive, for example during a short migration window or for a single-purpose legacy integration.

When Exemptions Make Sense

• A short-lived break-glass or migration scenario.
• A single-purpose service account for legacy protocol access.
• A shared automation credential, where you should use the Shared/Bot user setting instead (Shared/Bot users bypass 2FA by design).

When Exemptions Are a Security Risk

• Exempting admins, or users with broad access.
• Exempting a human user because “2FA is annoying,” instead of fixing enrollment and recovery.