Restrict Microsoft Office macros ML1: requirements

What Restrict Microsoft Office macros at ML1 asks an organization to prove

At Maturity Level One, an organization must show that four settings are in place and stay in place: macros are disabled for human users who lack a demonstrated business requirement (ISM-1671), macros in files from the internet are blocked (ISM-1488), macro antivirus scanning is enabled (ISM-1672), and users cannot change macro security settings (ISM-1489). A compliance lead who can show those four conditions on every in-scope Office installation, with evidence dated to the assessment period, has the core of the ML1 answer. The ASD profile for ML1 is published in the ISM OSCAL release and is the authoritative list of the controls to map against.

Macros matter because Office documents remain a common delivery route for malware. A macro can run code with the user's privileges, download a second-stage payload or drop files that evade signature checks, so the control exists to remove that execution path by default. The requirement is about enforcement, not policy text. An acceptable use statement that says macros are prohibited does not prove anything if a Group Policy object, an Intune configuration profile or a local override allows them on a subset of machines. The assessor will ask for the effective setting on real endpoints, not the intended one, and will ask who can change it.

The hard part is usually people and drift. Finance, operations and engineering teams often depend on spreadsheets with macros built years ago, and the business owner will push for exceptions. Each exception needs a documented business requirement, a named approver and a limited scope, or it becomes a standing gap. Drift is the second problem: settings applied through Group Policy or Intune can be overwritten by a later change, a new device image or a user with local administrator rights. Confirm with your own estimate of the environment which tool is authoritative for each setting, and schedule a recurring check that reads the effective configuration from every endpoint, not only the policy object.

Which Office installations, users and endpoints fall inside the macro control

The Essential Eight profiles define what the macro controls must do, but the organization decides which Office installations, people, devices and file paths the control covers. Each decision below changes the population an assessor will sample and the evidence you need to show.

Microsoft Office desktop installations

Decide whether the boundary includes only Office desktop applications on managed Windows endpoints, or also Office on unmanaged laptops, virtual desktops and macOS. Each installation type has its own macro settings path, so a policy applied to one fleet may not reach another. Build an inventory of installed Office versions and editions, then confirm which ones receive the locked settings. Ask your Office administrator to show a setting applied on a sample from each group, not only the baseline image.

Human users versus service accounts

The control states that macros must be disabled for human users without a demonstrated business requirement, so service accounts and automated jobs sit outside that wording. Document which accounts are human, which are non-interactive, and how each is identified in your directory. Keep a register of any account that runs Office automation, with an owner and a reason. An assessor will ask how you separated the two groups and how you prevent a service account from becoming a route for interactive macro use.

Endpoints where a business process needs macros

Some finance, engineering or reporting teams depend on macros that predate this control. Decide whether such machines sit inside the ML1 boundary as exceptions or outside it as a separate scope. Each exception needs a documented business justification, a named approver, and a record of who can run the macro. Confirm with the business owner whether the macro can be replaced, moved to a trusted location or signed, because those options change the evidence set at higher maturity levels.

Email attachments and internet downloads

The control requires that macros in files originating from the internet are blocked, so the boundary must cover every path that brings Office files in from outside. Map mail gateways, web downloads, cloud sync clients and removable media. Each path may tag files differently through the Mark of the Web or other markers, and the block only works where the tag survives. Test a macro-enabled file from each source and record whether the block applies.

File shares and collaboration locations

Files moved from a share or synchronized library may lose their internet origin marker, which can weaken the block. Decide whether internal file shares, SharePoint or OneDrive libraries and network drives are in scope as file sources, and whether they are treated as trusted locations. Trusted locations are an ML3 concept, so at ML1 they should not be used to bypass the internet block. Record which repositories hold Office files and who can write to them.

Who owns the boundary decision

ASD's profiles set the control objectives, but the system boundary is an organizational decision that should be approved and documented before testing begins. Record the scope statement, the justification for each exclusion, and the owner who signs it. An implementation partner can prepare the inventory and test evidence, but the organization owns the boundary and any independent assessor will test the scope the organization declares. Confirm the statement is consistent with your risk register and asset inventory.

How an assessor tests each ML1 macro control

This table compares the four ML1 macro controls by what the assessor checks, how the test is run, the evidence requested and the findings that usually cause gaps. Read each row as a test plan you can rehearse before the assessment starts. The main takeaway is that settings on paper are not enough: assessors look for the setting applied on sampled endpoints and for exceptions and local overrides that undo it.

