Windows Store Whitelist: Allowing App Downloads Through Your Firewall

If Windows 10/11 machines behind a corporate web security or proxy platform can browse the Microsoft Store and see apps, but installs fail as soon as they click Install, the store’s own connection is getting through while the actual app download traffic is being blocked separately.

The Original Fix (Legacy List)

This site originally recommended adding the following Microsoft domains to your web security platform’s whitelist:

download.windowsupdate.com
windowsupdate.microsoft.com
update.microsoft.com
download.microsoft.com
ntservicepack.microsoft.com
wustat.windows.com
c.microsoft.com
watson.microsoft.com
login.live.com
login.windows.net
account.live.com
clientconfig.passport.net
windowsphone.com
*.wns.windows.com
*.microsoft.com
www.msftncsi.com
www.msftconnecttest.com/connecttest.txt

Two entries in that original list are now dead weight: windowsphone.com relates to the Windows Phone platform, discontinued years ago, and doesn’t appear in any current Microsoft Store documentation. login.windows.net is a legacy Azure AD v1 endpoint that’s been superseded — current identity traffic for Store sign-in goes through login.microsoftonline.com and login.live.com instead. If you inherited a firewall rule set built from the list above, it will still mostly work (since *.microsoft.com is broad), but it’s worth tightening up against the current list below rather than carrying two dead entries forward indefinitely.

The Current Microsoft-Documented Endpoint List

Microsoft’s old dedicated “Store for Business prerequisites” page has since been retired; current guidance is split across the Intune network endpoints documentation and the Windows 11 connection endpoints documentation. As of 2026, the endpoints Microsoft documents for Microsoft Store connectivity are:

displaycatalog.mp.microsoft.com
purchase.md.mp.microsoft.com
licensing.mp.microsoft.com
storeedgefd.dsx.mp.microsoft.com
cdn.storeedgefd.dsx.mp.microsoft.com
livetileedge.dsx.mp.microsoft.com
storecatalogrevocation.storequality.microsoft.com
manage.devcenter.microsoft.com
*.wns.windows.com
*.notify.windows.com
*.do.dsp.mp.microsoft.com
*.dl.delivery.mp.microsoft.com
*.delivery.mp.microsoft.com
*.windowsupdate.com
*.update.microsoft.com
login.microsoftonline.com
login.live.com

A couple of practical notes: the Store API endpoints (displaycatalog, purchase, licensing, storeedgefd) explicitly do not support SSL/TLS inspection — if your web security platform intercepts and re-signs HTTPS traffic, these need to bypass that inspection entirely rather than just be allow-listed, or installs will still fail with certificate errors even once the domains themselves are reachable. The *.wns.windows.com and *.notify.windows.com endpoints handle push notifications, which also cover live tile and app update notifications, so it’s worth keeping those in place even if your main concern is just getting installs working. After adding the current endpoints, reboot the affected machines and retry the Store install — app downloads should now complete rather than failing partway through. If you’re managing a fleet through a centrally-managed proxy, this whitelist is worth adding as a standing exception rather than a one-off fix, since it also covers general Windows Update and activation traffic beyond just Store downloads.

Resources

• Microsoft
• guide