Skip to main content

Managing 2FA Requirements

Administrators set the 2FA requirement for people, decide which verification methods are available, and account for SSO and unattended integrations before enforcing it. A site-wide mandate, an individual user's requirement, and that user's enrolled methods are separate settings. Removing a requirement does not delete enrolled methods, and resetting methods does not remove the requirement.

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:

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.

Limiting Allowed 2FA Methods

Site Administrators can control which 2FA methods are available to users. All methods are enabled by default, which means a user can enroll in email verification even when your security policy would rule it out. If your user population can manage authenticator apps or hardware keys, disable the weaker methods instead of relying on guidance to steer people. Changing the supported 2FA methods lets a user without another supported method keep authenticating with their existing method until they complete replacement enrollment. Normal access requires that replacement; disabling a method does not leave an enrolled user with password-only sign-in.

2FA and Single Sign-on

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

If your site has a mix of SSO users and users who authenticate with a local Files.com password, and your identity provider already requires MFA, enabling the sitewide Files.com 2FA requirement prompts SSO users twice: once by the IdP and once by Files.com.

The sitewide Exempt SSO Users From Two-Factor Authentication setting removes that duplicate challenge. SSO users skip the Files.com 2FA prompt. Non-SSO users still face the sitewide requirement. The setting has no effect unless sitewide 2FA enforcement is already on. Changing it uses re-authentication to confirm the acting user's identity, subject to that control's authentication exceptions. When a parent site manages this setting, child sites cannot override it.

For per-provider control rather than a blanket exemption, use the Provision users with 2FA required? setting in each SSO provider's configuration under User Access & Security. This lets you follow the site-wide policy, always require 2FA, or never require it on a provider-by-provider basis. It applies to users provisioned through SCIM or JIT provisioning.

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.

Changes to Supported 2FA Methods

When a Site Administrator disables a previously allowed 2FA method, users who have no other supported method set up can still authenticate with their existing method to enroll a replacement. This lets them prove their identity using the method they already set up, without requiring an administrator to reset their 2FA. They must complete setup of a supported method before normal access resumes. The disabled method remains until that setup is complete; an unfinished setup does not count as a replacement.

Users who already have another supported 2FA method configured can continue signing in with that method without interruption.

When a site administrator enables an additional 2FA method, existing users are not affected. They can continue signing in with their current 2FA methods, and the newly supported method becomes available in their profile settings for optional setup.

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.

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.

Operational Considerations When Mandating 2FA

2FA is a strong security measure, and mandating it introduces 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.

Enabling the Mandate

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.

Removing a 2FA mandate has a 7-day waiting period so administrators have time to discover the pending removal before it takes effect. During this period, users covered by the mandate cannot remove their last 2FA method, and new users covered by it must still enroll at least one method.

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 emergency-access or migration scenario.
  • A single-purpose service account for legacy protocol access.
  • A shared automation credential, where the Shared/Bot user setting is the correct choice 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.

Removing Site-Level 2FA Enforcement

Site Administrators can remove the site-level 2FA requirement for all users or for Site Administrators only. A 7-day waiting period gives administrators time to discover the pending removal before it takes effect.

The existing requirement remains in force during that period for every user it covers. Those users cannot remove their last 2FA method, and new users covered by the requirement must still enroll a method.

Removing the 2FA Requirement from a User Account

Site Administrators can remove the 2FA requirement from an individual user account from the user's profile. Disabling this setting removes the requirement to use 2FA but does not delete any previously configured 2FA methods from the user's account. The user can sign in without being prompted for 2FA, and their enrolled methods remain available for future use.

Removing the requirement at the site level affects users whose 2FA setting is configured to use site-wide setting. For all other users, any custom setting explicitly configured for their account continues to apply.