Restrict Microsoft Office macros ML2: requirements, evidence

What Essential Eight ML2 asks for when restricting Office macros

If an audit, a customer questionnaire or your own plan has moved you from Maturity Level One to Maturity Level Two, the key change for Microsoft Office macros is this: ML2 keeps every ML1 macro restriction and adds a requirement that macros are blocked from making Win32 API calls, tracked as ISM-1673 in ASD's Information Security Manual. The risk behind that control is macros reaching deep into the operating system, where a malicious macro can call system functions directly instead of working only inside the Office application. The hard part is rarely the setting itself. It is finding the macros that legitimately depend on API access, such as those that interact with other applications, drivers or file system features, and deciding whether each one can be rewritten, moved to a controlled location or formally excepted.

Start with an inventory. Ask the team responsible for Office to list every macro-enabled document, template and add-in in use, who owns each one and what it calls. Then test the block in a pilot group before rollout, because a macro that fails silently can break a business process that nobody thought of as a macro. Record each exception, its owner and its review date. The ML1 controls behind this, including disabling macros without a business need and blocking internet-sourced macros, must still hold, so confirm they are enforced on the same endpoints. Confirm with your Microsoft administrators which policy mechanism enforces the API block in your environment, since the exact setting depends on your Office build and management tooling.

The Essential Eight is a set of mitigations, not a certification scheme, so there is no ASD certificate for reaching ML2. Maturity is shown when an assessor reviews how the strategy is implemented and whether it works in practice against the maturity model. Your evidence for this control should therefore show the policy configuration, the pilot results, the exception register and a sample of endpoints where the block was tested. Ask your assessor early which evidence they expect, and treat their review, not an internal checklist, as the measure of whether you are at ML2. The Essential Eight maturity model on cyber.gov.au is the reference the assessor will work from.

Which Office estate and macro sources fall under the ML2 macro control

The ML2 macro control applies to wherever Microsoft Office macros can run, not only to the machines the IT team manages day to day. Settle these scope decisions with the assessor before configuration work starts, because the population you agree to test sets the size of the work.

Office applications and versions

Inventory every Office application that can execute macros, including Word, Excel, PowerPoint, Access and Visio, and record the build and channel for each. Macro blocking settings differ between builds, so a machine on an older build can pass a policy check while still running macros the policy was meant to stop. Ask the assessor whether Office outside your standard image, such as legacy or project-specific installs, sits inside the tested population. Confirm which Office versions the ML2 macro setting is verified against.

Windows endpoints and servers

List the Windows workstations, virtual desktops, terminal servers and servers where Office is installed or published. Shared session hosts and published Office apps often run macros for many users under one machine, which makes them a higher-risk population than a single laptop. Check that the Win32 API restriction reaches each of these hosts through the same management channel, and record any host that is excluded from that channel.

User groups that can run macros today

Identify which users can enable macros now, including members of groups granted exceptions for finance, HR or operations workflows. Each exception is a place where the ML2 control must be justified or narrowed. Pull current group membership and exception records, not only the policy design, because drift often lives in those exceptions. Ask who approves a business need and how often that approval is reviewed.

Macro sources in documents, add-ins and templates

Macros arrive from more than the documents users open. Map macros embedded in files, Excel and Word add-ins, Normal.dotm and shared templates on network shares, and macros loaded through startup folders or add-in directories. Each source needs a clear owner and a clear path into the scope. A template that every user loads will expose many machines through one file, so treat shared templates as a separate line item in the scope statement.

Third-party and contractor machines

Contractor laptops, supplier devices and personal devices that open your organizational documents can run macros outside your management tools. Decide whether these devices are in scope, and if they are, how the control applies to devices you do not own. Where they are out of scope, document the reason and the compensating control, such as blocking external access to macro-enabled files. Confirm this boundary explicitly with the assessor, since it is often where findings appear.

Agreeing the tested scope

Write the scope statement as a list of Office builds, host populations, user groups and macro sources, then agree it with the assessor before evidence collection begins. A scope that is narrower than the estate invites questions about why hosts were left out, and a scope wider than what you can evidence creates unnecessary work. Keep the scope statement under version control so each assessment cycle can show what changed.

What changes between ML1 and ML2 for macros

Moving from Maturity Level One to Maturity Level Two for Microsoft Office macros is mostly additive. ML2 does not replace the ML1 controls. Macros must still be disabled for users without a demonstrated business need (ISM-1671), macros from the internet must still be blocked (ISM-1488), macro antivirus scanning must still be on (ISM-1672), and macro settings must still be locked so users cannot change them (ISM-1489). An organization that claims ML2 without first confirming those four controls are working has a gap at the base of its macro posture. Before adding anything, confirm each one against the Office policy, the device configuration and a sample of endpoints.

