What Restrict Microsoft Office macros ML3 requires in practice
An assessor or internal audit has asked for evidence that Office macros are restricted at Maturity Level Three. The requirement is only macros running in a sandboxed environment, from a Trusted Location, or digitally signed by a trusted publisher may execute, as set out in ISM-1674 (Microsoft Office macros are only allowed to execute in a sandbox, from a Trusted Location or if digitally signed by a trusted publisher). Macros remain a common initial access route because a document that looks like an invoice or report can carry code that runs as soon as a user enables content. At ML3, the question is no longer whether macros are blocked by default but whether every macro that does run has passed a documented trust decision.
Compared with ML2, the new work sits in three places. ISM-1890 requires that macros are checked for malicious code before they are signed or placed in a Trusted Location, so the vetting step must exist and leave a record. ISM-1487 limits write and modify rights on Trusted Locations to privileged users responsible for checking macros, which means the folder permissions must match the approval process. ISM-1675 and ISM-1891 stop users from enabling macros signed by untrusted publishers, or signed with anything other than V3 signatures, through the Message Bar or Backstage View. ISM-1676 requires the list of trusted publishers to be validated at least annually. Confirm the exact configuration method for your Office estate with the current ISM OSCAL catalog and Microsoft's own documentation before you write the procedure.
The setting itself is usually the easy part. The harder work is governance and evidence: a named owner for vetting, a written approval record for each macro or publisher, restricted rights on the Trusted Location folders, a dated annual review of the publisher list, and proof that users cannot override the policy. Ask your assessor which artifacts they will sample, such as approval tickets, folder access reports and the review sign-off, and build those records before the assessment begins. The ISM OSCAL catalog at the ASD mirror lets you map each of the six ML3 controls to the evidence you already hold.
Which macros, endpoints and people fall inside the ML3 scope
Maturity Level Three changes how macros run, not only which settings are switched on, so the scope decisions below determine how much of the estate needs signing, vetting and review. Each card names one decision and what it does to the work. Settle them in writing before the first configuration change is made.
Office versions and platforms
Start by inventorying every Microsoft Office version and platform in use, including Windows desktops, any Mac or mobile clients, and Office installed on servers or virtual desktops. The ML3 trusted publisher and signature controls depend on the Office client supporting them, so an older build can widen the remediation list. Ask your team to confirm which builds are supported for the settings in ISM-1675 and ISM-1891 before scoping the rollout.
Users who send or receive macros
Identify the business units whose workflows still depend on macro-enabled documents, such as finance models, legacy reporting or line-of-business templates. Each group needs a documented reason for macros to run, a named owner and a path to the sandbox, Trusted Location or signed macro that will replace the current workflow. Populations you cannot justify are the ones most likely to push macros back into the default-enabled state.
Trusted Location shares
Every network share, local folder or SharePoint library configured as a Trusted Location must be listed and its write permissions reviewed. ISM-1487 limits writes to privileged users responsible for checking macros, so any share where general staff can save files effectively becomes a trusted execution path. Expect the effort here to scale with the number of shares, and confirm each one has an owner and a documented purpose.
The macro signing and vetting team
Decide which people and roles sign macros, perform the malicious code checks required before signing or placing code in a Trusted Location, and maintain the trusted publisher list. This team needs documented separation from requesters, a defined review process and enough capacity for the volume of macro requests. Ask who holds the signing keys and how their access is logged, because a shared or poorly controlled signing identity undermines the whole model.
Third-party and vendor macros
Macros supplied by vendors, partners or software packages often arrive unsigned, from unknown publishers, or embedded in files received from outside the organization. Each source needs a decision: obtain a signed version from the vendor, rebuild the function inside an approved template, or retire it. Vendor macros can add significant effort because the organization cannot always edit the code it is asked to sign, so raise this with suppliers early.
Annual trusted publisher review
The trusted publisher list must be validated at least once a year under ISM-1676, which makes it a recurring commitment rather than a one-off project. Schedule the review, record who approved each publisher and retain the evidence of the check. Plan for this in the operating budget, since the review cost recurs for as long as the ML3 position is maintained.
How an assessor tests macro restrictions at ML3
This table pairs each ML3 macro control with the test an assessor typically runs, the evidence requested and the findings that most often cause gaps. Read it as a checklist for preparing evidence before fieldwork begins, since each row names the artifact the assessor will ask to see.
| Control and test | Evidence requested | Common findings |
|---|---|---|
| ISM-1674: Only sandboxed, Trusted Location or trusted-signed macros run. Review Group Policy or Intune settings for macro execution rules, then sample endpoints for effective settings. | Exported GPO or Intune policy with assignment scope, plus effective-setting results from sampled devices. | Policy exists but is not assigned to all Office user groups, or a sampled device shows a conflicting local setting. |
| ISM-1890: Macros are checked for malicious code before signing or Trusted Location placement. Review the signing and vetting record for a sample of macros. | Vetting records with reviewer, date, scan results and approval for each signed or trusted macro. | Macros signed or placed in Trusted Locations with no vetting record, or records that do not show a scan result. |
| ISM-1487: Only privileged users checking macros can write to Trusted Locations. Inspect file system and share permissions on each Trusted Location. | Access control lists for every Trusted Location path and the list of accounts with write rights. | General user or broad domain group holds write access, often inherited from a parent folder. |
| ISM-1675 and ISM-1891: Users cannot enable untrusted-publisher macros or non-V3 signatures through the Message Bar or Backstage View. Test on sampled endpoints. | Configuration showing the Message Bar and Backstage options are locked, plus test results from a sampled user profile. | Users can still enable macros from the Message Bar, or signatures other than V3 are accepted. |
| ISM-1676: The trusted publisher list is validated at least annually. Review the validation record and the list itself. | Dated review record, the trusted publisher list at review time, and the reviewer's sign-off. | No review in the last 12 months, or publishers on the list that no longer have a business owner. |
Sequencing ML3 macro controls so each step produces evidence
This sequence moves an organization from ML1 and ML2 macro restrictions to ML3 controls, with each step closing on a record an assessor can inspect. Work runs in order because the vetting and signing steps depend on knowing which macros exist and where they come from.
Confirm ML1 and ML2 macro restrictions are in place
Before adding ML3 controls, confirm the ML1 restrictions (macros disabled for users without a business need, internet-sourced macros blocked, macro antivirus scanning on, macro settings locked) and the ML2 block on Win32 API calls are working on every in-scope endpoint. The IT or endpoint team checks configuration against the ISM Essential Eight profiles and exports the policy state from the device management tool. Done means the export shows no endpoint outside the approved baseline, and any exceptions are recorded with an owner and a reason.
Inventory existing macros and their sources
Identify every macro-enabled document, template and add-in in use, along with where each one lives and who maintains it. Security and business owners work together on this, and scanning tools or file share audits can help find candidates. The output is a macro register listing file location, author or publisher, signing status and business owner. Done means every macro that users rely on appears in the register, and any unknown source is flagged for review before it can be signed or trusted.
Define the macro vetting and signing process
Write the procedure that decides whether a macro may be signed or placed in a Trusted Location. It should require a malicious code check before any signature or location approval, name the people who perform and approve the check, and state what happens when a macro fails. The security function owns the procedure and the approvers sign it off. Done means a written procedure exists and each approved macro has a vetting record showing the reviewer, date, scan or review method and the decision.
Restrict Trusted Location write access to privileged users
Configure Trusted Location folders so that only privileged users responsible for checking macros can write to or modify them, and remove write access from general user groups. Administrators make the change through group policy or the device management platform, then test that a standard user account cannot add or edit a file in those locations. Done means a permissions export for each Trusted Location shows write rights limited to the named privileged group, and the group membership list is retained.
Lock the Message Bar and Backstage View options
Set policy so users cannot enable macros signed by an untrusted publisher, or signed with anything other than V3 signatures, through the Message Bar or Backstage View. The administrator applies the settings centrally and confirms that the options are greyed out or blocked for a test user. Done means a policy export shows the settings locked, and a test record shows an untrusted or non-V3 signed macro cannot be enabled by a standard user.
Validate the trusted publisher list
Review the list of trusted publishers held in Microsoft Office and remove any publisher that has not passed the vetting procedure. Each remaining entry should match a publisher identified in the macro register and a vetting record. The security owner performs the review and records the result. Done means a dated validation record lists each publisher, the evidence supporting its trust and the person who approved it.
Set the annual review of trusted publishers
Schedule the trusted publisher validation to repeat at least once a year, and assign an owner, an evidence location and a process for removing publishers that no longer pass review. Add the task to the recurring control calendar so that the next review is visible to assessors. Done means the calendar entry, the owner and the prior validation record are all retained, so the annual cycle can be demonstrated across at least one completed review.
How vetting before signing works and why it is the control most often missed
ISM-1890 requires that macros be checked for malicious code before they are signed or placed in a Trusted Location. For a Maturity Level Three assessment, the check itself matters less than the record that proves it happened. An assessor will ask who reviewed each macro, what they looked at, when the review occurred, and what the outcome was. A macro that was signed months ago with no retrievable review record fails the control in practice, even if the code was clean. Organizations often miss this because the signing step is quick and automated, while the vetting step is a manual decision that nobody logs.
Start by naming the people who perform the check. The organization owns this decision, and the reviewers should be separate from the developers who wrote the macro, so that no one approves their own code. Privileged users responsible for checking macros are also the only users who may write to Trusted Locations under ISM-1487, so the same roles usually govern both the vetting and the placement of approved macros. Document these roles and the access granted to each. Confirm with your own security team how reviews are assigned and how the review tooling is selected, since ASD's publications describe the requirement without prescribing a specific method.
Protect the signing key as carefully as the approval it represents. Whoever holds the private key can make any macro appear trusted, so the key should sit with a restricted set of named custodians, be stored in a hardware-backed or managed key store where your environment supports it, and be used only after a review record exists. Keep the record in a tamper-evident store separate from the people who sign, covering the macro hash, the reviewer, the scan or review result, the signing date and any later revocation. Consider writing a short internal procedure, then test it by asking an independent person to trace one signed macro back to its review. Confirm the exact key management options with your Microsoft and PKI teams before you commit to a design.
Evidence that passes an ML3 macro assessment
An assessor testing macro restrictions at Maturity Level Three will look for proof that the settings are enforced, that trusted locations and publishers are controlled, and that someone reviews them on a schedule. Each card below is one artifact that answers one of those checks, and together they show the settings, the people who manage them and the review history.
Exported macro policy settings
A current export of the Office macro policy from the managed fleet, showing that macro settings are locked so users cannot change them. The export should cover the ML3 controls ISM-1674 and ISM-1675 (or ISM-1891 where it applies), with the policy scope and assignment groups visible. Check that the export comes from the live configuration rather than a template, and that a sample of endpoints reports the same values. Re-export after every change to the policy and at each assessment date.
Trusted Location access control export
An access control list export for each Trusted Location, showing that only privileged users responsible for checking macros can write to or modify it, as ISM-1487 requires. Record the group names, not only user names, and confirm that standard users and service accounts do not appear with write rights. Keep the export alongside the change history for each location, so an assessor can match each addition to a named approver.
Macro vetting and signing log
A dated record for each macro placed in a Trusted Location or signed by a trusted publisher, showing the malware check performed under ISM-1890 before signing, the tool or method used, the result and the approver. Include macros that were rejected, because a log with only approvals suggests the check was not applied. Store the log in a system with restricted write access, and review it against the Trusted Location history each quarter so gaps are caught before an assessor finds them.
Trusted publisher list with validation record
The list of trusted publishers held in Office, with a validation date, the name of the reviewer and the outcome for each entry. ISM-1676 requires validation at least annually, so the record should show that the review happened within the last twelve months and that publishers no longer needed were removed. Ask the reviewer to sign off with the date, and keep the previous version so an assessor can see how the list changed.
V3 signature configuration
Evidence that the Office configuration only allows macros signed with V3 signatures, and that users cannot enable untrusted-publisher or non-V3 macros through the Message Bar or Backstage View, as ISM-1891 expects. Capture the setting value and a test result from a managed endpoint showing a non-V3 signed macro is blocked. Confirm this against the Office build in use, since signature support depends on the product version, and retest after Office updates.
Sample endpoint compliance reports
Periodic reports from endpoint configuration tools showing whether a sample of devices pass or fail the macro policies, with failing devices and remediation dates recorded. Wazuh Security Configuration Assessment and Fleet policies can both produce this kind of output, and Fleet's policies page shows passing and failing devices per policy. Choose a sample across departments and device types, and retain the reports with their scan dates so the assessor sees a pattern over time rather than one clean snapshot.
What meeting ML3 macro controls costs in money and effort
This table breaks down the cost and effort components of meeting the ML3 macro controls, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to separate work your own staff can absorb from work worth contracting out. No prices are given because none were supplied for this topic.
| Cost component | Who carries it | One-time or recurring | What drives it |
|---|---|---|---|
| Microsoft licensing for management tooling | Organization, under licenses it already holds | Recurring (per existing license term) | Confirm with Microsoft which tier includes the Intune and Entra features you plan to use; add-on licenses change the figure |
| Engineering time to configure and lock macro settings | Internal staff or implementation partner | One-time, with later changes | Number of Office versions, device groups and policy layers to reconcile |
| Trusted Location setup and access control | Internal staff or implementation partner | One-time, then recurring when locations change | Number of Trusted Locations and how many privileged users must write to them |
| Vetting new macros before signing or placing in Trusted Locations | Internal security or development staff | Recurring | Macro volume and how often business owners request new or changed macros |
| Annual validation of the trusted publisher list | Internal compliance or security staff | Recurring, at least annually | Number of trusted publishers and how many have changed certificates or ownership |
| Monitoring and evidence upkeep | Internal operations staff; tooling may be self-hosted | Recurring | Endpoint count, frequency of configuration checks and how evidence is stored and dated |
| External review of the vetting process | Independent reviewer or consultant, if engaged | Optional, recurring if used each cycle | Scope of macros reviewed and whether the process is documented well enough to sample |
| Assessor sampling during assessment | Organization for preparation; assessor for testing | Recurring per assessment cycle | Quantity of macros, publishers and locations an assessor selects to test |
| Self-hosted tooling for configuration checks and inventory | Organization for hosting and staff time | Recurring infrastructure and admin effort, lower license spend | Platform size, hosting model and whether the team has skills to run it; confirm current license terms of each tool |
Who owns macro controls and what an implementation partner can take on
Your organization owns the controls. The decisions that define which macros may run are business and security decisions, and they cannot be delegated to a vendor or a consultant. Your security function accepts the risk of any macro that runs, and it should be able to show who made each call and when.
- Trusted publisher decisions: Approve which publishers appear on the trusted publisher list, and record the reason for each addition and removal.
- Signing key custody: Control the private keys used to sign macros, including who can request a signature, where keys are stored and how compromise would be handled.
- Vetting sign-off: Accept the result of the malicious code check that ISM-1890 requires before any macro is signed or placed in a Trusted Location.
- Trusted Location ownership: Name the privileged users allowed to write to Trusted Locations under ISM-1487, and review that list on a schedule.
- Annual review: Own the yearly validation of the trusted publisher list required by ISM-1676.
Before you engage anyone, confirm that these owners are named in writing and that the approval records will exist in your own systems. Review the Essential Eight maturity model to confirm the ML3 requirements your team must meet.
An implementation partner prepares systems and evidence. DeployOpen, for example, configures settings, builds monitoring for the controls and organizes the records your team and the assessor will use. The partner does not decide which macros are trusted and does not sign off on vetting.
- Configuration work: Apply the Office macro settings that block macros by default, restrict execution to sandboxed, Trusted Location or trusted-signed macros, and prevent users from enabling untrusted or non-V3 signatures through the Message Bar or Backstage View.
- Evidence pipeline: Build compliance checks, such as a configuration assessment on endpoints, so that the state of each setting can be shown over time.
- Vetting record template: Prepare a template that captures the macro, the checks run, the result, the approver and the signing decision, for your team to complete.
- Trusted Location access: Set up the access controls and change logging around Trusted Locations so that only named privileged users can change them.
- Handover documentation: Document each setting, its owner and the recurring tasks, so your team can operate the controls after the engagement ends.
Ask any partner for a written scope that lists which ISM controls it will configure and which evidence it will hand over. Confirm that it will not sign macros or issue assurance on your behalf.
The auditor is independent of both your team and the implementation partner. It tests whether the ML3 macro controls operate as described, samples endpoints and records, and reaches its own conclusion about maturity. An auditor reports on the Essential Eight maturity level it finds. The Essential Eight is a set of mitigations, not a certification scheme, so there is no ASD certificate for the strategy or for any level.
- Endpoint sampling: Select a sample of endpoints and check that the macro settings are in force and cannot be changed by users.
- Record testing: Examine the vetting records, trusted publisher list, annual review evidence and Trusted Location change logs.
- Effectiveness testing: Check whether the controls work in practice, not only whether they are configured.
- Independent conclusion: Form its own view of the maturity level and document the reasons for it.
- Reporting limits: Issue a report of findings. It does not issue a certificate, and it does not design or configure your controls.
Before engaging an auditor, ask which assessment method it uses and what evidence it expects for each ISM control in scope.
Questions buyers ask about ML3 macro restrictions
Do we need to reach Maturity Level Two before we attempt Maturity Level Three macro controls?
In practice, yes. The ISM v2026.09.4 Essential Eight profiles show that every ML1 control is also in ML2, and all but three ML2 controls are also in ML3, where ML3 replaces ISM-1691, ISM-1695 and ISM-1873 with stricter versions. That means the ML3 macro work sits on top of the ML1 and ML2 baseline rather than replacing it. Confirm the exact control set for your target level in the ISM OSCAL profiles before you plan scope, because a gap in ML2 will show up as a gap in ML3 evidence.
How long does ML3 macro restriction take, and what drives the timeline?
No fixed duration is supplied for this work, so treat any number you hear with caution and ask for your own estimate. The main drivers are how many Office deployments you run, how many macro-enabled documents and add-ins exist in production, how many trusted publishers and Trusted Locations need to be justified, and whether your endpoints already report configuration state centrally. Macro inventory is often the longest step because business owners must confirm which macros are genuinely needed. Ask the partner to break the plan into inventory, policy build, pilot, rollout and evidence collection, and to name the dependencies in each phase.
Can our own team implement ML3 macro controls in-house?
Often yes, if you already manage Office policy centrally and have people who can read the ISM controls and test the result. The work is mostly configuration, process and evidence, not new software. The harder parts are agreeing who may write to Trusted Locations (ISM-1487), setting up the vetting process before signing (ISM-1890), and keeping the trusted publisher list current. Teams without an internal assessor-facing owner often find the evidence trail harder than the configuration. An outside partner can prepare systems and evidence, but your organization still owns each decision and the control itself.
What does the annual trusted publisher review involve?
ISM-1676 requires that Microsoft Office's list of trusted publishers is validated at least annually. In practice, the review checks each publisher still has a business reason to be trusted, that its certificates are valid, and that no publisher has been removed or compromised. It also confirms that the list matches what the vetting process approved, and that changes were made by the privileged users allowed to modify Trusted Locations and trust settings. Keep dated records of who reviewed the list, what changed and why, because the assessor will ask to see the review rather than hear that it happened.
Can a partner sign macros on our behalf?
No. The organization owns the decision to trust a macro or a publisher, and that decision must follow your own vetting process under ISM-1890. A partner can help build the vetting workflow, prepare the signing and trust configuration, and document the evidence, but signing and approving publishers stays with your staff. Only privileged users responsible for checking macros should be able to change Trusted Locations (ISM-1487). An independent assessor, not a partner, decides whether your controls meet the maturity level.
What should we ask a partner to include in a quote for ML3 macro work?
Ask for a written scope that names the systems covered, the Office versions and deployment methods in use, and the ML3 controls included (ISM-1674, ISM-1890, ISM-1487, ISM-1675, ISM-1891 and ISM-1676). The quote should separate one-time work, such as inventory, policy build and pilot, from recurring work, such as the annual publisher review and ongoing evidence collection. Ask which tools they would use for configuration assessment, for example Wazuh Security Configuration Assessment, and whether those tools are yours to keep. Confirm who performs the independent assessment, since the partner cannot issue it, and what handover documentation you receive.
Which parts of the ML3 macro work usually stay with the organization?
Business decisions stay with you: which macros are needed, which publishers you trust, who may modify Trusted Locations, and when a macro is retired. Operational ownership also stays internal, including running the annual trusted publisher review and responding when a policy check fails. A partner can configure endpoints, build checks and collect evidence, but the controls keep running after the engagement ends. Plan internal owners and a recurring calendar before work starts so the maturity level holds once it is reached.
Where ML3 macro implementations usually fall short
Maturity Level Three macro controls fail in predictable places: the signature rules are loose, the trust settings can be changed by people who should not change them, and the paperwork behind trust decisions is missing. Each card names one gap an assessor is likely to find and the check that closes it.
V3-only signatures not enforced
ISM-1675 and ISM-1891 require that users cannot enable macros signed by an untrusted publisher or signed with anything other than V3 signatures through the Message Bar or Backstage View. Many estates block untrusted publishers but still allow older signature versions to be enabled by a click. Test this on a clean profile with an older-signed macro document and confirm the prompt offers no way to run it.
Trusted Locations writable by general users
ISM-1487 limits write and modify rights on Trusted Locations to privileged users responsible for checking macros. A common gap is a shared network folder listed as trusted that inherits broad write permissions from a parent share. Any user who can drop a file there can run macros with trusted status. Review the NTFS and share permissions on every trusted path and confirm that only the macro checking group holds write rights.
Vetting not recorded
ISM-1890 requires that macros are checked for malicious code before they are signed or placed in a Trusted Location. Teams often perform the check informally, so when an assessor asks who reviewed a macro, when, and against what, there is no answer. Keep a register that records the macro's hash, the reviewer, the date, the method used and the decision. Without that record, the control cannot be shown to operate.
Publisher list never revalidated
ISM-1676 requires that the list of trusted publishers is validated at least annually. In practice the list is built once during rollout and then left alone, so certificates expire, publishers change ownership, and revoked signers remain trusted. Schedule a yearly review with a named owner, compare each entry against current signing certificates, and remove anything that can no longer be verified. Retain the dated review record as evidence.
Macros allowed through Message Bar prompts
The Message Bar and Backstage View can offer an Enable Content button that bypasses the intended restriction. ISM-1675 and ISM-1891 expect those paths to be closed for macros that should not run. Configure the Office policies so that the prompt cannot enable untrusted or non-V3 content, then test by opening a sample document from email and from a download and confirming the option is absent or ineffective. Record the test result for the assessor.
Sandbox claims not tested
ISM-1674 allows macros to run only in a sandboxed environment, from a Trusted Location, or when signed by a trusted publisher. Some organizations state that macros run in a sandbox without confirming that the sandbox actually isolates them from the host, the network and the file system. Ask for the sandbox configuration, then run a controlled macro test that attempts those actions and capture the outcome. A stated sandbox without test evidence is a finding waiting to happen.
How DeployOpen prepares macro controls and evidence for an assessment
DeployOpen plans and implements the Maturity Level Three macro controls inside your own Microsoft environment and self-hosted tooling, then prepares the configuration records and evidence an assessor will ask for. Your organization owns its controls and its maturity claim, and only an independent assessor can confirm the level reached.
How we scope
- Engagements are fixed-scope, with the macro controls, systems and deliverables agreed in writing before work starts.
- The written scope lists which Office applications, user groups and Trusted Locations are covered at ML3.
- Scope also names the trusted publisher list, its owner and the annual validation date the organization will commit to.
How we build
- Configure macro execution so only sandboxed, Trusted Location or trusted-signed macros may run, mapped to ISM-1674.
- Set up the malware-check and signing workflow that vets macros before they are signed or placed in Trusted Locations.
- Restrict write access to Trusted Locations to named privileged users, and monitor endpoints with Wazuh or Fleet policies.
How we hand over
- Deliver configuration records, policy exports and endpoint pass or fail reports that show each ML3 macro control in place.
- Document the vetting procedure, trusted publisher review record and the annual validation task with its owner.
- Provide a control-to-evidence map keyed to ISM control IDs so an assessor can trace each claim to a source.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover re-validating the trusted publisher list, reviewing policy drift and updating configurations when Office changes.
- Ask any provider to confirm which assessment evidence they prepare and confirm that the independent assessor makes the final determination.
