Implementing Essential 8 Maturity Level 2 in Microsoft Cloud VDI (AVD & W365) – Office Macros

Configure Microsoft Office Macros – The Latte Art of Security

You know that feeling when your latte art turns into a murky blob instead of a perfect rosetta? That’s what happens when macro security is ignored, it’s messy, inconsistent, and occasionally dangerous. In Microsoft Cloud VDI environments like Azure Virtual Desktop (AVD) and Windows 365, locking down Microsoft Office macros is a delicate pour. It’s about creating that balance between creativity and control — letting automation fuel productivity, but never letting a dodgy macro spill over into compromise.

What is “Configure Microsoft Office Macros”?

Under the Essential Eight, the goal of this control is simple: don’t let macros become a backdoor for malware. At Maturity Level 2, the ACSC expects you to:

  • Disable macros for users without a proven business requirement.
  • Allow only trusted or digitally signed macros.
  • Block macros originating from the Internet.
  • Prevent users from changing macro settings.
  • Enable macro antivirus scanning.
  • Block macros from making Win32 API calls.

It’s all about ensuring automation is helpful and harmless — like adding sugar, not sand, to your morning brew.

How it Works in Cloud VDI

Macro enforcement can look a little different depending on whether you’re managing session hosts in Azure Virtual Desktop or Cloud PCs in Windows 365.

Both run Microsoft 365 Apps, but the way policy is delivered differs:

  • AVD is generally multi‑session and device‑centric.
  • W365 is single‑user and identity‑centric, better suited for app policy management.

Let’s break down both flavours.

Two Ways to Pour the Policy: Device vs App

Option 1: Device Configuration Profiles (Intune or GPO)

Device‑level enforcement pushes configuration directly to the Windows environment — essentially, registry‑based policy under HKCU\Software\Policies\Microsoft\Office\16.0\Common\Security.

Best for:

  • AVD session hosts (multi‑user or pooled environments).
  • Hybrid joined or domain joined machines.
  • Scenarios where you need registry‑backed, “no user override allowed” enforcement.

Key Pros:

  • Covers all ACSC ML2 requirements, including the Win32 API block.
  • Macro UI fully greyed out.
  • Consistent across multi‑user sessions and golden images.

Caveats:

  • Requires periodic image or script updates in some environments.
  • Slightly heavier management overhead for dynamic host pools.

Option 2: App Policy for Microsoft 365 Apps (via Office Cloud Policy Service)

The newer, cloud‑based approach lets you target macro behaviour at the app level, not the Windows device.
These policies are managed through Intune under:
Apps > Policies for Microsoft 365 Apps

They flow down from the Office Cloud Policy Service (OCPS) and are applied whenever the user signs in to Microsoft 365 Apps with their Entra ID account.

Best for:

  • Windows 365 Cloud PCs (single‑user, fully cloud‑managed).
  • Azure AD‑joined user devices where policy follows the identity, not the VM.

Key Pros:

  • Lightweight, user‑centric management (no image rebuilds).
  • Follows the user if their Cloud PC is replaced or reset.
  • Ideal for tenant‑wide baseline enforcement.

Caveats:

  • Limited macro configuration scope (cannot yet block Win32 API calls).
  • Settings apply only while connected to Office services.
  • Not recommended for AVD multi‑session hosts.

Side‑by‑Side Comparison

  Device Configuration (Intune/GPO) App Configuration (Office Cloud Policy Service)
Policy Scope Machine / User (via registry) User / Identity (via Office sign‑in)
Best Fit For AVD, hybrid join, shared devices Windows 365 Cloud PCs, user‑centric fleets
Delivery Channel Intune MDM or Group Policy Cloud Policy Service (OCPS)
Offline Behaviour Enforced locally Requires connectivity to refresh
Win32 API Block Supported ❌ (not yet available)
Macro AV Scanning
Lockdown (user cannot change) ✅ (for available settings)
Consistency across multi‑session

Real‑World Impact

Mismanaged macro policies are still one of the top causes of ransomware detonation and lateral‑movement campaigns.
A disciplined configuration:

  • Closes a major phishing vector.
  • Reinforces least‑privilege operations.
  • Creates a clean, consistent security posture across app delivery models.

For most deployments:

  • Use Intune Device Profiles for AVD.
  • Use App Policy (OCPS) for Windows 365.
    Mix them if your organisation runs both — those policies happily coexist.

Implementation Examples

A. Using Intune (Device Configuration Profile)

  1. In Intune admin center, go to Devices > Configuration Profiles > Create Profile.
  2. Select Platform: Windows 10 and later, and Profile type: Templates > Administrative Templates.
  3. Configure these settings under Microsoft Office 2016 (or later) > Security Settings > Trust Center:
    • Disable all macros except digitally signed macros
    • Block macros from running in files from the Internet
    • Enable antivirus scanning of macros
    • Block macros from calling Win32 API
    • Prevent users from changing macro settings
  4. Assign to device groups used for AVD session hosts or hybrid desktops.

B. Using Intune (App Policy for Microsoft 365 Apps)

  1. In Intune admin center, go to Apps > Policies for Microsoft 365 Apps > Create Policy.
  2. Sign in with appropriate privileges and select Configure Settings.
  3. Under Security Settings > Macros, configure:
    • Disable macros except digitally signed macros
    • Block macros from the Internet
    • Prevent users from changing macro settings
    • (Optional) Enable macro antivirus scanning
  4. Assign to AAD user groups (this follows the user across devices).

Note: The “Block Win32 API calls” setting is not available here. If ML2 compliance is mandatory, use the Device‑level policy alongside app policy to close that gap.

Policy Flow Diagram

flowchart LR A[Intune Device/Profile Policy] -->|Registry enforcement| B[Office Trust Center] A2["App Policy (OCPS)"] -->|User-based delivery| B B -->|Open document| C[Macro Execution] C -->|Signed/trusted source| D[Run macro safely] C -->|Untrusted or Internet sourced| E[Macro blocked + AV scan] E --> F[No Win32 API calls allowed]

Gotchas & Edge Cases

  • Unsigned macros in internal templates: use a corporate code‑signing certificate (via AD CS or Azure Key Vault).
  • Older builds of Microsoft 365 Apps: ensure you deploy to supported channels (Current Channel / Monthly Enterprise) for macro enforcement parity.
  • Multiple policy sources: If both OCPS and GPO apply, the most restrictive setting wins.
  • Local elevation: remove local admin rights on session hosts to prevent registry regression.
  • Trusted Locations: restrict write access; treat them like a tap locked after hours.

Best Practices

  • Always default to “disable except signed macros.”
  • Combine AV scanning + Win32 API blocking for full ML2 coverage.
  • Use App Policy (OCPS) where users are single‑tenant and mobility matters.
  • Use Device Policy where consistency and lockdown are key.
  • Audit macro execution and blocked events with Microsoft Defender for Endpoint.
  • Re‑test after Office channel upgrades; macro policy enforcement occasionally changes between builds.
🍺
Brewed Insight: Macro controls are like pulling espresso — pressure, temperature, and timing all matter. If you get one off, it either burns the shot (too restrictive for users) or lets something unwanted flow through.
Use Intune App Policy for flexibility, Device Profiles for reliability, and you’ll have a perfect balance — creamy productivity with zero bitter aftertaste.

Learn More