macOS and Windows app allowlisting with Hexnode: inventory gaps, Santa MonitorMode, and AppLocker AuditOnlySolved

The behavior you are seeing comes from a few different mechanisms working together. For inventory and policy selection:

• The app picker is an aggregated list of apps discovered from enrolled devices and apps available in the portal’s app repository. Once an app is discovered on at least one enrolled device, it can appear as a selectable item for policy configuration.
• Reports > Applications is intended to show the current application inventory based on the latest device check-in.

For Adobe Creative Cloud apps on macOS, the discrepancy is usually caused by install location and app structure. Many Adobe apps are installed as nested bundles, for example: /Applications/Adobe Premiere Pro 2026/Adobe Premiere Pro 2026.app

These nested app bundles may not always be captured consistently in standard automated inventory sweeps, even though they can appear in the policy picker from previously discovered data.

If you do not want to allowlist all of /Applications/, use explicit path-based entries for the nested apps instead of relying only on bundle IDs or broad directory rules. For example, target the full app path for each Adobe application you want to allow.

For macOS enforcement, Hexnode’s native app restriction policies rely on Apple’s native configuration profile framework, including Screen Time-based controls. These are enforcement-focused and do not provide a native alert-only or monitor-only toggle. Also, users with full local administrator/root access may be able to bypass or tamper with some local enforcement components. ADE enrollment makes the MDM profile non-removable from System Settings, but it does not remove the user’s underlying root privileges.

For Windows, Hexnode Application Compliance is primarily an audit/compliance mechanism. It can flag a device as non-compliant but does not provide scalable rule-based blocking with wildcards or publisher rules through the standard selector. For larger deployments, AppLocker or Windows Defender Application Control is usually more practical because they support rule-based allowlisting such as publisher rules and path rules.

That clears up the picker vs reports part. We don’t want to allow /Applications/ though. If local admins can drag apps there, it defeats the point of an allowlist. We’re leaning toward monitor mode first. Can Hexnode ingest Santa block/unknown events or AppLocker audit events centrally? Or would those logs only live on the endpoints?

For a strict local-admin-resistant model on macOS, Santa is the more appropriate architecture because it uses Apple’s Endpoint Security Framework for binary authorization. Hexnode can be used to deploy the required components, such as:

• Santa package
• System Extension profile
• PPPC profile
• Santa configuration profile

However, Hexnode does not natively ingest Santa’s block, allow, or unknown-event telemetry into the Hexnode dashboard. If Santa is run in MonitorMode, its events must be collected from the device and forwarded to a centralized logging or SIEM platform.

For Windows AppLocker, you can deploy an AppLocker XML policy through Hexnode using Deploy Custom Configuration. If your XML uses: EnforcementMode=”AuditOnly“ Windows will respect audit-only mode. Hexnode does not force the policy into enforcement mode.

AppLocker audit events are generated locally in Windows Event Viewer under: Application and Services Logs\Microsoft\Windows\AppLocker

For example, Event ID 8003 indicates that an executable would have been blocked. Hexnode does not aggregate those individual Windows Event Viewer entries into the compliance dashboard, so centralized alerting would require Windows Event Forwarding or a SIEM/log collection tool.

We tested the macOS side with Santa in MonitorMode using Hexnode for deployment. It runs fine on the pilot devices and generates logs. One thing we noticed: JSON logging includes the full process environment, which we didn’t want written to disk. We switched to filelog and are parsing that through our log pipeline instead.

That is a reasonable security decision. JSON is easier for most SIEM tools to parse, but if the JSON output includes more process environment data than you want stored locally, using Santa’s filelog format and parsing it centrally is a valid approach.

For AppLocker AuditOnly testing, be aware of the default AppLocker rules. If the policy allows everything under locations such as Program Files or System32, executables launched from those paths will not generate Event ID 8003 because they are already allowed.

To validate that audit logging works, test with an unapproved executable from a user-writable path such as:

• C:\Users\Public
• a user Downloads folder
• another non-allowed user-space directory

That should generate the audit event needed to confirm the monitoring pipeline before switching to enforcement.

So the practical setup is:

• Use Hexnode native app restrictions only where profile-based enforcement is enough.
• Avoid broad /Applications/ allowlisting if local admins are in scope.
• Use explicit paths for nested macOS apps when staying within Hexnode policies.
• Use Santa MonitorMode for stronger macOS binary monitoring and send logs to a SIEM.
• Use AppLocker AuditOnly XML on Windows and collect Event ID 8003 from Windows logs.

That seems like the direction we’ll take.

Yes, that is the recommended approach for this requirement. Hexnode can act as the deployment and configuration channel for both Santa on macOS and AppLocker on Windows, while the event telemetry and alerting layer should be handled by your centralized logging platform. For macOS, keep the native Hexnode allowlist for simpler restrictions or targeted path-based controls. For a stricter default-deny model with local admins, use Santa MonitorMode first, validate events, then move toward enforcement when your allowlist is mature. For Windows, deploy AppLocker in AuditOnly mode first, collect and review audit events, refine publisher/path/hash rules, and only then switch to enforcement if the policy is stable.