What’s the issue?
SQL Server instances bind to one or more IP addresses on their host, configured through SQL Server Configuration Manager under the IP Addresses tab of the TCP/IP protocol properties. The IP addresses determine which network interfaces the instance listens on and where clients can connect. Each address can be configured separately for which port to use and whether the address is enabled.This finding reports the IP address or addresses currently in use by the SQL Server instance. It is not an issue in itself, but the address is worth recording and reviewing because several operational and security considerations depend on it.
Why is this a problem?
The most important security concern is whether the instance is reachable from untrusted networks. A SQL Server instance with a publicly accessible IP address is exposed to the entire internet, which means it is constantly subject to port scans, brute-force authentication attempts, and exploitation attempts targeting any known vulnerability. Public exposure of SQL Server is rarely appropriate and is one of the most common contributors to compromise.Even on private networks, the IP address determines which segments of the network can reach the instance. Network segmentation and firewall rules should restrict inbound access to only the specific source addresses that legitimately need to connect, rather than allowing any host on the network to attempt connections. The configured IP addresses are the starting point for understanding the actual exposure.
Disaster recovery planning also depends on knowing the IP addresses involved. Connection strings, application configuration, DNS records, and firewall rules all reference specific addresses, and recovering an instance to a new host typically requires updating these references. Documentation that captures the addresses in use, the DNS names that resolve to them, and the dependencies that reference them is essential for reliable recovery.
What should you do about this?
No remediation is required if the configured IP addresses are appropriate for the intended use and properly protected by network controls. Confirm the current configuration in SQL Server Configuration Manager and capture the addresses for documentation.Verify that public-facing addresses, if any, are intentional and protected by appropriate controls. SQL Server should generally not be directly exposed to the internet. If public access is required for a specific use case, layer additional protections including IP allowlisting at the firewall, encryption in transit, strong authentication, and active monitoring for suspicious activity. Consider whether a more secure alternative such as a VPN, private endpoint, or jump host can replace direct public exposure.
Confirm that firewall rules at both the host level (Windows Firewall) and the network level allow only the source addresses that legitimately need to reach the SQL Server port. Default-allow rules and rules with broad source ranges should be tightened to specific application servers, jump hosts, and administrative workstations as appropriate for your environment.
Document the IP addresses, the DNS names that resolve to them, and the firewall rules that protect them, as part of the standard documentation for each instance. Include cluster and listener addresses for high availability configurations, and record the dependencies (applications, scheduled jobs, integrations) that connect through each address. This documentation is invaluable during outages, recovery exercises, and migrations.