A lot of organizations think they've locked down the Microsoft Store. They've applied the Turn off the Store application policy, done a quick validation, and moved on. The Store opens with a blocked message. Job done.

‍

Except it isn't.

‍

What that policy actually does is exactly what it says: it turns off the local Store app. It does nothing to stop a user from opening a browser, navigating to apps.microsoft.com, and downloading an application directly to their machine using the Microsoft Store Web Installer. No Store app required.

‍

Most gaps in endpoint security aren't configuration failures. They're assumption failures. Someone assumed a policy was broader than it actually was.

‍

This is one of those gaps. And in enterprise environments with compliance requirements, software governance policies, or tightly controlled deployment pipelines, it matters. Here's how to close it using Entra Internet Access.

‍

What the Microsoft Store Web Installer Actually Does

‍

The Microsoft Store Web Installer is a standalone installer that lets users download and install Store apps from the web without ever opening the Store application. It creates a stub .exe installer that executes locally. It was designed as a legitimate distribution mechanism for custom and in-house apps. For developers, it's genuinely useful.

‍

For IT teams trying to enforce app governance, it's a gap. Every existing policy targets the local Store app. None of them reach the browser-based download flow at apps.microsoft.com. The fix is straightforward: block the URL that the Web Installer depends on. That URL is get.microsoft.com. Block it at the network layer, and the download never completes.

‍

IMPORTANT NOTE: This approach addresses the specific Web Installer behavior. If you need to govern app installation broadly, look at Application Control. These are complementary layers, not substitutes for each other.

‍

The Three-Step Configuration in Entra Internet Access

‍

Entra Internet Access handles this through a layered model: a web content filtering policy, a security profile, and a Conditional Access policy. Each layer does a specific job. Here's how to set them up.

‍

Step 1: Create the Web Content Filtering Policy

‍

The filtering policy is where you define what gets blocked. In this case, you're targeting a single FQDN.

‍

1. Open the Microsoft Entra admin center and navigate to Global Secure Access > Secure > Web content filtering policies.

‍

2. Click Create policy. On the Basics page, give it a clear name and set the action to Block.

‍

3. On the Policy Rules page, add a rule with destination type set to FQDN and the destination set to get.microsoft.com.

‍

4 Review and create the policy. If you already have a filtering policy in place, you can add this rule to it instead.

‍

Step 2: Create the Security Profile

‍

A security profile groups one or more filtering policies and sets their priority. This is what gets linked to your Conditional Access policy.

‍

1. Navigate to Global Secure Access > Secure > Security profiles and click Create policy.

‍

2. On the Basics page, set the state to Enabled and assign a priority. Priority 100 works well if this is a net-new profile.

‍

3. On the Link policies page, link the filtering policy you just created. Set the state to On.

‍

4. Review and create the profile.

‍

Step 3: Create the Conditional Access Policy

‍

The Conditional Access policy is the delivery mechanism. It connects user context to the security profile and determines who gets this control applied.

‍

1. Navigate to Entra ID > Conditional Access and click Create new policy.

‍

2. Under Assignments, target the appropriate users or groups. Set Targeted resources to All internet resources with Global Secure Access. Apply any network or condition filters relevant to your environment.

‍

3. Under Session controls, check Use Global Secure Access security profile and select the profile you created.

‍

4. Set the policy to On and create it.

‍

What Users Experience

‍

Once this is in place, the behavior is clean and predictable. A user navigates to apps.microsoft.com, finds an app, and clicks download. The Global Secure Access client intercepts traffic to get.microsoft.com and blocks it. The download does not complete. The local Store app opens instead, where the Turn off the Store application policy delivers its own blocked message.

‍

Two layers. One clear outcome. No silent bypass.

‍

Why This Matters in Governed Environments

‍

In financial services, government, and regulated industries, app installation controls aren't optional. They're part of your compliance posture, your change management process, and your endpoint integrity story. A policy that blocks the Store app but leaves the web installer open is a half-measure, and half-measures tend to show up in audit findings.

‍

The good news is that the fix is simple once you know where the gap is. Entra Internet Access gives you the URL-level control you need, and it integrates cleanly with the Conditional Access policies you're likely already managing.

‍

This is exactly the kind of nuance we navigate with clients every day in our Modern Workspace practice. The technology exists to do this right. The challenge is knowing which layer does what, and making sure nothing falls through the gap between them.

‍

Relevant to Your Environment? 

‍

If your organization is deploying or maturing its Entra Internet Access configuration, this control should be part of your baseline hardening checklist alongside existing Store policies and Application Control.

‍

BITSUMMIT's Modern Workspace practice helps enterprise organizations close gaps like this one before they become audit findings.