The single macro control added at ML2 is ISM-1673: Microsoft Office macros must be blocked from making Win32 API calls. This is the control that separates the two levels for this strategy. In practice, the work is to identify which approved macros legitimately call Win32 APIs, decide whether each one is still needed, and then enforce the block through the platform's policy tooling. Expect the most effort in the inventory step, because business owners often do not know which macros call into the operating system. Ask the implementation partner or your own administrators to produce that inventory, and treat any macro that cannot be justified as a candidate for removal.

The ISM Essential Eight baselines are published in OSCAL, so ISM-1673 can be traced to the ML2 profile and to the ML1 and ML3 profiles in the same machine-readable set. That traceability matters for evidence. An assessor can see that the control sits in ML2, and that ML3 later replaces the macro execution rules with stricter ones: macros may run only from a sandbox, a Trusted Location or when signed by a trusted publisher. Review the ISM OSCAL files in the ISM OSCAL repository to confirm the exact control text and baseline membership for your version before you build your evidence register.

How an assessor tests the ML2 macro block

This table compares what an assessor does, asks for and usually finds when testing the Win32 API block at Maturity Level Two. Read it as a checklist for your own pre-assessment review, since each row maps a test step to the evidence that should exist before the assessor arrives. The main takeaway is that a policy on paper is not enough: the block must be verified on sampled endpoints across every Office application in scope.

Test area	What the assessor does	Evidence requested and common findings
Effective policy review	Samples endpoints across user groups and reads the effective macro policy on each, not only the central template	Exported policy settings per device. Finding: the Win32 API block is set in one Office application but not in others in scope
Controlled macro test	Runs a test macro in a non-production sample that attempts a Win32 API call and records whether it is blocked	Test record with date, device, Office version and result. Finding: the test was run once on a single build and never repeated after updates
ML1 restrictions still hold	Confirms internet-sourced macros are blocked, macros are disabled without business need, macro antivirus scanning is on and settings are locked	Policy exports showing each ML1 setting alongside the ML2 addition (ISM-1673). Finding: ML2 change weakened an ML1 setting
User changeability	Checks whether an ordinary user can alter macro settings or trust decisions in the Office interface	Account permission review and screenshots of the user view. Finding: settings a user can change without an administrator
Exception register	Requests the list of macro exceptions and checks each has an approver, a business reason and an expiry date	Register with owner, scope, compensating control and review date. Finding: exceptions with no owner or no expiry
Change and drift	Looks for evidence that the policy is monitored and that a changed setting is detected and reviewed	Configuration monitoring output or change tickets. Confirm with your tooling vendor what drift reporting it supports
Logging linkage	Checks that macro-related security events feed the central logs reviewed under ML2 logging controls (ISM-1906, ISM-1228)	Log source list and sample alert from a macro-blocked event. Finding: blocked events are generated locally but never reach the log store

How to implement the ML2 macro block in sequence

This sequence takes an organization from an inventory of macro-dependent documents to a documented, tested and signed-off Win32 API block at Maturity Level Two. Each step produces a record that an assessor can later examine.

Inventory macro-enabled documents and their owners
Identify which documents, templates and add-ins in the estate contain macros, and which business teams depend on them. Record each item with its file location, purpose, author, business owner and whether it calls Win32 API functions. The output is a macro inventory list that names an accountable owner for every entry. The step is done when the business owners have confirmed their entries in writing.
Confirm the ML1 macro settings are in place
Before adding the ML2 control, verify that the ML1 restrictions are enforced on every managed device: macros disabled for users without a demonstrated business need, internet-sourced macros blocked, macro antivirus scanning enabled and macro settings locked against user change. Use central configuration and a compliance check, such as a configuration assessment or a policy query, to show the current state. The output is a configuration baseline that records each setting, its value and the check that confirmed it.
Build the Win32 API block as a central policy
Write the ML2 rule that blocks Microsoft Office macros from making Win32 API calls, using the Office administrative mechanisms your estate already uses, and apply it through central device management rather than local settings. Keep the policy in version control with a change record so its history can be shown later. Confirm with the vendor documentation for your Office version which setting names apply, since this guide does not list them. The output is a versioned policy file and its change record.
Pilot the policy on a controlled group
Apply the policy to a small pilot group chosen from the inventory's business owners and IT staff, and run a set of controlled test macros covering known-good macros, macros that call Win32 APIs and macros blocked by the ML1 controls. Record what each test macro did, whether it was blocked, and who observed the result. Where a legitimate macro is blocked, log it for the exception process rather than reverting the policy silently. The output is a pilot test record with pass or fail for each test case.
Handle exceptions through a documented approval
Route every macro that fails a legitimate business need through a written request that names the document, the business reason, the Win32 API calls involved and the risk owner who accepts it. Approve, reject or redesign each request, and set a review date for approved exceptions. Keep approved exceptions narrow so the control still applies to the estate. The output is an exception register with an approver, a decision and a review date for each entry.
Roll out to the full estate
Expand the policy from the pilot group to all in-scope devices in stages, checking the compliance status of each group before moving to the next. Confirm that devices outside central management are identified and either brought under management or documented as out of scope. Watch for user-reported blocked macros and route them into the exception process. The output is a rollout log that shows the devices in each wave and their compliance status at the end of each wave.
Record the policy state and test results
Produce a signed rollout record that states the policy version, the devices in scope, the pilot and rollout test results, the exception register and the named approver for the final state. Store it with the ML1 baseline and the inventory so that the control can be traced from requirement to evidence. Ask the independent assessor which format of record they expect, because the format is theirs to decide. The output is the signed rollout record, which becomes the core evidence for this control.

Evidence that passes an ML2 macro assessment

An assessor testing Microsoft Office macro restrictions at Maturity Level Two looks for proof that the Win32 API block is configured, enforced and working over time. The artifacts below connect the configuration, the exceptions, the test results and the logs, so each one can be checked against the others.

Exported central policy with Win32 API block

Export the active policy for every Office application in scope, showing the setting that blocks macros from making Win32 API calls alongside the ML1 settings they build on. Assessors compare the export against what devices actually receive, so confirm the export comes from the management system that pushes the policy, not from a document someone typed. Schedule the export and store each version with the date and the change ticket that produced it. An export that predates the last policy change proves nothing about the current state.

Dated test record of blocked macros

Keep a test record showing a controlled macro, built for the test and carrying no business function, failing to call the Win32 API on a representative device. Each entry should name the Office application, the build of the test macro, the device, the tester and the date. Repeat the test after any policy change, Office update or new Office application rollout. Assessors favor records they can reproduce, so store the test macro and its expected result alongside the log.

ML1 configuration baseline

Maintain the baseline that proves the ML1 macro controls still hold at ML2: macros disabled for users without a demonstrated business need, internet-sourced macros blocked, macro antivirus scanning on, and macro settings locked. Record each setting, its expected value and the last date it was verified. The ML2 assessment reuses these controls, so any drift in the ML1 baseline will also appear as a gap at ML2. Confirm that the baseline maps to the ISM controls ASD lists for ML2 rather than relying on a local naming scheme.

Exception register with owners and review dates

List every user, group or document that receives macro permissions beyond the standard policy. Each row needs a named business owner, the business justification, the approving authority, the scope of the exception and a review date. Assessors check whether exceptions expire and whether any still in force lack a justification. The register should also show that an exception never bypasses the Win32 API block without separate approval. Review it on a fixed cadence and record the outcome of each review.

Endpoint compliance reports over time

Collect point-in-time results from endpoint compliance checks that confirm each managed device is still applying the macro policy. A single passing report shows a snapshot, while a series of reports shows whether the control holds between audits. Configure policy queries that return yes or no answers for each device, and retain the history so failing devices can be traced to their remediation. Check that the reports cover unmanaged or newly enrolled devices, because gaps in enrollment are a common reason a control appears to pass when it does not.

Event log entries of blocked macro activity

Retain event log entries that show macro activity being blocked, including the application, the device, the user and the time. These entries prove that the control operates in production rather than only in a test lab. Protect the logs from unauthorized modification and deletion, and analyze them in a timely manner so that repeated blocked attempts are investigated. Incidents found through these logs should follow the incident response plan and reporting path your organization defines for the CISO and, where required, ASD.

What meeting the ML2 macro block costs in money and effort

This table breaks down the cost components of blocking Win32 API calls from Office macros at ML2, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build an itemized scope before requesting quotes, since no price figures are published here.

Cost component	One-time or recurring, and who is paid	What drives it up, and how to keep it down
Policy management tooling and licenses	Recurring. Licensed endpoint management or GPO and Intune licensing is paid to the vendor; self-hosted open-source options such as Fleet (MIT) can replace some licensed monitoring, but confirm the license terms of any bundled component before relying on it.	Up: number of endpoints and whether macro policy must be enforced on devices outside the corporate network. Down: reuse existing Office and endpoint management licenses and confirm what they already include before buying new tooling.
Engineering time to build and test the policy	One-time for the initial configuration and test plan, paid to internal staff or an implementation partner. Some retesting recurs after Office or endpoint updates.	Up: number of Office versions, build variants and test rings. Down: standardize on a single supported Office baseline and write the block as a repeatable, version-controlled configuration.
Business time to review macro dependencies and exceptions	Recurring. Paid as internal staff time across finance, operations and other teams that rely on macros for workflows.	Up: number of macro-dependent workflows and the volume of exception requests. Down: inventory macro use before enforcement, retire obsolete macros and set a documented approval path for the few exceptions that remain.
Evidence upkeep	Recurring. Staff time to export policy state, keep exception records and retain logs that show the block is in force and that changes were approved.	Up: number of exceptions, change frequency and the number of systems producing evidence. Down: automate policy-state reporting and keep one exception register linked to the relevant control IDs.
External testing or review	Optional, one-time or periodic. Paid to an independent tester or reviewer, separate from the auditor who issues any report.	Up: scope of the review and the number of endpoint builds tested. Down: agree a written scope that covers a representative sample of builds rather than every endpoint.
Auditor sampling time	Recurring with each assessment cycle. Paid to the independent assessor, based on the sampling plan they set.	Up: unclear evidence, undocumented exceptions and inconsistent configurations across endpoints. Down: provide a complete policy export, a current exception register and logs that show macro-blocking events are reviewed.
Quote scope	Request a quote with an itemized scope that separates one-time setup from recurring work and shows which items are licensed, which are open source and which are staff time.	Ask each provider to state the Office versions, endpoint count, number of workflows reviewed and evidence outputs included, so quotes can be compared on the same basis.

Open-source tools that support ML2 macro evidence

Maturity Level Two adds Win32 API blocking to the ML1 macro controls, and it also expects logs to be protected, analysed and reported. The tools below can help produce evidence for those controls, but each covers a different piece of the picture. None of them enforces the Win32 API block on its own, so the Office estate still needs its own configuration and verification.

Configuration drift checks with Wazuh

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies, largely based on CIS benchmarks, and checks files, directories, registry keys and running processes. Teams can add custom policies that test the Office macro settings their ML2 baseline expects, then review the failures. Confirm that your policy content covers the specific Office registry values for your build and Office version before relying on the results as evidence. Wazuh does not block Win32 API calls itself.

Device compliance questions with Fleet

Fleet policies are yes or no osquery questions asked of each device, and the policies page shows which devices pass or fail. A policy can ask whether the macro setting is present on a workstation, which gives a fleet-wide view of gaps. A passing query shows the setting exists, not that it is enforced. Confirm that osquery can read the relevant configuration on your managed platforms and that the question matches your own macro requirement.

Application audit trails with Nextcloud

Where Nextcloud hosts documents or workflows that touch Office files, the admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. This supports the ML2 expectation that event logs are protected from unauthorised modification and deletion, once the log is forwarded and access-controlled. Confirm which events the app records in your version and that the log file is protected and retained. It does not inspect macro execution on endpoints.

Secrets and API request audit with OpenBao

OpenBao audit devices record a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. This gives a tamper-evident record of who requested which secrets, which can support the ML2 logging and incident analysis expectations for systems that hold credentials used by macro-enabled workflows. Confirm the hashing and retention behaviour for your deployment, and ship the log to a protected store. OpenBao does not control Office macros.

Who owns the macro control, who prepares evidence, and who assesses it

Your organization owns the Maturity Level Two macro control. That means the decisions about which macros are needed, who may approve an exception and how the restriction behaves in daily work sit with your people, not with a vendor or consultant. The ML2 addition is the Win32 API block tagged ISM-1673 in the ISM OSCAL catalog, and your team is accountable for deciding how that block affects existing business workflows.

Control ownership: Name an accountable owner for the Office macro settings, the Win32 API restriction and the exception register.
Exception approval: Decide who may approve a macro that needs to call Win32 APIs, and record the business justification and expiry for each approval.
Business reviews: Walk through macro-dependent workflows with the teams that use them, such as finance spreadsheets or reporting templates, and decide which ones move to a supported alternative.
Operational records: Keep the change history for policy updates, exception decisions and review outcomes, because the assessor will ask for them.

Before engaging anyone, confirm that your team can name the owner, the approver and the review cadence for this control in writing.

Questions buyers ask about the ML2 macro requirement

