Authentication Checks by Connection Method
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.
Two-Factor Requirements
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 and the applicable protocol and IP restrictions; site-wide API keys have their own site and Workspace scope. API key permission scopes can further limit what a connection can do.
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.
The app sign-in checks govern how a new app connection is established. Credential and session revocation governs whether established access can continue.
Protocol and Network Controls
An enabled protocol is another prerequisite for a connection; having a valid credential does not enable a protocol that the site has disabled. Site protocol settings and the user's protocol privileges let you keep unused connection methods unavailable. An open shared service port alone does not establish that your site's users can authenticate through it.
IP whitelists apply to the source address Files.com observes. An address on any applicable site, user, group, or Partner list can satisfy the whitelist; the lists do not form a series of increasingly narrow requirements. Country restrictions, when configured, are separate checks that must also pass. Files.com does not recommend adding static IP restrictions unless your organization requires them, because changing networks, proxies, and service addresses can interrupt legitimate work.
Network location is not a person's identity. Several devices can share one public address, and one device can use several addresses over time. Use the account and credential model to establish who is connecting, and use network restrictions only for the additional connection requirement they actually enforce.