Helping users stay safe: Blocking internet macros by default in Office
Published Feb 07 2022 09:07 AM 234K Views

Updated July 20, 2022:

We’re resuming the rollout of this change in Current Channel. Based on our review of customer feedback, we’ve made updates to both our end user and our IT admin documentation to make clearer what options you have for different scenarios. For example, what to do if you have files on SharePoint or files on a network share. Please refer to the following documentation:

•            For end users, A potentially dangerous macro has been blocked 

•            For IT admins, Macros from the internet will be blocked by default in Office


If you ever enabled or disabled the Block macros from running in Office files from the Internet policy, your organization will not be affected by this change.


Update July 8, 2022:

Following user feedback, we have rolled back this change temporarily while we make some additional changes to enhance usability. This is a temporary change, and we are fully committed to making the default change for all users. 


Regardless of the default setting, customers can block internet macros through the Group Policy settings described in this article


We will provide additional details on timeline in the upcoming weeks.


It’s a challenging time in software security; migration to the modern cloud, the largest number of remote workers ever, and a global pandemic impacting staffing and supply chains all contribute to changes in organizations. Unfortunately, these changes also give bad actors opportunities to exploit organizations:


“Cybercriminals are targeting and attacking all sectors of critical infrastructure, including healthcare and public health, information technology (IT), financial services, and energy sectors. Ransomware attacks are increasingly successful, crippling governments and businesses, and the profits from these attacks are soaring.”

- Microsoft Digital Defense Report, Oct 2021


For years Microsoft Office has shipped powerful automation capabilities called active content, the most common kind are macros. While we provided a notification bar to warn users about these macros, users could still decide to enable the macros by clicking a button. Bad actors send macros in Office files to end users who unknowingly enable them, malicious payloads are delivered, and the impact can be severe including malware, compromised identity, data loss, and remote access. See more in this blog post.


"A wide range of threat actors continue to target our customers by sending documents and luring them into enabling malicious macro code.  Usually, the malicious code is part of a document that originates from the internet (email attachment, link, internet download, etc.).  Once enabled, the malicious code gains access to the identity, documents, and network of the person who enabled it."

- Tom Gallagher, Partner Group Engineering Manager, Office Security


For the protection of our customers, we need to make it more difficult to enable macros in files obtained from the internet.


Changing Default Behavior

We’re introducing a default change for five Office apps that run macros:


VBA macros obtained from the internet will now be blocked by default.


For macros in files obtained from the internet, users will no longer be able to enable content with a click of a button. A message bar will appear for users notifying them with a button to learn more. The default is more secure and is expected to keep more users safe including home users and information workers in managed organizations.


"We will continue to adjust our user experience for macros, as we’ve done here, to make it more difficult to trick users into running malicious code via social engineering while maintaining a path for legitimate macros to be enabled where appropriate via Trusted Publishers and/or Trusted Locations.”

- Tristan Davis, Partner Group Program Manager, Office Platform


This change only affects Office on devices running Windows and only affects the following applications: Access, Excel, PowerPoint, Visio, and Word. The change will begin rolling out in Version 2203, starting with Current Channel (Preview) in early April 2022. Later, the change will be available in the other update channels, such as Current Channel, Monthly Enterprise Channel, and Semi-Annual Enterprise Channel.


At a future date to be determined, we also plan to make this change to Office LTSC, Office 2021, Office 2019, Office 2016, and Office 2013.


End User Experience

Once a user opens an attachment or downloads from the internet an untrusted Office file containing macros, a message bar displays a Security Risk that the file contains Visual Basic for Applications (VBA) macros obtained from the internet with a Learn More button.


A message bar displays a Security Risk showing blocked VBA macros from the internetA message bar displays a Security Risk showing blocked VBA macros from the internet


The Learn More button goes to an article for end users and information workers that contains information about the security risk of bad actors using macros, safe practices to prevent phishing & malware, and instructions on how to enable these macros by saving the file and removing the Mark of the Web (MOTW).