Control	What the assessor checks	Test approach	Evidence requested	Common findings
ISM-1671: macros disabled for users	Macros are disabled for human users who lack a documented business requirement	Inspect the group policy or endpoint management macro setting, then sample standard user endpoints to confirm it is in force	Macro policy export, list of users with approved macro requirements, sign-off records for each	Macros enabled for a group with no approval record; business justification dated after enablement
ISM-1488: internet-sourced macros blocked	Macros in files marked as coming from the internet are blocked from running	Download a test file with a macro from an internet source, open it on a sampled endpoint and record whether the macro runs	Test file, screenshot or log of the blocked attempt, configuration showing the block setting	Block setting absent on some device groups; files from file shares or email attachments bypass the mark
ISM-1672: macro antivirus scanning	Antivirus scanning of macros is enabled in Microsoft Office and in the endpoint protection product	Inspect the Office and antivirus configuration, then sample endpoints to confirm scanning is active	Antivirus policy export, scanning status per endpoint, recent detection or test record	Scanning turned off in Office settings; endpoint protection excluded for certain macro-enabled file types
ISM-1489: settings locked from users	Standard users cannot change macro security settings in the Office Trust Center	Sign in as a standard user on a sampled endpoint and attempt to change the macro setting; record the result	Standard user test record, policy showing the setting is locked, list of administrators who can change it	Users hold local administrator rights and can change settings; registry values overwritten by a local profile

How to implement the ML1 macro controls, step by step

This sequence moves an organization from unrestricted Office macros to a state where only documented exceptions can run macros, and where that state is locked against user change and backed by evidence an assessor can test.

Inventory macro-dependent workflows and business needs
Start by identifying which Office files, templates and add-ins rely on macros today. Business owners and application owners confirm each workflow, its users and why a macro is needed. Record each justified case in an exception register with the named owner, the affected user group and the review date set by your own policy. The step is done when every macro-dependent workflow either has a documented business requirement or is scheduled for removal. Ask your implementation partner to help with discovery, but the business owners must approve each exception.
Set the default to disabled for human users
Configure Office so that macros are disabled for human users by default, with the exceptions from the register applied only to the named groups. Apply the policy through your central management tooling, not by asking each user to change a setting. Export the resulting configuration so that the policy state can be compared against the register. The step is done when a test account outside the exception groups cannot run a macro and the exported configuration matches the register.
Block macros in files originating from the internet
Configure Office so that macros in files marked as coming from the internet are blocked, even for users who otherwise have macros enabled. Test the setting with a macro-enabled file downloaded through a browser and an email attachment, since both paths mark the file differently. Keep the test results and the configuration export as evidence. The step is done when test files from both sources are blocked and the policy is applied to all managed endpoints in scope.
Enable macro antivirus scanning in endpoint protection
Turn on macro scanning in the endpoint protection product that covers Office applications, so that macros are inspected before they run. Confirm the scan policy is applied to every managed endpoint and that detections are reported to a central console. Test with a harmless sample macro that the scanner flags as expected. The output is the scan policy export and the test record. Your endpoint vendor's documentation should be the reference for the exact setting name in your version.
Lock macro security settings through central management
Use central management to lock the Trust Center macro settings so that human users cannot change them. Verify on a standard user account that the settings are greyed out or that changes are reverted on the next policy refresh. Record the lock evidence, such as a screenshot or a policy compliance report from the management console, together with the date of the test. The step is done when a standard user cannot alter macro security settings and the lock is shown as applied on every endpoint in scope.
Confirm the controls against the ISM profile and keep evidence current
Map the four macro controls (ISM-1671, ISM-1488, ISM-1672 and ISM-1489) to the configuration exports, test records and lock evidence you produced. Use the ISM OSCAL catalog to confirm the control text and tag set for your ISM version. Store the evidence with a named owner and a review schedule that your own policy sets. Because the macro exception register changes as workflows change, schedule periodic reconciliation of the register against the live configuration. The step is done when each control has evidence and an owner, and an independent assessor can trace each one to a test.

Which evidence passes an ML1 macro assessment and how to keep it current

An assessor testing macro restrictions at Maturity Level One wants to see the settings, the people who are allowed exceptions, and proof that the settings held over time. The cards below cover each artifact and the routine that keeps it accurate between assessments, since a policy that was correct on audit day can drift within weeks.

Exported Office macro policy