How much extra effort does the ML2 macro block add on top of ML1?

At Maturity Level Two the work is incremental: the ML1 macro controls stay in place, and the main new task is blocking Microsoft Office macros from making Win32 API calls, tracked as ISM-1673 in ASD's ISM OSCAL catalog. The effort depends on how many macro-enabled documents, add-ins and line-of-business workflows your organization depends on. Most of the cost sits in finding those dependencies and testing them, not in the policy change itself. Ask a partner to separate the ML2 macro work from the ML1 baseline in any quote so you can see what is new.

What does the ML2 macro work need from the business and IT teams?

IT needs to own the configuration, testing and rollout, while the business owners of macro-dependent processes need to confirm which macros are genuinely required. Security needs to define the evidence it will accept and confirm that logs of blocked macro activity reach a central place. Expect the business side to be asked for a list of workflows, owners and acceptable alternatives, because a blocked Win32 call can break a process that nobody documented. Agree these roles before work starts so testing does not stall on sign-off.

How long does it take to reach a tested state for the ML2 macro control?

No duration is fixed here, because the timeline depends on the drivers that matter most: the number of Office endpoints, how many macro-dependent workflows exist, whether group policy or Intune is already in use, and how quickly business owners can test. Testing and exception handling usually take longer than the configuration change. Ask any provider to break the timeline into discovery, configuration, pilot, rollout and evidence collection, and to state which steps depend on your staff's availability.

Can our own team implement the ML2 macro control in-house?

Often yes, if you have administrators who manage Office configuration centrally and someone who can test business workflows properly. The control itself is a configuration change, but proving it works requires a documented baseline, a pilot group and records of exceptions. Teams that lack Office administration experience or that cannot schedule business testing tend to benefit from outside help on the rollout and evidence. Whichever route you choose, the organization remains responsible for the control.

What should we ask a partner to include in a fixed-scope quote?

Ask for the written scope to name the endpoints, Office versions and workflows covered, the ML1 controls that are assumed to be in place, and the ML2 macro configuration to be delivered. The quote should list deliverables such as configuration records, a pilot report, an exception register and the evidence pack, plus what the client must provide, such as workflow owners and test time. Confirm who performs testing, who approves exceptions, and what happens if a business workflow fails. A partner prepares evidence, but only an independent assessor issues any assessment conclusion.

Does an assessor certify that we meet ML2 for macros?

No. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate for Maturity Level Two. Maturity is evidenced through an assessment of how each strategy is implemented and how effective it is against the maturity model. An independent assessor can review that evidence and report on it, and your own governance records will show what you concluded. Be cautious with any provider who offers an Essential Eight certificate.

How do we keep the ML2 macro control current after the assessment?

Treat it as a recurring operational task. Review the list of macro-enabled workflows and exceptions on a set schedule, check that the Win32 API block still applies after Office updates and policy changes, and retain logs showing blocked macro activity. Wazuh's Security Configuration Assessment can check endpoint configuration against YAML policies, and Fleet policies can ask yes or no questions of devices to show which ones pass or fail, which helps produce ongoing evidence. Confirm both tools against your own Office environment before relying on them.

How DeployOpen scopes and prepares ML2 macro evidence

DeployOpen works on the ML2 macro requirement as one part of a wider Essential Eight implementation inside your own infrastructure. We scope the systems, build the controls and assemble the evidence, while your organization keeps ownership of its controls and an independent assessor decides whether the level is met.

How we scope

Engagements are fixed-scope, with the Office estate, macro policy sources and in-scope endpoints agreed in writing first.
The written scope names which ML2 macro controls apply, including the Win32 API block alongside the ML1 restrictions.
We confirm which logs and endpoint reports will serve as evidence, and who in your organization owns each one.

How we build

We configure the Win32 API restriction for Office macros and check it against the ISM control tagged ISM-1673 in the ASD profile.
Endpoint configuration checks, such as Wazuh policies or Fleet yes or no queries, are set up to show whether devices pass or fail the macro settings.
Macro-related event logs are forwarded to a central store with protection against unauthorised modification and deletion, consistent with ISM-1815.

How we hand over

You receive documentation of each macro setting, its owner, its test method and where its evidence is stored.
Test records show the policy state on sampled devices, along with the procedure used to produce them.
We walk your assessor and internal owners through the evidence set, so they can trace each ML2 macro control to its proof.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the handover.
Retainers can cover periodic re-checks of macro policies, log forwarding health and evidence refreshes before each assessment.
Ask us in your quote to confirm exactly which of these recurring tasks sit inside your retainer and which stay with your team.