What is Mark of the Web (MOTW)?

The MOTW is an attribute added to files by Windows when it is sourced from an untrusted location (Internet or Restricted Zone). The files must be saved to a NTFS file system, the MOTW is not added to files on FAT32 formatted devices.


IT Administrator Options

This chart shows the evaluation flow for Office files with VBA macros and MOTW:

Evaluation flow for Office files with VBA macros and MOTWEvaluation flow for Office files with VBA macros and MOTW

Organizations can use the “Block macros from running in Office files from the Internet” policy to prevent users from inadvertently opening files from the internet that contain macros. Microsoft recommends enabling this policy, and if you do enable it, your organization won’t be affected by this default change.


“Setting policy is a powerful tool for IT Admins to protect their organizations. For years we’ve recommended blocking macros obtained from the internet in our security baselines, and many customers have done so. I’m pleased Microsoft is taking the next step to securing everyone with this policy by default!”

- Hani Saliba, Partner Director of Engineering, Office Calc


Additionally, there are two other options to know your files are safe:

  • Opening files from a Trusted Location
  • Opening files with digitally signed macros and providing the certificate to the user, who then installs it as a Trusted Publisher on their local machine

To learn more about how to get ready for this change and recommendations for managing VBA macros in Office files, read this article for Office admins.


Thank you,

Office Product Group
VBA Team & Office Security Team


More helpful information on the threats of Ransomware:


Continue the conversation by joining us in the Microsoft 365 Tech Community! Whether you have product questions or just want to stay informed with the latest updates on new releases, tools, and blogs, Microsoft 365 Tech Community is your go-to resource to stay connected!

Brass Contributor

Thanks - the article does not mention XLAM at all but I can see that it might apply.

So what will the new expected behavior be when a signed XLAM with MOTW is opened from an untrusted location?

  • By the user double-clicking the XLAM
  • By the user using File Open from Excel
  • By the user using the Excel Addins to dialog to install the XLAM
  • By VBA in the event
  • By Excel when Excel opens and finds a Registry Open key has been created for the XLAM

And how does this behavior change with a signed XLAM with MOTW from a trusted location?


@fastexcel I'm sorry that article didn't call out XLAM; the security patch from 016 impacts both XLA and XLAM files.

There's very little change in the behavior of XLA and XLAM files with MOTW.


Enumerating the behavior of XLAM files with MOTW:

  • Double clicking on the file will open Excel but the add-in will be silently blocked. As I mentioned in a previous reply, the Excel team is working on improving this experience by informing the user that the add-in has been blocked.
  • Opening a file via File > Open in Excel will have the same behavior as double clicking on the file.
  • Adding the file via Excel Add-ins dialog will show a pop up informing the user that the add-in is blocked. The user needs to remove MOTW or, if the add-in is digitally signed, trust the publisher, to enable the VBA in the add-in.
  • Opening via in VBA will depend on the user's settings. By default, opening other workbooks/add-ins from VBA bypasses most security settings
  • opening an XLAM file with MOTW from a trusted location will not be blocked - this is because trusted locations override MOTW. We only recommend using trusted locations when users trust the location, the source of the file, and the contents of the file, as files in trusted locations override most security checks.

Can you expand on the Registry Open key? 2 different methods of achieving this come to mind, and I want to make sure I investigate the scenario you're asking about.

Brass Contributor

Thanks for the XLAM details.

The most usual scenario for the Registry open key is for an Installer exe to install the files and set the Open key, with Excel closed. Then when Excel starts it will read the registry key and open the XLAM

Copper Contributor

Another terrible update idea from Microsoft.

I made my own excel macro enabled document and put it on office server.

I made it available offline from my laptop and after the update (Version 2205), I just received this information and the macro document showed me the security risk banner instead of security warning which I can enable macro.

This is very frustrating as I made the macro for my co-workers to update stock document easily.


I hope the next update will give back permission to enable macro instead of blocking it.

