How do app allowlist, blocklist, and compliance policies work on Windows and macOS?Solved

Hi @ruthg_,

Application Compliance and active app blocking are separate workflows in Hexnode.

Application Compliance policies are used for monitoring. If an app that does not meet the configured compliance rule is found on a device, the device is marked non-compliant in the Hexnode portal. This does not automatically prevent the app from launching.

Active app blocking is handled through Allowlist or Blocklist Policy.

On both Windows and macOS:

• Blocklist mode allows users to run apps normally, except for the apps explicitly added to the blocklist.
• Allowlist mode blocks apps by default and allows only the apps explicitly added to the allowlist.

So, if the goal is only to detect and report unauthorized apps, use Application Compliance. If the goal is to actively prevent apps from running, configure the relevant Allowlist or Blocklist policy.

Allowlist and blocklist are generally used as alternative enforcement approaches. A blocklist is suitable when only a few apps need to be restricted, while an allowlist is better for strict environments where only approved apps should run.

Best Regards,
Isabel Lora
Hexnode UEM

That clears up the compliance part. One thing still confuses me though: on macOS, the allowlist page shows a huge list of apps, including native utilities like the screenshot tool. On Windows, I don’t see the same kind of pre-filled list.

Are the macOS apps coming directly from enrolled devices? And why does Windows not show a similar list?

Yes @ruthg_, the behavior differs between macOS and Windows because of how app inventory is reported.

For macOS, Hexnode can collect and display installed applications from enrolled Macs, including native macOS utilities. That is why the macOS allowlist or blocklist selection may show many discovered local apps. This makes it easier to select apps without manually entering their identifiers.

For Windows, the policy dropdown does not automatically populate with every local or system application installed on managed devices. Windows app control usually requires the app to be defined explicitly.

So “Store Apps” does not mean a collective inventory of all apps installed across devices. It refers to apps available in or added to the Hexnode app repository.

Best Regards,
Isabel Lora
Hexnode UEM

I had the same misunderstanding with Store Apps. I assumed it was a combined list from all enrolled devices, but it makes more sense now that it’s tied to the app repository. The macOS list being populated from device inventory explains why it looks much larger.

One more related question: if a report shows multiple versions of the same app, for example several Slack versions, do I need to allow every version separately? If I allow only the newest version, will older installed versions stop working?

No @ruthg_. Older versions will not stop working just because the report lists multiple versions.

Hexnode allowlist policies identify apps using their unique application identifier, such as the Bundle ID on macOS or the Package Name/App ID where applicable. The version number is not what determines whether the app is allowed.

For example, if multiple versions of the same app share the same application identifier, allowing that app allows all versions that use the same identifier. Reports may show different versions separately to provide visibility into what is installed across endpoints, but allowlist enforcement treats the app as the same application as long as the identifier remains unchanged.

In short, you normally allow the app itself, not each individual version.

Best Regards,
Isabel Lora
Hexnode UEM