Files.com ships with strong security defaults out of the box, with no manual configuration necessary. Strong encryption enforcement and protection against repeated failed login attempts are built in and enabled by default.

Every organization has unique security requirements, so Site Administrators have full control over these security features and can fine-tune the site settings to meet their needs.

Files.com automatically limits repeated failed login attempts. The default protection suits most organizations; its internal thresholds are not published. Refer to Compliance and Security for more details about Files.com's SOC-2 compliance and Information Security programs.

A custom policy locks users out after a specified number of failed login attempts. Repeated attempts using common usernames can therefore lock out users even when they have not tried to sign in. The custom setting is provided for the rare circumstances in which your own organization's compliance procedures require you to specify exact settings. Only enable the custom option if you require it to meet a compliance need and if your usernames are suitably obfuscated.

Files.com strongly recommends leaving this set to Use default Files.com protection. When enabling the custom setting, take care to avoid accidental user lockouts. Maintain at least one backup administrator user who can unlock another administrator in the event of an accidental lockout.

Session Settings

You can customize how often users' sessions are invalidated, requiring them to log in again. By default, your site is configured to balance security with convenience.

Session Expiration

Web interface sessions automatically expire after a period of inactivity. This setting customizes the session idle timeout. The default value is 6 hours, and the maximum is 168 hours (7 days).

App Session Lifetimes

The Desktop App and Mobile App have separate session lifetimes, measured from sign-in rather than inactivity. Their session tokens keep the apps connected without repeated login prompts and are issued even when Allow Users To Create API Keys is disabled. That setting controls credentials for users' own integrations; app session lifetimes control when users must authenticate again.

Site Administrators configure each lifetime independently under Security → Sessions. Each setting applies to users of that app across the site and saves separately. To change either value, select its Edit button, choose Days or Hours under Time Unit, enter the duration, and select Save. The duration must equal a whole number of hours. For example, 0.5 days is accepted as 12 hours, while 0.1 days is rejected because it equals 2.4 hours. Saved positive values appear in days when they divide evenly into days, and in hours otherwise.

Files.com recommends a lifetime of 30 days, or 720 hours, to balance security with uninterrupted work in the apps. If you need a shorter lifetime, allow at least three times the duration of your longest typical file transfer. This buffer helps long-running transfers complete before the session expires. If a session token expires while a transfer is in progress, the Desktop App pauses the transfer until the user signs in again.

Desktop App Session Lifetime

Desktop App Session Lifetime controls how long a Desktop App sign-in remains valid. Its default is 4,320 hours (180 days).

Setting this value to 0 makes new Desktop App sessions expire immediately. It does not change the Mobile App lifetime, and existing Desktop App sessions retain their original expiration.

Mobile App Session Lifetime

Mobile App Session Lifetime controls how long a Mobile App sign-in remains valid. Its default is 720 hours (30 days).

Setting this value to 0 makes new Mobile App sessions expire immediately. It does not change the Desktop App lifetime, and existing Mobile App sessions retain their original expiration. For either app, 0 means immediate expiration, not an unlimited session.

What Happens When the Value Changes

Changing either lifetime applies only to newly issued session tokens for that app. Existing sessions keep working until their original expiration time unless access is revoked separately.

For example, if a Site Administrator changes Mobile App Session Lifetime from 30 days to 7 days, a user who signed in 10 days before the change keeps their existing token for another 20 days. A user who signs in after the change receives a new token that expires in 7 days. Desktop App sessions are unaffected.

Disconnecting and reconnecting in the Desktop App reuses the existing token. A reconnect does not issue a new token and does not pick up the new lifetime.

Child Site Management Policies

A Parent Site Administrator can enforce either or both lifetimes through a Child Site Management Policy. On the policy details page's Security tab, use Add to Policy for each lifetime to manage, with a separate value for each. On an affected Child Site, the setting shows Managed by Parent Site Administrator and its Edit button is disabled. A lifetime not included in the policy remains under the Child Site's control. Policy changes also apply only to new sessions; they do not revoke existing app sessions.

How to Revoke Active Desktop Connections

A Site Administrator can revoke any active Desktop App connection from the Active Desktop Connections list at the site level or on each user's page under user details. Revoking a connection ends the session immediately, and the user must sign in again the next time they open the Desktop App.

To end all Desktop App sessions on the site at once, turn off Desktop App Enabled. Leave it off to prevent further Desktop App sign-ins, or turn it back on to let users establish fresh sessions. This also signs out administrators and applies across all Workspaces on the site.

Desktop Session IP Pinning

The Desktop Session IP Pinning setting ties a Desktop App session to the IP address the user signed in from. When the setting is enabled, a change to the user's IP address signs them out of the Desktop App and requires them to sign in again. Files.com disables this setting by default, and the default works for most sites.

Files.com verifies each new app sign-in independently of this setting. IP pinning adds an ongoing address restriction for compliance programs that specifically mandate it. Only enable it if an internal security or compliance program requires it.

IP addresses change for many legitimate reasons. A user who moves a laptop from the office to a home network, switches Wi-Fi networks, or connects through a VPN will see their IP address change. With Desktop Session IP Pinning enabled, each of those changes signs the user out of the Desktop App. Repeated forced sign-ins frustrate legitimate users and are a frequent source of support requests.