For information, I also can't find the security and unblock check box as mentioned in this post, also tried to adjust some setting in trust center, tried to add trusted locations to my server by IP but it's not allowed by excel. None of the solution works on me.

So now I can do nothing about it.


Thanks for the brilliant idea Microsoft!!!


Hi @yrzhl, if you cannot find the unblock button, you may try saving the files to trusted locations, adding the file server or network share as a trusted site by adding its FQDN or IP address to the list of trusted sites. You can find more details in article for Office admins.


Thank you!

Copper Contributor

Hi @PhoebeYuan, thank you for replying.

None of the solutions at the page mentioned work for me.

And for add the location to trusted location it showed me error "The path you have entered cannot be used as a Trusted Location for security reason. Choose another location or a specific folder" (image=

I don't understand why microsoft restrict this location (my own intranet server).


@yrzhl you may try to use "Trusted sites" solution, which is different from "Trusted Locations". Go to Control Panel > Internet Options > Change security settings.

  • Web Site: URL (Example:
  • Network Share: The FQDN (for example, \\ or IP address of the destination server that you specify when you connect (for example, \\) (Example:

Thank you!

Copper Contributor

@PhoebeYuanHi thanks for the solution, it works! I thought of that idea but missed to unchecked the "Require server verification (https:) for all sites in this zone" button. Now it's running without notification.


But any idea to do it simpler way? Because I need to update on more than 10 devices. Let say using script or .bat.

Copper Contributor

Is it just me or have Microsoft rolled this change back on the Current Channel?


I was trying to reproduce the pinkish-red 'Security Risk... Learn More' notification in the Message Bar, in preparation for demonstrating the new default behaviour for a YouTube video I'm putting together about my company's macro-enabled toolkit.


Created a simple .xlsm to show a MsgBox in the open event of the workbook, saved it and uploaded it to cloud storage, deleted it from my local storage, re-downloaded it from cloud storage (to a non-trusted location, my Downloads library)... did not use the Unblock checkbox on the Properties dialog to remove the mark of the web... then opened up the file.


It first went into Protected View (expected behaviour), but then after I clicked Enable Editing, instead of getting the pink/red message about macros being blocked altogether, I just got the old 'Security warning...' message with the 'Enable Content' button. The file's VBA project wasn't digitally signed, wasn't saved to a Trusted Location, and still had the mark of the web on it... so macros should have been blocked.


I also tried uploading it and re-downloading it from our Sharepoint document library, emailing it to my work address from my personal address, opening it directly from the attachment... still macros weren't blocked entirely. Even tried downloading an .xlsm from the internet that I hadn't created (from a known trustworthy source) that my installation of Office had never encountered before, so that it definitely wasn't a Trusted Document... and STILL macros weren't blocked.


It feels like something has undone this new default behaviour very recently... maybe Microsoft Defender is overruling the block?


I'm loathed to clear my Trusted Documents in an effort to trigger the red macro block message, just for the sake of the video, but I'm not sure what else to try at this point.

@vincehardwick Based on feedback received, a rollback has started. An update about the rollback is in progress. I apologize for any inconvenience of the rollback starting before the update about the change was made available. @PhoebeYuan FYI

Iron Contributor

Thank you for the update on this page regarding the Rollback.  It would be good to have effectively communicated this elsewhere.  There are considerable rollbacks occurring across the platform and for months, "support" has been ill-qualified to assist because of the lack of communication.  I mention Exchange in January, the ensuing "Defender" debacle in March/April, NCE, the move to get rid of Outlook and only have a "web app", and now the latest, the Partner Center Changes slated for October that seemingly require a degree to understand.


MOTW is for advanced teams.  Your standard SMB and even mid-sized businesses are going to implode if this gets fully implemented in it's current form.  You seem to be catering to enterprises now that have very large teams of people to manage your products, and that's simply not the case for most of the user base. It needs to be simplified before it's released, and moreso, it needs to be effectively communicated.


I'm hopeful this is a new overall direction for the Office line.

Copper Contributor

Thanks for the update @Angela Robertson, in one sense I'm glad it wasn't me just missing something obvious... but on the other hand, rolling back a recently implemented change in default behaviour without at least announcing the rollback is about to happen is very poor product management. I appreciate your apology, but it really should not have been necessary in the first place, it's not like Microsoft are new to this.


We've been scrambling to obtain a digital certificate for signing our VBA projects since I first became aware of the impending update in mid-June... then immediately after we've incurred that expense and got things working again in the least inconvenient way for our customers, Microsoft just flip a switch without telling anybody? You've got us jumping from one foot to the next and having to second guess what the next volte face is going to be.

Copper Contributor

Any reference or detail why Microsoft rolling back automatic macro blocking features.


@Pinku1725 , based on feedback, we’re rolling back this change from Current Channel production. We appreciate the feedback we’ve received so far, and we’re working to make improvements in this experience. We’ll provide another update when we’re ready to release again to Current Channel. Thank you.

Copper Contributor

Congrats MSFT.  You bent to the luddites again who will soon be on the Who's Who of Pwned Orgs and blaming you for not protecting them.  It seems no good deed goes unpunished.


Literally black hats and red teams around the world are celebrating this backpedalling.  

Copper Contributor

@hwallisbackpedalling? This time I agree with microsoft to rollback the update which force user not to use macro, which also one of excel feature. User have the rights to use or not use the feature. If it will be blocked, then why microsoft create it at the first place?

This macro feature is very important and useful to make things easier usually end user (especially older generation who has difficulties using computer). From your comment, I believe you're not macro user and the feature doesn't help you at all.


Besides there's a software that can detect any viruses, malware, spyware etc called antivirus. It's your fault it you didn't use one of them.

Copper Contributor

Why not just integrate unblocking in Excel? Maybe with some extra big additional warnings. The whole MOTW way of unblocking will be out of scope for 99% of end users. What would be even better would be an upgrade or replacement for VBA that takes modern security practices into account.

Copper Contributor

One vote for rollback. My Access applications can now launch 100% of the time at work. Previously 0%. There's that many other security measures in place that I suspect the actual risk of anything negative happening is more theoretical than measurable.

Brass Contributor

On the one hand, macros are immensely powerful, but on the other hand, they are a big security issue. But antivirus isn't the solution: macros may be very individual.

In my mind, macros must be signed to run. And there for MS has to setup an easy digital signature infrastructure concept with free code signing certificates for small business, individuals, and big companies.

Brass Contributor

"macros must be signed to run"


Good idea, but unfortunately validly signed Macros with MOTW are NOT currently allowed to run, unless the publisher has already been trusted (IT Admins etc know how to trust a publisher but end-users mostly do not). At the moment it is much easier to tell users to always unblock all downloaded files than to explain Signing and how to Trust a Publisher.

@VNJoe @vincehardwick and others providing feedback. I hear that more proactive communication is needed and will work with the team to provide that proactive communication going forward. 

Copper Contributor

I write macros frequently and I have noticed files I wrote and saved on the home network file servers are sometimes considered "over the internet." 


In my opinion, there should be some way for a user to enable macros. 

Copper Contributor

Hello @Angela Robertson , is there a way to check if the rollback is completed? We get a feeling that some of our users are rolled back but some are stuck in this change and don’t seem to revert. Thanks.

Copper Contributor

Hi @Angela Robertson, I am currently testing this functionality in the 'Current Preview' channel to get ready for when this is pushed out again, and we are seeing files containing macros on our file server getting blocked even though they do not hold the Mark of the Web attribute (confirmed via the 'notepad {name of file}:Zone.Identifier' command, 'Unblock' is not available under properties).


According to the documentation only files containing macros AND the MOTW attribute should be impacted.


I do not want to add a trusted location as that disables all protections, not just the macros. Is this an intended impact or something that would be fixed before the change is released again?



Copper Contributor

Thank God for the rollback. Half our users wanted to move away from Microsoft Office because of this change. Please leave it to the users to decide if they want to enable macros or not. Microsoft Excel is the best spreadsheet software out there because it allows for automation via macros. The day you remove this ability or make it difficult for users to use macros you will essentially kill this brilliant tool.

Brass Contributor

Hi @Kellie_msft , hi MS,
you have updated this message "We’re resuming the rollout of this change in Current Channel.", but not forwarded this message to us.
Only updating the documentation isn't enough. We need not only a technical concept but also a real concept about user adoption. The handling of this feature is not acceptable for end users.

Copper Contributor

Looks like the update was pushed to Message Center on the admin portal today:


From a security perspective, this change in default behaviour is long overdue and I can't think of another way they could have shut off this attack vector for macro-based malware, even if the communication of it has been botched.


Creators of legitimate VBA projects just need to either self-sign their code ( or obtain a code signing certificate from one of the MS Trusted Root Participant CAs (, and support their users in adopting best practice re: trusted locations and trusted publishers (


It's all stuff that VBA developers and users should have been doing before now anyway, and the workaround steps that are now necessary aren't all that technical. There will be some resistance to the change, but that doesn't make it a bad one... it will achieve what has been needed for some time: make it more difficult for companies to be brought to their knees by ransomware.

Brass Contributor

Unfortunately  code-signing VBA XLAM addins does not really help with this security update - the user still has to unblock the download.


@tpg017, for the new updated doc for end users: A potentially dangerous macro has been blocked ,  in section "If you’re sure the file is safe and want to unblock macros", multiple solutions are provided to help unblock the macros. Do you mean the files still can't work with these solutions adopted? Can you share more details? Thanks!

Copper Contributor

@vincehardwick We did code sign our VBA product, distributed it to thousands of users, out of which almost all recently added a worksheet or deleted a worksheet manually and the signature was lost. With the new update, they couldn't use the file anymore. Months and years of hard work gone in seconds. 
It doesn't make sense to lose the signed VBA certificate if a user adds a sheet but its a shame and that's just how it is (Only if the user makes a code change to a signed copy then the signature/ signed cert should be discarded - Not sure why Microsoft won't fix this).

If Microsoft fixes all the bugs around 'not discarding VBA signature' when users make worksheet changes then this solution may work in the future but until then it should let us macros users enjoy the brilliant software it has given us.

Brass Contributor

@PhoebeYuan   Yes this page has been slightly revised, but it is just too complex for normal users and with too many "ifs". And the workflow for receiving macro files by mail is complicated: first save to desktop, check, set the flag, move to destination, and then open. And no possibility for admins or users to name reliable sources. 

Copper Contributor

@praddsouza That does not entirely match up with my experience thus far when it comes to digital signatures and VBA projects. In the macro-enabled workbook that I manage, the VBA project is password-locked, the workbook structure is password-protected, and a new blank worksheet can be added programmatically via a command button and associated macro.


The model can be saved after programmatic insertion of a new blank worksheet without the digital signature being discarded, as long as you don't enter the password to unlock the VBA project and view the code module attached to the new worksheet object - which may (depending on your VBE settings) add directives at the top of the module by default (e.g. Option Explicit), thereby changing the VBA project.


The new worksheet inserted programmatically can also be deleted via command button/associated macro without affecting the VBA project/digital signature.


An existing worksheet can also be deleted programmatically without affecting the VBA project/digital signaature, as long as the code module attached to the worksheet object being deleted is empty, e.g. there is no Worksheet_Change event procedure code related to the sheet.


So it's all about structuring your project such that critical code is not attached to worksheets which the end user is able to delete. If your experience is different, I assume that either your workbook is not protected, meaning users can freely delete core worksheets that have VBA code associataed with them, or if the workbook is protected, then there remains a programmatic way via user interface operations (command buttons etc) that users are able to delete these core worksheets with associated VBA code.


In that latter case, it would be sensible to review your project's structure and remove that ability to programmatic deletion of those worksheets, or move any associated code to a module/worksheet object which cannot be programmatically deleted. In the former case, I would strongly suggest workbook protection and VBA project protection.

Copper Contributor

@PhoebeYuan The files will work, i.e. macros can be enabled, by applying one or more of the documented solutions.


@tpg017 I don't think the workflow is all that complicated - you may be over-complicating it by thinking you have to do BOTH ticking the Unblock checkbox AND moving it to a trusted location - you don't... one or the other will suffice. But yes, saving the attachment is required first.


And there absolutely is a possibility for admins/users to define trusted sources - that's precisely what trusted publishers are for.


If you mean trusted sources as in the email addresses from which you will trust any macro-enabled files received as attachments... given the possibility of spoofing a sender's email address, I would suggest that is an extremely risky way to handle macro security. Perhaps better would be to ask people who might email you macro-enabled files to use self-certification to digitally sign their VBA projects, then you can add them as a trusted publisher on the receiving machine.

Copper Contributor

@vincehardwick All our users like most users, want to keep the workbook unprotected. They want to add new worksheets and delete them if required. 
I can understand, if they delete a core worksheet with code attached to the worksheet module then yes, Microsoft can say "Hey code changed and hence discarding signature" - This is acceptable.


The issue when Microsoft discards a signature when a user adds a innocent worksheet that has no code attached to the worksheet module and same for deleting a worksheet that has no code attached to the worksheet module.


These are just two behaviors I have noticed. Its possible that there may be many more.

Copper Contributor

Absolutely, I understand the need for users to add and remove worksheets for their own side calculations - but you can achieve this using macros attached to command buttons, whilst still keeping the workbook structure protected, and all after applying a digital signature, which is preserved just fine if you password-protect your VBA project.

Copper Contributor

Perhaps Microsoft Excel with internet connection could check file and say it's OK, assume liability and charge for the cost in the subscription. One problem would be preventing MS from datamining what it sees to provide new features, 

Iron Contributor

@vincehardwick  "From a security perspective, this change in default behaviour is long overdue and I can't think of another way they could have shut off this attack vector for macro-based malware, even if the communication of it has been botched."


Turn off autorun.


Done and done.


This "fix" for "Secure by Default" is truly a horrible path being taken by Microsoft.  "Secure by Default" implies you can change the default, and you can't.  So, the actual name of this marketing hype phrase should be "Removing Features" or "Disabling your Software".

Copper Contributor

Auto-run? Do you mean any code that's in the Workbook_Open event? I'm not sure how that is any less an example of 'removing features' than blocking macros on files originating from the Internet. Apart from that, it would be trivial to circumvent that solution, just by putting the malicious code into a different event and then artificially triggering it. A limited disabling wouldn't be effective enough in preventing malware attacks from being able to deliver payloads.


Your point about 'secure by default' not applying due to users being unable to change the default behaviour is strange... several methods have been documented for how to avoid the block and therefore change the behaviour.


This block is also limited to macro-enabled files with the MotW attribute... which itself is trivial to remove, even for relatively unskilled, non-technical end users. Anybody could be shown how to do that within 30 seconds. And then hey presto, your 'disabled software' is re-enabled and your end user has had to think twice before enabling potentially dangerous active content.


It's best we get used to the idea of VBA being a high risk way of developing solutions, and accept the inevitable safeguards and restrictions that will have to be introduced to keep the platform alive until it is finally retired,and let's be honest, the writing is on the wall here in that regard. But that won't be for a while yet, I expect, certainly not until Office Scripts become more established and better conceptualised and implemented, so as to provide a viable replacement.


@fastexcelcode-signing VBA XLAM addins, the note callout in Macros from the internet are blocked by default in Office - Deploy Office | Microsoft Docs, saying: using a digital signature and trusting the publisher doesn't work for Excel Add-in files that have Mark of the Web. This behavior isn't new for Excel Add-in files that have Mark of the Web. It's worked this way since 2016, as a result of a previous security hardening effort (related to Microsoft Security Bulletin MS16-088). 


Yes I understand that this was done in 2016. But the implementation was a mistake then and it is still a mistake today. Because few organisations ever implemented the policy the problem has gone largely un-noticed until now.


The correct solution would be to ask the user if they wanted to trust the named publisher of the signed XLAM file when they open or install the XLAM that has MOTW. This would be a much more secure solution than just telling users to unblock all MOTW files.

BTW I very painfully discovered yesterday the VBA code-signing process has been changed.

If you start getting messages that SignTool does not recognise the file format then you need to upgrade to the V3 format – see article below.

Copper Contributor

We are officially moving away from Microsoft Office throughout our organization because of this horrendous change. We had automated our entire workflows with Excel Macros but some geniuses at Microsoft are hell bent on killing a beautiful software. Our clients are devastated. I hope someday some better sense prevails.

Millions of users are complaining about this across the world. Here is a link at Microsoft itself.


@praddsouza, do all solutions under section "Steps to take to allow VBA macros to run in files that you trust" in Macros from the internet are blocked by default in Office - Deploy Office | Microsoft Docs and A potentially dangerous macro has been blocked ( can't help on unblock the case? If you're hitting another different case, may I know more details about the issues your customers are facing? Thanks!

Copper Contributor

@PhoebeYuan None of the solutions actually work. We digitally sign our macros. Clients are sick of trying to unblock files (that worked so well for decades - all you had to do was click the Enable Macros/ Content button). Now they have to figure out how to unblock each time they download files from email or cloud servers. Additionally a user adding a simple worksheet removes the digital signature (how does adding a worksheet make changes to the code?). The whole world was ok till someone had to mess with new security settings. I think Microsoft should allow users to choose to enable macros or not. Users know that you have to walk and cross at a zebra crossing and not stray onto a road with traffic.


@praddsouza If you're using digital signature, below 2 options may help:

  • Admin to deploy cert for multiple users: you need to deploy the public code-signing certificate for the trusted publisher to your users first. With GPO, 
    • Go Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies, right-click Trusted Publishers, and then choose Import.
    • Run the Certificate Import Wizard and import the appropriate certificate file to the Trusted Publishers certificate store.
  • End users: the unblock file will only need to be checked once, and then the user need to add the trusted publisher into Office. Then next time, all files from the same trusted publisher will NOT be blocked by MOTW anymore. you can refer to the article: A potentially dangerous macro has been blocked (, the last solution:


More details on how to add a trusted publisher in Office can be found in Add, remove, or view a trusted publisher (


Brass Contributor

Hi Microsoft,
when will be the version for enterprise channel released? Actual it is "To be determined".
We at enterprise level have to prepare our information campaign for our endusers! One week before is too late … We expect the information from MS at least three months before release.


@tpg017   Are you asking about Monthly Enterprise Channel or Semi-Annual Enterprise Channel?

Brass Contributor

@DHB-MSFT Yes your are right, I'm asking about the "Semi-Annual Enterprise Channel". Thanks 


@tpg017 FYI, we just updated the release schedule (see Versions of Office affected by this change). This change is scheduled to be available in Semi-Annual Enterprise Channel on 10 January 2023 in Version 2208.

Brass Contributor

How is MOTW managed for files received as email attachments (Outlook on Exchange Online)?  And is that behaviour different depending on who sent the email?  For example, would an email with a xlsm attachment sent from an internal colleague result in the file receiving the MOTW?


I've been trying to test the scenarios today, and what I'm seeing is that email attachments sent directly from a colleague in my company do not get MOTW, yet if I forward the same email out of the company and back in again, they do receive MOTW.


This is fine, and perhaps desirable to avoid business impact.  But what is annoying is that this behaviour does not seem to be consistent across all of my users.  Some recipients of the same email attachments do mark those attachments with MOTW, despite being in the same organisation on the same email system and same domain as me.


Any help to understand this behaviour would be appreciated please.

Version history
Last update:
‎Jul 20 2022 09:04 AM
Updated by: