IP whitelisting restricts incoming client connections to a specific list of pre-approved IP addresses. A connection covered by this control is blocked unless its source IP appears on an applicable allow list.

We do not recommend IP whitelisting for most customers. Most modern internet connections use dynamic addresses that change frequently, so legitimate users get locked out the moment they switch networks or move locations. The feature exists because some security and compliance regimes mandate it, not because it's the right default. For the reasons to avoid it, see IP Whitelisting is Not Universally Recommended below.

When you do enable it, Files.com lets you limit the IP addresses that can access your site. For example, you can configure it so that connectivity is only allowed from your corporate network, limiting access to employees who are physically at your corporate office or connected to your corporate office via VPN. Remote, external, and mobile employees would not be able to connect.

Enabling this feature blocks those client connections from IP addresses that are not on an applicable whitelist.

You can restrict access by IP address at a variety of levels: site-wide, for a specific partner, at the group level, and for individual users.

When another Files.com site uses one of your API keys for a native Files.com Remote Server, none of these IP whitelists apply to that connection. Its access follows the key and applicable folder permissions. Use the site's control for disabling native Remote Server access if your organization requires every such connection to be subject to an IP whitelist.

This is an optional feature provided for compliance with your company security posture. It is not required, and we do not recommend it as a default configuration.

IP Whitelisting is Not Universally Recommended

IP whitelisting looks like a straightforward way to control access, but it introduces operational challenges that often outweigh the benefits. The feature is designed to restrict access, not grant it, and we recommend enabling it only when your security office or a compliance regulation explicitly requires it.

Enabling an IP whitelist without fully understanding the implications leads to access issues and support overhead. Business processes that rely on external connectivity with vendors, suppliers, partners, or customers break when any of those external parties changes premises, updates their network, or changes internet service providers.

IP whitelisting is a frequent source of connectivity failures. Many organizations have dynamic or cloud-based IPs that change periodically, which makes a previously approved IP obsolete without notice. The result is unexpected disruptions and users who suddenly cannot connect. Mobile users, remote employees, and third-party vendors often access services from multiple locations, which makes it impractical to maintain an accurate whitelist.

From a security perspective, IP whitelisting is an outdated practice. Modern security models rely on identity-based authentication, encryption, and network-level controls that provide stronger protection without the operational overhead. Over-reliance on whitelisting creates a false sense of security while complicating legitimate access.

If your site does not already have an IP whitelist in place, adding one will not resolve connectivity issues. Updating the whitelist only has an impact if access has already been restricted.

Before enabling IP whitelisting, evaluate whether it is actually necessary. In most cases, other security mechanisms provide better protection with far fewer operational challenges.

How IP Whitelists Apply to Users, Groups, and Partners

In addition to your site's IP whitelist, you can create more targeted lists that apply only to specific users, groups, or partners. A user can connect if their IP appears on any applicable list, whether site-wide, group, user, or partner.

User-level and group-level IP whitelists apply only to their users and groups.

Partner-level IP whitelists apply to all of that partner's users. Partner users can have IP lists on their user account that apply only to that particular partner user. Partner users cannot be members of groups, so group-level IP lists never apply to a partner user.

When There is No Site-Wide IP Whitelist

When no list exists for the site, the user, any of their groups, or (for partner users) their partner, a user can connect from any IP address without restriction.

When a specific IP whitelist exists for the user (or their group or partner), that user must access the site from one of the addresses on that whitelist.

Bypassing the Site-Wide IP Whitelist

By default, your site's Allow User Overrides for Allowed IPs setting is enabled. While it is enabled, Site Administrators can configure user-level IP whitelists and Bypass Site IP Whitelist for any user on the site. Workspace Administrators can do the same for users within the Workspaces they administer, including Workspace Administrator accounts.

Site Administrators control Allow User Overrides for Allowed IPs. Disabling it prevents user-level IP whitelists and Bypass Site IP Whitelist overrides from being set and makes Files.com ignore them for every user, including Site Administrators and Workspace Administrators. Site-wide, group-level, and partner-level IP whitelists continue to apply.

Before disabling the setting, clear existing user-level IP whitelists and turn off Bypass Site IP Whitelist for users who have it enabled. Files.com refuses the change while any of those user overrides remain configured.

With user overrides enabled, when a user account is configured to bypass the site IP whitelist, the site-wide list no longer applies to that user, even if one exists. When an IP whitelist exists at the user, group, or partner level, the user can only connect from an IP address on that matching list.

If no such list exists for a user configured to bypass the site IP whitelist, the user can connect from any IP address.

Interaction With Other Restrictions

If you maintain a list of Allowed Countries or Disallowed Countries, the IP whitelist and country restrictions combine so that a given connection must satisfy all restrictions to be allowed. For example, IP addresses associated with countries on your Disallowed Countries list cannot connect, even if those IPs would otherwise be allowed by your IP whitelists.

Public Hosting

Folders configured with the Public Hosting (Web Hosting) setting are not affected by IP whitelisting. Public folders are accessible from any location and any IP address.

IPv6

Files.com does not support IPv6 addresses for any part of its platform, including IP Whitelisting.

Enabling IP Whitelisting For All Users

To add IP addresses to the site-wide IP whitelist, type "IP Whitelist/Blacklist" in the search box at the top of every page and then click the matching result. Enter each whitelisted IP address on a separate line. You can specify a range in CIDR format, such as 192.168.1.0/27.

For client connections covered by IP whitelisting, adding one or more IP addresses to the site-wide whitelist requires users to connect from an applicable whitelisted address unless user overrides are allowed and they have the Bypass Site IP Whitelist setting enabled. User, group, and Partner lists can also allow addresses, as described above.

The site-wide whitelist applies to Site Administrators as well, so a list that omits your own address locks you out of your own site. Confirm your current IP address before you save the list, and keep one or two backup Site Administrator accounts as a precaution.

Disabling IP Whitelisting

To disable IP whitelisting, clear all content from the site-wide and per-user, per-group, or per-partner IP whitelists.

Logging

Files.com logs all login attempts made to the site by users or systems. Login attempts blocked by IP address restrictions configured by a Site Administrator do not appear in the user's activity logs or the site-wide History logs. These blocked attempts are captured in the API logs, where they are recorded with a 401 status code and an error type of not-authenticated/locked-out for administrators to review.