Skip to main content
MDM is the delivery layer. It cannot see prompt content — no MDM can — but without an enforced install policy, only the willing employees end up protected. That is the same gap every BYOD security tool faces, and it is the gap MDM closes.
Cross-referencing MDM device IDs against client check-ins and Entra ID identities is what lets the console tell you which machines are covered and which are not.

​
Provider status

The force-install policies below work today on any of these platforms, whether or not the console-side roster adapter has shipped. The adapter affects whether PromptShields can read your device inventory back — it does not affect your ability to push the client out.
Workspace ONE / Omnissa and the SMB long tail (Hexnode, Mosyle, Scalefusion) are not currently planned. Their Chrome and Edge managed-policy payloads are equivalent to the ones below.

​
Force-installing the browser extension

You will need the PromptShields extension ID from your store listing. It is referred to as <EXTENSION_ID> throughout.
Configuration Profile → Settings catalog → Google Chrome > Extensions > Configure the list of force-installed apps and extensionsAdd one entry:
For Microsoft Edge, use the equivalent Microsoft Edge > Extensions > Control which extensions are installed silently setting with the Edge Add-ons update URL.
Force-install makes the extension non-removable by the user. Communicate that before you push it. An extension that silently appears and cannot be removed generates far more helpdesk noise than one that was announced.

​
Deploying the desktop agents

The desktop agents are ordinary managed applications — deploy them the way you deploy any other line-of-business app.
Package the MSIX and deploy through Intune as a Line-of-business app or a Windows app (Win32).Two prerequisites to verify in the same deployment:
  1. The WebView2 Runtime must be present, or sign-in cannot complete.
  2. The prompt-shields:// protocol handler must be allowed to register.
See Windows agent for detail.

​
Verifying coverage

A push that reports success is not the same as a client that is working. Reconcile three lists:
1

MDM says the policy applied

Your MDM’s compliance report — the device received the profile.
2

The client checked in

The console’s deployment view shows agents online, their version, and which platforms the rollout touched.
3

Investigate the gap

Devices in list one but not list two are your real work: machines that are offline, offboarded, asleep, or where the user never completed sign-in or the permission grant.
The deployment view surfaces offline agents with context — last seen date and, where known, the reason — so long-tail investigation does not require a spreadsheet.

​
Rollout sequence that works

  1. IT department only. Manual install. Shake out sign-in and endpoint configuration.
  2. One friendly department. Still manual or optional install. Watch the false-positive rate in Guideline mode.
  3. Force-install the browser extension fleet-wide. Policies stay in Guideline — observing, changing nothing.
  4. Deploy the desktop agents where native-app coverage matters.
  5. Promote policies to Strict once the data supports it. See Policies.