We host an asset-performance dashboard on company servers. It collects data from customer equipment and presents the results in charts and dashboards. To keep the service off the open internet, our current process requires collecting each customer site's public IP address and manually adding it to a firewall ACL.
This is becoming difficult to operate because customers may have dynamic addresses, remote users, changing networks, and eventual offboarding requirements. I'm concerned that firewall allowlisting is being used as the primary access-control mechanism when authentication and authorization should probably be handled at the application or identity layer.
For a B2B application like this, is maintaining customer IP allowlists at the firewall a normal enterprise practice? What architecture would you recommend for balancing network controls, application security, customer access, and manageable onboarding and offboarding?
5 Answers
The usual modern approach is to put an identity-aware application proxy or access gateway in front of the service. It can integrate with an identity provider, enforce MFA and conditional-access policies, and control access by customer organization or individual user. That avoids asking customers to install VPN clients or constantly updating firewall rules for changing IP addresses.
If you use Microsoft identity services, an application proxy may be a good fit. Otherwise, comparable zero-trust gateways are available from other providers. The application should still enforce authorization, while the proxy, WAF, and firewall provide additional layers of defense.
Some compliance teams may still require WAF or firewall allowlists. In that case, run identity controls and network restrictions together rather than treating the IP list as the only authentication mechanism.
If customers truly need private network connectivity rather than browser access, site-to-site tunnels or customer-managed proxy nodes can work. Tunnels can reconnect when a customer's public IP changes, so they avoid manually tracking every address. However, they add operational complexity and should use narrowly scoped firewall rules and strong endpoint authentication.
For a normal web dashboard, an identity-aware proxy is generally easier to operate than requiring every customer to deploy VPN software.
A lightweight point-to-point tunnel can be appropriate for specialized integrations, but it is usually excessive for ordinary browser access.
A hosted access gateway can be a practical short-term solution. Proxy the hostname so the origin address is not publicly reachable, require authentication through a zero-trust policy, disable inappropriate caching, and use WAF protections and logging. Just verify the provider's user and policy limits before relying on a free or entry-level plan.
The long-term goal should still be proper application authentication, authorization, and lifecycle automation rather than using the gateway as a permanent substitute for those controls.
Separate the security design for data collection from the security design for dashboard access. For incoming equipment data, consider mutually authenticated TLS, signed requests, short-lived tokens, or another protocol-appropriate mechanism. For people viewing the dashboard, use an identity provider, MFA, and tenant-aware application authorization.
Another option is to place a collector or middleware service in a DMZ or cloud environment. Customer equipment sends data to that service, and the internal dashboard retrieves or receives only the necessary information. That keeps the core application away from direct customer connections.
IP allowlists are useful for reducing the attack surface, but they do not authenticate a customer. An address usually represents an entire building or network, including guest devices, contractors, and potentially compromised systems. Stale entries can also become dangerous if an ISP later reallocates an address.
Expose an application gateway or WAF instead of the application server directly, require strong identity-based authentication and authorization, and keep the backend isolated. The dashboard should independently verify user permissions and tenant boundaries.
There is some initial setup and possible customer friction, but it makes onboarding, offboarding, automation, and audit logging much easier than maintaining IPs manually.