Ever poured milk into your coffee only to realise it had gone off? That’s a similar kind of disappointment to what happens when unknown or malicious software sneaks into your virtual desktop environment. Application Control keeps your environment free from untrusted code—making sure only good beans go through the grinder.

In the world of Azure Virtual Desktop (AVD) and Windows 365 (W365), that means clearly defining and enforcing which applications and binaries can run. The result: stable, predictable, and secure workspaces ready for production.

What is Application Control?

Application Control is one of the Essential Eight mitigation strategies from the Australian Cyber Security Centre (ACSC).

Think of it as a virtual doorman: only pre‑approved software gets through the door, and everything else is turned away before it even gets to the bar.

Goal for Maturity Level 2

Implement centrally managed application allow‑listing across all workstations, internet‑facing servers, and cloud desktops. Policies must restrict execution of executables, installers, scripts, compiled HTML, and software libraries to an organisation‑approved set, while blocking everything else.

ML2 also requires:

• Microsoft’s recommended application blocklist to be implemented.
• All allow and block events to be centrally logged, analysed in a timely manner, and protected from unauthorised modification or deletion.
• Cybersecurity events to be triaged, escalated to the CISO (or delegate), reported to the Australian Signals Directorate (ASD) where applicable, and managed under the organisation’s incident response plan.

Solutions meeting this level include Microsoft Defender Application Control (MDAC), AppLocker, and third‑party tools such as ThreatLocker and Huntress.

How it Works in Cloud VDI

Application Control enforces trust rules at the OS layer for AVD and W365 endpoints. Policies block execution outside approved paths, publishers, or hashes—keeping user and attacker activity under control.

Both AVD & W365 can leverage Microsoft Sentinel or Huntress for their centralised logging & managed SIEM requirements

Centralised Logging Flow

• MDAC/AppLocker logs to Microsoft‑Windows‑CodeIntegrity and AppLocker Operational event logs.
• Logs can be forwarded using the Azure Monitor agent into Microsoft Sentinel, Defender for Endpoint, or a Huntress Managed SIEM instance.
• ThreatLocker provides cloud‑native audit logs that can export directly to Huntress or Sentinel for SOC‑level analysis.
• Once ingested, events are write‑once and immutable, satisfying ML2’s requirement for protecting logs from modification or deletion.

Real‑World Impact

Without Application Control, users or attackers can run virtually anything—from legitimate but risky admin tools to full‑blown malware.

Implementing this control delivers:

• Clear separation between trusted and rogue executables.
• Reduced attack surface across both pooled and personal VDI instances.
• Operational consistency between session hosts and Cloud PCs.
• Stronger evidence for Essential Eight ML2 compliance, with verifiable centralised logs.

Application allow‑listing also simplifies post‑incident analysis, helping teams trace root causes fast without hunting through endpoints one by one.

Implementation Examples

Intune Portal: MDAC with Central Logging

1. In Intune, open Endpoint security > Attack surface reduction > Application control.
2. Create a new Defender Application Control Policy and select Microsoft’s recommended blocklist to satisfy ASD requirements.
3. Assign a Starter policy (for example, “Allow Microsoft and Store‑signed apps”).
4. Deploy logging by:
   • Installing the Azure Monitor Agent.
   • Configuring diagnostic settings for CodeIntegrity and AppLocker operational logs.
   • Sending events to Microsoft Sentinel, Huntress Managed SIEM, or Defender for Endpoint via secure connectivity.
5. Create analytic rules or detection packs to highlight blocked or unsigned executions.

Bicep Example (Log forwarding configuration concept)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

resource law 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: 'law-avd-security'
  location: resourceGroup().location
}

resource diag 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: 'sendAppControlLogs'
  scope: avdSessionHost
  properties: {
    workspaceId: law.id
    logs: [
      {
        category: 'AppLocker'
        enabled: true
      }
      {
        category: 'Microsoft-Windows-CodeIntegrity/Operational'
        enabled: true
      }
    ]
  }
}

ThreatLocker

1. Deploy ThreatLocker agents to your AVD or W365 devices.
2. Enable Learning Mode to baseline permitted applications.
3. Enforce policies after validation.
4. Review block events and alerts sent automatically to the ThreatLocker Portal or your connected SIEM.
5. Logs can stream directly to Huntress or Sentinel, where they’re retained securely with integrity controls.

Huntress Managed SIEM

If you prefer a fully managed logging backbone without owning a Sentinel workspace:

1. Connect your MDAC, Defender, or ThreatLocker telemetry sources using Huntress ingestion connectors.
2. Configure Windows Event Forwarding from VDI hosts (CodeIntegrity and AppLocker logs).
3. Huntress collects, normalises, and monitors events, providing SOC analysis and alerting back to your security team.
4. This satisfies ASD’s requirement for timely analysis and incident identification of application control events.

Gotchas & Edge Cases

• Audit First: Begin with audit or learning mode before enforcement.
• Unsigned Apps: Internal or custom apps must be signed or explicitly allowed.
• Golden Image Sync: AVD hosts rebuilt from the master image must automatically receive updated allow‑lists and log forwarding.
• Event Volume: Application control logs can grow quickly—plan retention filters.
• Clarify SIEM Ownership: Whether Sentinel or Huntress, ensure someone is reviewing the dashboards; unattended logs don’t count toward ML2 “analysed in a timely manner.”

Best Practices

• Apply Microsoft’s Recommended Application Blocklist in all MDAC deployments.
• Continuously tune AppLocker or ThreatLocker rules based on review logs.
• Forward logs to a central SIEM—choose Microsoft Sentinel if you want deep Azure integration, or Huntress Managed SIEM if you prefer a fully managed option with SOC oversight.
• Confirm central SIEM stores logs immutably and monitors event integrity.
• Validate rulesets annually, following policy drift reviews.
• Strengthen your incident escalation workflow:
  • SOC receives SIEM alerts from Sentinel or Huntress.
  • Escalate confirmed cases to the CISO or delegate.
  • If warranted, report to ASD and execute the active cyber incident response plan.

Learn More

• Microsoft Defender Application Control Overview
• AppLocker Policies in Windows
• ThreatLocker Official Documentation : only accessible via a portal login
• Huntress Managed SIEM Overview
• Microsoft Recommended Block Rules
• Azure Monitor Agent Overview
• Microsoft Sentinel Data Connectors
• ACSC Essential Eight Maturity Model