Which URLs must be allowed on a firewall to use the new Microsoft Purview portal fully privately (private endpoints only)?

Q1 — Is Platform alone really sufficient?

For the new Microsoft Purview portal (purview.microsoft.com), yes: the current Microsoft documentation identifies Platform and Ingestion as the supported private endpoint types.

The Platform private endpoint is the one used for client access to the new Purview portal. The Ingestion endpoint is required for private scanning/data ingestion scenarios.

The portal private endpoint belongs to the classic Purview governance portal (web.purview.azure.com). Microsoft also documents different private DNS zones for them:

New portal / Platform: privatelink.purview-service.microsoft.com Classic portal / Portal: privatelink.purviewstudio.azure.com

So based on the current documentation, I would not consider the portal private endpoint a requirement for purview.microsoft.com. Microsoft Learn

The fact that the portal loads with only Platform but then returns:

Failed to load permissions AxiosError: Network Error

suggests that I would first check DNS resolution and the actual failed HTTP request, rather than assume the missing component is the classic Portal private endpoint.

From a client using the private connection, Microsoft suggests validating:

nslookup <tenant-object-id>-api.purview-service.microsoft.com

That name should resolve to the private IP of the Platform private endpoint. Microsoft Learn

Also keep in mind that Private Link covers the supported Purview service path, but it does not make every dependency used by the browser private. Microsoft explicitly notes that environments blocking all public outbound traffic still need connectivity for Microsoft Entra ID and other required dependencies. Microsoft Learn

Q2 — Which FQDNs must be allowed on the firewall?

I couldn't find a Microsoft document that provides one fixed, Purview-only list containing every FQDN used by the new portal.

Microsoft maintains those dependencies through the broader Microsoft 365 endpoint list.

For example, the current Microsoft 365 documentation lists:

purview.microsoft.com

as a Required Security/Compliance endpoint over TCP 443. It also lists Microsoft Entra authentication endpoints and several Microsoft 365 common dependencies used by the browser.

So I would not build a permanent allowlist only from FQDNs seen in one browser session. Microsoft updates the published endpoint list over time, so the firewall rules should be based on the Microsoft-published endpoint information relevant to Purview, Microsoft Entra authentication and the Microsoft 365 web dependencies you actually require.

In other words, you can still keep the Purview API/service traffic on Private Link, while allowing the minimum required outbound HTTPS traffic for authentication and browser dependencies.

Q3 — What exactly is res.cdn.office.net?

Microsoft doesn't appear to document res.cdn.office.net individually with a Purview-specific description, but it falls under the officially published: *.office.net endpoint family.

Microsoft currently classifies *.office.net as Required for Microsoft 365, using TCP 443/80 and UDP 443. Microsoft Learn

Based on what you observed, that endpoint is being used to retrieve web resources required by the portal UI. That would explain why Purview itself remains reachable while the account card and some icons stop rendering when res.cdn.office.net is blocked.

I would therefore treat it as a browser/UI dependency, not as the Purview private service endpoint itself.

The important distinction is:

`Purview service/API traffic → Platform/Ingestion Private Endpoints

Browser authentication/UI dependencies → required Microsoft Entra / Microsoft 365 endpoints`

If adding the classic portal private endpoint is currently making the error disappear, I would capture the failed request in the browser Network tab before keeping that endpoint in the design. Based on Microsoft's current documentation, the new portal should use the Platform private endpoint.

If you can share the URL of the request behind the AxiosError (with tenant-specific information removed), that should make it possible to identify whether the remaining issue is private DNS or a blocked outbound dependency.

References

Private endpoints for data governance solutions https://learn.microsoft.com/en-us/purview/data-governance-private-endpoints

Configure and verify DNS Name Resolution for Microsoft Purview private endpoints https://learn.microsoft.com/en-us/purview/data-gov-classic-private-link-name-resolution

Microsoft 365 URLs and IP address ranges https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide