Authentication Methods
A Files.com account can use different credentials for browser sign-in, apps, and automated connections. The checks depend on the credential presented, not just the account's configured sign-in method. This distinction matters when assessing whether a two-factor authentication requirement covers a particular connection.
Accounts, Credentials, and Permission
The account identifies the user and their assigned access. A credential proves that a connection may act as that account, or as the site for a site-wide API key. A session lets that authenticated connection continue. Understanding which of these you are configuring prevents a sign-in policy from being mistaken for a rule about every later request.
Two-factor authentication is especially important at interactive sign-in, when a person can supply a second proof. Dedicated keys support unattended transfers without an interactive challenge on each request. Those keys need their own scope and lifecycle rather than relying on the password policy to control them.
Sign-In and Later Connections
| Connection method | Authentication check | Where the second factor applies |
|---|---|---|
| Browser or API sign-in with a Files.com password | Files.com verifies the password and the account's applicable sign-in requirements. | Files.com checks the enrolled second factor when required. |
| Browser-based Single Sign-On | The identity provider authenticates the person; Files.com matches that identity to the configured account. | The provider applies its own requirements. Files.com applies its 2FA requirements unless the user is exempt. |
| Desktop or Mobile App | Browser sign-in establishes a dedicated app credential for later connections. | Required verification occurs during sign-in, rather than before every file operation. |
| Sign In with Files.com for Remote MCP | Browser sign-in and client approval establish a Files.com login session. | Applicable sign-in checks occur in the browser. Later operations use the session without repeating the second factor for each request. |
| API key, including a key used with FTP, SFTP, or WebDAV | Files.com verifies the key and its permitted access. | The key authenticates independently of password or browser-based 2FA. |
| Password over FTP, SFTP, or WebDAV | Files.com verifies the password and any applicable protocol authentication requirements. | When Files.com 2FA is required, a supported code accompanies the password unless the connection is exempt. |
| SSH key over SFTP | Files.com verifies the registered key. The password-and-key authentication method also requires the password. | Hardware verification on a supported SSH key is separate from Files.com-managed 2FA. |
The authentication method controls password and SSO sign-in. It does not revoke separately issued API or SSH keys. An SSO user can therefore have protocol access through a key without repeating the browser sign-in. LDAP and Active Directory can also authenticate passwords for supported protocols; other browser-based SSO providers require a separate credential for those connections.
For SAML sign-in, the provider's trust and audience configuration determines which identity-provider responses it accepts. This matters when one identity provider serves several Files.com sites: choosing a site through Relay State is separate from validating the assertion for that site's provider.
Two-Factor Requirements
Changing the site's allowed 2FA methods does not leave an enrolled user signing in with a password alone. Enabling another method leaves existing enrollments unchanged. When a method is disabled, users with another supported method already set up can use it. Users without one continue authenticating with their existing method to enroll a replacement before normal access resumes. Files.com removes the disabled method only after a supported method's setup is complete; starting setup does not count as a replacement.
For sites using an identity provider's MFA, SSO exemptions prevent duplicate Files.com prompts. The exemption concerns the Files.com challenge; the identity provider still controls its own authentication requirements.
A hardware-backed SSH key can require physical interaction before the private key is used. This does not enroll the account in Files.com 2FA or satisfy a Files.com-managed 2FA requirement. Key-only SFTP access for an account with that requirement needs the appropriate protocol exception.
Access After Authentication
Authentication establishes which account or key is connecting. It does not add permissions. User credentials remain subject to the user's access; site-wide API keys have their own site and Workspace scope. API key permission scopes can further limit what a connection can do. Protocol and network checks depend on the connection method, as described below.
Selected account and credential changes also use re-authentication to confirm the acting user's identity again. That confirmation applies to the individual request and does not expand the user's permissions.
A temporary Agent transfer URL instead authorizes a specific file operation; it does not establish general account access.
The app sign-in checks govern how a new app connection is established. Credential and session revocation governs whether established access can continue.
Network & Protocol Access explains the additional connection requirements, including protocol availability, IP whitelists, country restrictions, and the separate controls for native Files.com connections.
API and Web Interface Availability
The Files.com API intentionally exposes functionality that the web interface does not. It supports programmatic work and integrations, while the web interface presents controls for interactive use. A capability does not need a corresponding button or screen to be supported. Authorization is enforced by the service for the operation and credential involved; the absence of a control in the web interface is not a permission restriction. API Keys explains the credentials and access controls for independent integrations.