Export the effective Office macro configuration from your management platform, showing the disabled default for human users, the block on macros in files from the internet, macro antivirus scanning enabled, and the lock that stops users changing macro security settings. Confirm the export reflects the policy applied to devices, not only the policy drafted in the console. Schedule a monthly export to a controlled repository with a named owner, so the file in front of an assessor is never more than one cycle old.

Macro exception register

Record every user granted macros for a demonstrated business requirement, with the business justification, the approver, the scope of the exception and an expiry or review date. ISM-1671 depends on that demonstrated need, so an undocumented exception is a finding even when the technical setting is correct. Review the register at each recurring review and remove entries whose need has ended. The register owner should reconcile it against directory group membership at the same time.

Endpoint test results

Run a test on sample devices from each standard build and capture results showing whether a macro from an internet-sourced file is blocked, whether scanning fires, and whether a standard user can change the setting. Keep the test scripts and the dated output together so an assessor can repeat the check. Ask your management platform or security tooling vendor to confirm which checks they can report on directly. Run the sample again after every major build or Office update.

Change records for policy updates

Keep a record for each change to the macro policy, including the reason, the requester, the approver, the date applied and the rollback plan. Assessors look for evidence that a changed setting was authorized and that the change did not quietly weaken an ML1 control. Link each change to the exception register where it affected user access. Store change tickets in the same system as your other configuration records so the history can be produced in one request.

Recurring review records

Document a scheduled review in which the control owner confirms the policy export, the exception register, the endpoint test results and open changes still agree. Record the attendees, the findings and the actions with due dates. The review is the evidence that the control is operated, not only configured, and it is the record most likely to lapse between assessments. Set the review cadence in your control calendar and name a deputy so it continues when the owner is absent.

How self-hosted open-source tools can produce macro control evidence

Wazuh is an open-source security platform licensed under GPL-2.0-only. Its Security Configuration Assessment (SCA) module scans monitored endpoints for misconfigurations using YAML policies. Most of the shipped policies are based on CIS benchmarks, and the platform supports custom policies written for the organization's own standards. Each check can look at files, directories, registry keys and running processes, and the module reports which checks passed or failed and recommends remediation. For macro controls, the relevant idea is that a custom policy can read the Office registry values that hold macro security settings and report whether they match the expected configuration on each endpoint.

Custom registry checks: An illustrative policy could test whether the registry value controlling macro security is set to the required state for each Office application in use. The check would then show a pass or fail per endpoint.
Version-specific paths: Office stores these settings under registry paths that vary by version and deployment, so the organization must confirm which checks match its Office version before relying on results.
Baseline mapping: Shipped CIS-based checks may cover related Office hardening, which can help, but the team should confirm exactly which checks exist in its installed policy set.
Remediation output: Failed checks include recommended remediation, which gives the platform team a documented change to track and reverify.
Scan history: Repeated scans show whether a failure was fixed and when, which supports the operating evidence an assessor will ask for.

Before relying on Wazuh results as evidence, confirm the policy versions, the Office versions in scope and the scan schedule with your own environment and assessor.

What meeting the ML1 macro control costs in money and effort

This table lists the cost components of meeting the Maturity Level One macro restrictions, who is paid for each, and whether the cost is one-time or recurring. Read it to see which items you can keep in-house, which you might buy, and what to request in a quote. The main takeaway is that most ML1 macro cost sits in policy upkeep and evidence rather than in new software, especially where endpoint tooling is already licensed.

Cost component	One-time or recurring	What drives it up	How to keep it down and what to ask for in a quote
Configuration and policy engineering	One-time, with periodic rework	Number of device groups, mix of Office versions, and whether settings are enforced through group policy, Intune or another management tool	Reuse one baseline across Office versions. Ask the provider to list each setting it will lock, the platform used to enforce it, and how drift will be reported.
Business-need review and exception handling	Recurring	Number of roles that claim a need for macros, and absence of a written request and approval path	Limit exceptions to named roles with a documented owner and review date. Ask who approves exceptions, how long they last, and who records them.
Endpoint protection and management licenses	Recurring, often already owned	Number of endpoints, feature tier needed for macro scanning and settings enforcement, and whether the licence bundle already covers them	Check first whether current licences cover macro antivirus scanning and tamper protection. Ask any vendor to confirm which licence tier includes each feature in writing.
Monitoring and configuration assessment tooling	Recurring if commercial, typically none for self-hosted open source	Commercial per-endpoint licensing, and the effort to run and update a self-hosted server	Self-hosted open-source options such as Wazuh (GPL-2.0-only) or Fleet (MIT) can remove licence spend for this check, but you pay for hosting, upkeep and staff time. Ask for the hosting model and update responsibilities.
Evidence collection and upkeep	Recurring	Number of devices sampled, frequency of reporting, and whether evidence is gathered by hand	Automate the export of policy pass and fail results and keep dated records. Ask the provider what evidence it will produce each cycle and in what format.
Assessor sampling and review	Per assessment	Number of endpoints and business units the assessor samples, and how well evidence is organized	Prepare a clear evidence index before the assessor arrives. Ask your assessor for its sampling approach before fieldwork starts.
External review or testing, if bought	Optional, one-time or recurring	Scope of the review, whether it tests macro behavior on real endpoints, and whether it is repeated	Buy only where internal staff lack the skill to test. Ask for a fixed scope, named deliverables, and a clear statement of what the review does not cover.

Where macro controls usually fail an assessment

Most macro failures at Maturity Level One are not missing settings. They are settings that exist on one machine, for one application or for one week, with no record that anyone checked them. Each card below names a gap an assessor is likely to find and the action that closes it.

Default is off, overrides are on

The Group Policy or Intune baseline disables macros, but local users or legacy profiles keep an override that re-enables them for a single document type or workstation. An assessor testing ISM-1671 will look at the effective setting on sampled endpoints, not the policy document. Close this by reading the resolved configuration on a sample of machines and removing any local or per-user override that conflicts with the central baseline.

Exceptions without approval records

Some business units need macros for finance models or internal tools, so exceptions get granted verbally or by email and never recorded. ISM-1671 allows macros only where there is a demonstrated business requirement, so the requirement and its approver must be documented. Close this by keeping a register of each exception with the business justification, the named approver, the affected accounts and a review date, and by checking that each enabled macro maps to an entry.

Internet blocking covers one application

Mark-of-the-web blocking is often configured for Word but not Excel, PowerPoint or Visio, so a macro file opened from a download in one product still runs. ISM-1488 applies to macros in files from the internet across the Office suite, so an assessor will open test files in each application. Close this by testing a file downloaded through a browser in every Office application in use and confirming that macros are blocked in each one.

Scanning off on some endpoints

Macro antivirus scanning under ISM-1672 is enabled on the main image but not on machines built from an older image, rebuilt laptops, or endpoints enrolled outside the management tool. Coverage gaps like these only show up when the population is counted against the scanning configuration. Close this by reconciling the device inventory against the endpoints reporting the scanning setting, and treating any unreported device as non-compliant until it is fixed.

Settings drift after updates

An Office feature update, a new management profile or a new security baseline can reset macro settings or add a policy that conflicts with the existing one. ISM-1489 requires that human users cannot change macro security settings, and that protection holds only if the locked state survives change. Close this by re-checking the resolved macro settings after every Office update and profile change, and by alerting when a monitored setting leaves its expected value.

Evidence is a one-time screenshot

A screenshot of a policy editor proves the setting existed on the day it was taken, not that it held across the period an assessor covers. Repeatable exports of resolved settings, compliance results and exception records are what an assessor can re-check. Close this by scheduling an export of the macro policy state from each endpoint population, retaining the dated outputs, and mapping each output to ISM-1671, ISM-1488, ISM-1672 and ISM-1489.

Questions buyers ask about the ML1 macro control

How much effort does the ML1 macro control take for a small versus a large Office estate?

Effort scales with the number of users, the number of device builds and how many business processes depend on macros today. A small estate with one standard Office build and a short list of approved macro-enabled files can often be configured in a few focused changes. A large estate adds work in several places: inventorying which teams rely on macros, deciding who keeps a documented business need, pushing settings through group policy or device management to every build, and handling exceptions. The biggest driver is usually not the settings themselves but the number of macro-dependent workflows that must be found, justified and moved to a controlled alternative. Ask any provider to break its quote down by device count, build count and number of macro-dependent workflows.

Can we implement the ML1 macro control in-house?

Often yes, if your endpoint management team already controls Office configuration centrally and has a change process that can record the settings and exceptions. The work is mostly configuration, testing and documentation rather than new technology. The points where in-house teams usually struggle are the business-need review, which requires people outside IT to confirm which macros are genuinely required, and the ongoing checks that prove settings stay locked after updates or new builds. Decide early whether you have the capacity to run those checks every month, because an implementation that works on the day of rollout but drifts afterwards will not satisfy an assessor.

What does the work need from IT, security and business owners?

Each group owns a different part of the control:

IT owns the configuration: the Office policy settings, the deployment mechanism and the proof that devices receive them.
Security owns the monitoring, the scanning confirmation and the exception and risk decisions.
Business owners own the justification for any macro that must keep running, including who approves it and when it is reviewed.

The organization remains accountable for all three. An implementation partner can prepare the configuration, evidence and records, but the business owners must still make and sign the decisions about which macros are needed.

Does ASD issue a certificate for the Essential Eight or for ML1?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, so there is no ASD certificate to obtain for Maturity Level One. Maturity is established by assessing how each strategy is implemented and whether it works in practice against the maturity model published by the Australian Signals Directorate. Organizations that need independent assurance should engage a suitably qualified assessor, and should confirm with their customer or regulator what form of evidence or assessment they will accept. Any provider claiming to issue an Essential Eight certificate should be questioned closely.

Does the Essential Eight profile data in OSCAL help us track the macro control?

It can help, provided you use it as a structured reference rather than a finished compliance answer. ASD publishes the Information Security Manual in OSCAL with Essential Eight baseline profiles, and the ML1 macro controls are identified by their ISM IDs, such as ISM-1671, ISM-1488, ISM-1672 and ISM-1489. Importing those identifiers into a governance, risk and compliance tool lets you map each control to its configuration, owner and evidence, and to track status over time. The mapping itself still has to be written by your team or provider, and you should confirm the exact profile version your assessor expects. Fleet policies and Wazuh configuration assessment checks can supply some of that evidence, but each check must be validated against your own macro settings.

What should we ask an implementation partner for in a fixed-scope quote?

A fixed-scope quote should state the exact scope in writing before work starts. Ask the partner to specify:

the number of devices, Office builds and user groups covered;
which macro settings will be configured and through which management tool;
how the business-need review will be run and who signs off;
what evidence will be delivered, such as configuration exports, scan results and monitoring reports;
what is excluded, including any changes to other Essential Eight strategies;
how post-rollout checks and handover will be handled.

Confirm in writing that the partner prepares systems and evidence, and that independent assessors remain responsible for any assessment or report.

Who does what: your team, an implementation partner and the assessor

Your organization owns the Essential Eight control environment. For macros, that means deciding which staff have a demonstrated business requirement to run macros, approving any exception, and accepting the residual risk of each one. Those decisions cannot be delegated to a vendor or partner because they describe how your business operates. Your team also owns the macro settings in production, the records that show who approved what, and the response when a control drifts.

Business-need decisions: Name the roles or users who may run macros, and record the justification for each.
Exception approvals: Sign off on any exception to the default-disabled setting, with a review date.
Control ownership: Assign an accountable owner for the macro settings and for the evidence that proves them.
Operational response: Investigate failing endpoints and decide on remediation or documented acceptance.
Policy and records: Keep the approved configuration baseline and the change history.

Check that every macro exception has a named approver, a stated reason and a review date that your team, not the partner, controls.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems and evidence for Restrict Microsoft Office macros at Maturity Level One, working inside the client's own infrastructure. The organization keeps ownership of its controls, and any assessment of maturity is carried out by an independent assessor, not by DeployOpen.

How we scope

Confirm which Microsoft Office estates, user groups and endpoints fall inside the macro restriction scope.
Record which users have a documented business need for macros, so exceptions are explicit and bounded.
Agree the written scope, deliverables and timeline before work starts, since engagements are fixed-scope.
Identify which ISM controls for ML1 macros apply to each environment and which owner holds each one.

How we build

Configure Office macro settings to disabled by default, with the internet-sourced macro block enforced.
Enable macro antivirus scanning and lock macro security settings so human users cannot change them.
Set up endpoint configuration checks, such as Wazuh policies or Fleet queries, to report drift from the target state.
Test each control on representative devices and record pass or fail results before rollout.

How we hand over

Deliver configuration baselines, policy files and test results that map each ML1 macro control to its evidence.
Document the exception process for business-need macros, including approval records and review dates.
Provide runbooks so the organization's own staff can reproduce the configuration and check it on demand.
Give the assessor a clear evidence index. Confirm with the assessor which artifacts they will accept before handover.

How we support

Ongoing support, upgrades and continuous checks are available as a retainer after the initial scope is delivered.
Review configuration drift and policy results on a schedule agreed in the written scope.
Update baselines when Microsoft changes Office settings or when ASD revises the ISM profiles.
Confirm with your assessor and your own environment before relying on any single tool's output as evidence.