Files.com recommends leaving Desktop Session IP Pinning at its default of disabled.

Transfer Protocols

For compliance reasons, you may need to prevent all users from connecting with specific protocols. Files.com lets you completely disable all FTP/FTPS traffic, all SFTP traffic, or both.

Enable FTP

When this setting is enabled, users who have been granted permission to connect via FTP or FTPS will be able to connect. When this setting is disabled, no users can connect via FTP or FTPS, even if their individual user permissions grant them FTP access. FTP is enabled by default for new sites.

If your site has dedicated IPs and this setting is disabled, all of the ports used for FTP (21, 3021, 990, 3990, 40000-50000) will be entirely closed.

For sites that don't have dedicated IPs, disabling FTP access will not close any ports. Even though the ports remain active, users cannot connect via FTP or FTPS when FTP is disabled. After authenticating, the system immediately closes each FTP or FTPS connection and displays an error message.

Enable SFTP

When this setting is enabled, users who have been granted permission to connect via SFTP will be able to connect. When this setting is disabled, no users can connect via SFTP, even if their individual user permissions grant them SFTP access. SFTP is enabled by default for new sites.

If your site has dedicated IPs and this setting is disabled, port 22 will be entirely closed. For sites that don't have dedicated IPs, disabling SFTP access will not close port 22, but users will still not be able to connect via SFTP.

Enable WebDAV

WebDAV is not recommended for most organizations. The Files.com Desktop App is faster, easier to use, and more secure than WebDAV, and supports both Windows and Mac. WebDAV is enabled by default for new sites. Disable WebDAV access on your site unless your organization requires it.

When this setting is enabled, users who have been granted permission to connect via WebDAV will be able to connect. When this setting is disabled, no users can connect via WebDAV, even if their individual user permissions grant them WebDAV access.

Protocols explains why service ports can remain open and why a protocol response is separate from permission to use your site.

Desktop and Mobile App Access

Use Desktop App Enabled and Mobile App Enabled to control which apps your organization allows users to connect with. Both are enabled by default and apply across all Workspaces on the site.

In the web app, open Clients & Protocols → Desktop App → Settings or Clients & Protocols → Mobile App → Settings and change the corresponding switch. Only Site Administrators and read-only Site Administrators see these Settings tabs; read-only Site Administrators can view the settings but cannot change them.

Turning a setting off signs out all users of that app on the site, including Site Administrators, and prevents new sign-ins to that app. The other app and browser sign-in to the web app, including SSO, remain available. Turning the setting back on allows users to sign in again, but does not restore the sessions that were signed out.

A Parent Site Administrator can enforce either setting through a Child Site Management Policy. A setting controlled by a policy shows Managed by Parent Site Administrator on the Child Site and cannot be changed there.

API Key Creation

The site-wide Allow Users To Create API Keys setting controls whether users can create credentials for their own integrations. It governs creation only; disabling it does not revoke existing keys or prevent otherwise authorized management or deletion. It does not prevent Desktop or Mobile App sign-in, which is controlled by the app access settings above.

API Keys explains the relationship between this policy, the authority of an issued key, and ending its access.

Native Files.com Remote Server Access

Site Administrators can disable use of the site's API keys by native Files.com Remote Servers on other Files.com sites. This controls use of existing keys for those connections, separately from whether users may create keys.

Native connections follow the key's scope and applicable folder permissions. The issuing site's IP whitelists, country lists, user and group protocol permissions, and Global Acceleration regional connection setting do not apply to them. Disable native access if your organization's requirements cannot permit a connection outside those controls. To end access through an individual key without disabling this use for the site, revoke that key or disable the user who owns it.

Encryption Settings

Files.com lets you control the ciphers used to connect securely to your site. The defaults work for the vast majority of sites and are the setting to leave in place.

Files.com does not recommend allowing legacy insecure ciphers. The setting exists for sites with a business-critical client that cannot negotiate modern ciphers and cannot be upgraded. It applies to your whole site rather than to that one client, and it makes your site ineligible for the Files.com HIPAA BAA program.

IP Whitelisting

Files.com provides IP whitelists to limit which addresses your users can connect from. Many organizations mandate IP allow lists as part of their own security posture, so Files.com supports multiple levels of whitelists that can be defined throughout your site.

Files.com does not recommend static IP lists. They create authentication problems and work disruption for minimal security benefit, and the platform's built-in security tools prevent unauthorized access attempts more effectively than IP whitelisting.

Only use these settings if your internal security or compliance programs require it.

Site-wide IP Whitelist

Site Administrators can limit which IP addresses your users are allowed to connect from. You can enter the allowed IPs one per line, or specify a range in CIDR format, such as 192.168.1.0/27.

If you have also defined user-specific IP whitelists, users connecting from an IP address matching either whitelist can log in.

User or Group Specific IP Whitelist

You can manage IP whitelisting for individual users or groups via the IP whitelist user setting, found in the settings for an individual user or group. If you are also using a site-wide IP whitelist, users connecting from an IP address matching either whitelist can log in.

Security Settings