Firewall/Proxy allow-list for onboarding devices and Microsoft Purview

To ensure Microsoft Purview operates smoothly in your environment, you must allow traffic through your firewall or proxy, enabling client devices to communicate with the service. The good news is that most of the communication relies on standard HTTPS over port 443, so you don’t need to open up unusual ports. The key is to ensure that the right domains and service tags are whitelisted, so your clients and onboarding process can reach Purview without being blocked.

At a minimum, you’ll need to allow connections to your Purview account endpoint (for example, youraccount.purview.azure.com) and the general Purview service addresses like *.frontend.clouddatahub.net. You also need to permit access to Azure Active Directory login endpoints, such as login.microsoftonline.com, since that’s how user authentication happens. If your Purview setup uses managed storage, you should also allow the related blob and queue endpoints. To keep things simple, Microsoft recommends using service tags like AzureCloud or Storage rather than individual IPs, because those IP ranges change frequently and service tags are automatically updated.

If your organization uses private endpoints, the setup changes slightly. Instead of public Purview URLs, you’ll need to allow traffic to the private link DNS zones, such as privatelink.purview.azure.com. That ensures devices and self-hosted integration runtimes can still reach Purview through secure internal routes. Either way, the rule of thumb is to allow HTTPS traffic to Purview, Azure AD, and any associated storage accounts. This provides client devices with a clear path for onboarding, labeling, and data governance tasks, eliminating the 403 errors you’ve encountered.