Microsoft 365 Apps Security: Setup, Policies, and Admin Configuration Guide 2026
Why This Is Happening
You opened an Excel workbook that's been running fine for years , an automated report, a finance tool your team built, a vendor-supplied spreadsheet , and instead of your macro firing up, you get a yellow or red banner that reads something like: "SECURITY RISK: Microsoft has blocked macros from running because the source of this file is untrusted." The Learn More button takes you to a generic help page. Your work is blocked. Your team is frustrated. And nobody in the building seems to know why this suddenly started happening.
I've seen this exact scenario on dozens of machines across every industry, healthcare clinics with Excel-based scheduling tools, logistics companies with macro-driven dispatch sheets, accounting firms with legacy Publisher templates. The confusion is real. The error message gives you almost nothing actionable. So let me explain exactly what's going on.
This is a deliberate, intentional Microsoft 365 Apps security change, not a bug, not a glitch, not something your IT team broke during a patch. Starting in April 2022, Microsoft began rolling out a fundamental shift in how Office handles macros downloaded from the internet. VBA macros have historically been one of the most common delivery mechanisms for malware, ransomware, and phishing payloads. A user gets an email attachment, opens it, clicks "Enable Content," and suddenly the network is compromised. Microsoft decided enough was enough.
The technical mechanism at play here is something called Mark of the Web (MOTW). Windows has silently been tagging files downloaded from the internet, via browsers, email clients, file-sharing services, with a hidden Zone Identifier in the file's NTFS Alternate Data Stream. Before this Microsoft 365 Apps security policy change, Office would warn you but still let you enable macros. Now, if a file carries that internet-origin tag, macro execution is blocked outright, with no "Enable Content" button to bail you out.
The change affected different Office applications on different timelines. Excel, Word, PowerPoint, Access, and Visio on the Current Channel got this in Version 2206 (July 2022). Semi-Annual Enterprise Channel users hit it in January 2023 with Version 2208. Project took even longer, Semi-Annual Channel users didn't see it until August 2024. Publisher had its own separate rollout. If your machines updated at different times, that's why some users are affected and others aren't yet. This inconsistency is a major source of support tickets.
What makes Microsoft 365 Apps security configuration genuinely tricky is that this isn't just one setting you flip. The right fix depends entirely on where your files live, a local folder, a network share, OneDrive, SharePoint, or an email attachment. Each scenario has a different recommended path. Get the wrong one and you'll either leave a security hole open or keep hitting the same block. This guide walks through every scenario, with the exact steps IT admins and end users need.
Browse all Microsoft fix guides if you're dealing with other Office issues alongside this one: Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you're dealing with a single file, say, one Excel workbook or a Word template you trust, this is the fastest way to unblock it without touching any Group Policy or registry settings. You don't need admin rights for this in most cases. Here's what you do.
Close the file in Office if it's open. Open Windows File Explorer and navigate to the file. Right-click the file → Properties. At the very bottom of the General tab, you'll see a Security section with a checkbox labeled "Unblock". Check that box, click Apply, then click OK. Reopen the file in Excel (or Word, PowerPoint, etc.) and your macro should now run normally.
That Unblock checkbox is what removes the Mark of the Web, that hidden NTFS metadata tag Windows stamped on the file when it was downloaded. Once the tag is gone, Office no longer treats the file as internet-sourced, and the macro block lifts immediately.
One catch: sometimes the Unblock checkbox isn't there. This happens when the file is stored on a network share (especially accessed via UNC path or IP address) rather than locally on the machine. In that case, jump to Step 3 in the section below, you'll need to add the share location to your Trusted Sites or Local Intranet zone instead.
If you're comfortable with PowerShell and want to unblock several files at once without clicking through Properties dialogs for each one, open PowerShell as your normal user (no elevation needed for files you own) and run:
Unblock-File -Path "C:\Users\YourName\Downloads\report_macro.xlsm"To unblock an entire folder of files in one shot:
Get-ChildItem -Path "C:\MacroFiles" -Recurse | Unblock-FileAfter running either command, open the file again, the macro block should be gone. If Office still shows the security banner after unblocking, close and fully reopen the application (not just the file). Sometimes Office caches the security decision for the session.
Get-Item "C:\path\to\file.xlsm" -Stream Zone.Identifier. If you get output (the stream exists), the Unblock approach will fix it. If the command returns nothing, the file doesn't carry MOTW, and the macro block is coming from a Group Policy setting instead, which means you need the admin-level fixes in the Advanced section.
This is the right starting point for any individual file, a downloaded attachment, a file a colleague sent via Teams chat, a spreadsheet pulled from a vendor portal. The process is the same regardless of whether it's .xlsm, .docm, .pptm, or .accdb.
Navigate to the file in File Explorer. Right-click it and choose Properties. On the General tab, look at the very bottom. If Windows has tagged this file as internet-sourced, you'll see a message like "This file came from another computer and might be blocked to help protect this computer" followed by an Unblock checkbox. Check it, hit Apply, then OK.
For admins managing multiple machines or files, PowerShell is faster and scriptable. The Unblock-File cmdlet is part of the Microsoft.PowerShell.Utility module, no additional installs needed:
# Unblock a single file
Unblock-File -Path "C:\Finance\Q1_Report_Macro.xlsm"
# Verify the Zone.Identifier stream is gone
Get-Item "C:\Finance\Q1_Report_Macro.xlsm" -Stream * | Where-Object Stream -ne ':$DATA'After that second command, if you see no Zone.Identifier in the output, the unblock worked. Reopen the file, your macros should now execute without any Microsoft 365 security warning. If you're on a domain-joined machine with Group Policy enforcing macro blocking, this file-level fix may still be overridden; in that case, the Advanced section covers what to do next.
If your team regularly opens macro-enabled files from the same folder on a local machine, say, a shared templates directory on C: drive or D: drive, setting that folder as a Trusted Location is far more efficient than unblocking files one by one. Trusted Locations tell Office: "Any file from this folder is safe, skip the internet-origin check entirely."
Inside Excel (or Word/PowerPoint, the steps are identical), go to File → Options → Trust Center → Trust Center Settings → Trusted Locations. Click Add new location. Browse to the folder path or type it in manually. If you want subfolders to be trusted as well, check the "Subfolders of this location are also trusted" checkbox. Click OK through all dialogs.
From that point forward, any macro-enabled file opened from that folder will run without hitting the Microsoft 365 Apps security block. No unblocking, no policy exceptions needed per file.
IT admins can push Trusted Locations via Group Policy instead of configuring each machine manually. The setting lives under:
User Configuration → Administrative Templates → Microsoft Excel 2016 →
Excel Options → Security → Trust Center → Trusted LocationsThe corresponding registry path (useful for scripted deployments) is:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Security\Trusted Locations\Location[N]Where [N] is a sequential number (Location1, Location2, etc.). Each location entry needs Path (REG_SZ) and optionally AllowSubfolders (DWORD, 1 = yes).
When the configuration is correct, opening a file from that path will show no security banner, macros execute immediately on file open.
Network shares are one of the trickiest scenarios in Microsoft 365 Apps security administration. If your users are accessing files via a UNC path like \\server\share\macrofiles\ or, more problematically, via the server's IP address like \\192.168.1.50\share\, Windows may classify that location as the internet zone rather than the local intranet zone. That triggers the macro block even though the file never left your building.
The fix depends on how your network is set up. For domain-joined environments, the cleanest approach is to add the server or share to the Local Intranet zone via Internet Options or Group Policy. Here's how to do it manually:
Control Panel → Internet Options → Security → Local intranet → Sites → Advanced
Add: \\server\share or file://192.168.1.50For a Group Policy-based push to all machines:
Computer Configuration → Administrative Templates → Windows Components →
Internet Explorer → Internet Control Panel → Security Page → Site to Zone Assignment ListAdd the UNC path with Zone value 1 (Local Intranet). Once deployed, files opened from that path will carry an intranet zone designation rather than an internet one, and the macro block won't apply.
Alternatively, you can designate the network share as a Trusted Site (Zone 2) in Internet Options, same path as above but using the Trusted Sites tab. Both approaches achieve the macro-unblocking result. Microsoft recommends the Local Intranet zone approach for internal shares, and Trusted Sites for intranet websites that distribute Office files.
After the zone assignment is in place, have the affected user close and reopen Office. They may also need to log off and back on if the Group Policy change is fresh. Open a test macro-enabled file from the share, the security banner should no longer appear.
This one catches a lot of admins off guard. You'd think that files stored in your organization's own SharePoint or OneDrive for Business tenant would be inherently trusted, they're behind your Azure AD authentication, after all. But when a user downloads a copy of that file to their local machine before opening it, Windows stamps it with a Mark of the Web based on the download URL. The local copy is now flagged as internet-sourced, and macros are blocked.
The recommended approach from Microsoft for OneDrive and SharePoint files is to have users open the file directly using the Open in Desktop App option rather than downloading it first. When opened this way, the file is opened in-place via the Office sync client, and the internet-origin tagging works differently, macros are generally not blocked. In SharePoint, look for the Open → Open in Desktop App option in the file's context menu or the ribbon.
If a user has already downloaded a local copy, the fix is to remove Mark of the Web from that local file using the Properties → Unblock checkbox or Unblock-File in PowerShell (see Step 1). Or, they can delete the downloaded copy and use Open in Desktop App going forward.
For Teams channels that have an associated SharePoint document library, the same rules apply. Files opened directly through the Teams desktop app interface typically go through the Office sync client pathway and don't hit the macro block. But files saved to Downloads via the Teams browser interface will be tagged.
You can also designate your SharePoint site URLs as Trusted Sites in Internet Explorer/Edge zone settings, which gives Office a signal that content from those URLs should be treated as trusted. This is a good belt-and-suspenders approach for organizations that have a mix of opening methods across their user base.
If your organization has macros provided by an independent software vendor (ISV), an internal development team, or a third-party tool that signs its code, this is the most secure and scalable long-term fix. Trusted Publishers let you say "macros signed by this specific certificate are always allowed to run" without opening up broad Trusted Locations or weakening the internet-origin checks.
First, obtain the public code-signing certificate from the publisher (your ISV should provide this). Then deploy it to your users' Trusted Publishers certificate store via Group Policy:
Computer Configuration → Windows Settings → Security Settings →
Public Key Policies → Trusted PublishersImport the certificate here and it will be pushed to all machines in scope. This is the Microsoft-recommended enterprise approach, and importantly, Microsoft specifically recommends preventing users from adding trusted publishers themselves, so that certificate trust decisions remain centrally controlled by IT.
To prevent end-user modification of the Trusted Publishers list, enable this Group Policy setting:
User Configuration → Administrative Templates → Microsoft Office 2016 →
Security Settings → Disable Trust Bar Notification for unsigned application add-insAnd set the VBA macro notification behavior via:
User Configuration → Administrative Templates → Microsoft Excel 2016 →
Excel Options → Security → Trust Center → VBA Macro Notification SettingsOnce the certificate is deployed and the macro file is opened, Office checks the file's digital signature against the Trusted Publishers store. If it matches, macros run silently, no prompts, no security banners, regardless of where the file came from. This works even for files that carry Mark of the Web. It's the most enterprise-grade approach to Microsoft 365 Apps security policy configuration for macro-dependent workflows.
Advanced Troubleshooting
When the basic file-level fixes don't work, or when you're managing dozens or hundreds of machines, you need to get into the Group Policy and registry layer of Microsoft 365 Apps security configuration. Here's how IT admins approach this at scale.
Group Policy: Block Macros from the Internet
Microsoft actually published a Group Policy setting specifically for this scenario before the default behavior change rolled out. It's called "Block macros from running in Office files from the Internet", and it lives at:
User Configuration → Administrative Templates →
Microsoft Office 2016 → Security Settings → Block macros from running in Office files from the InternetIf your organization already has this policy enabled, it will enforce macro blocking regardless of the default behavior change, and regardless of what individual users try to do with the Unblock checkbox. To allow specific trusted file sources to bypass this, you need the Trusted Locations or Trusted Publishers approach in parallel. The policy and the default change are independent levers; they interact in ways that aren't always obvious from the UI.
Registry-Level Macro Security Settings
For environments that can't use Group Policy (workgroup machines, non-domain-joined endpoints, certain VDI setups), the same macro security settings can be applied via registry. The key for Excel macro security, for example, is:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Security
Value: VBAWarnings (DWORD)
1 = Enable all macros (not recommended)
2 = Disable all macros with notification
3 = Disable all macros except digitally signed
4 = Disable all macros without notificationThe equivalent path for Word is \Word\Security, for PowerPoint \PowerPoint\Security, and so on. VBAWarnings value 3 is the sweet spot for most organizations, it blocks unsigned macros while allowing trusted-publisher-signed code to run automatically.
Event Viewer: Diagnosing Blocked Macro Events
When a macro is blocked, Office logs an event you can query in Event Viewer. Open Event Viewer (eventvwr.msc), navigate to Applications and Services Logs → Microsoft Office Alerts. Look for Event ID 6024 or entries from source Microsoft Office with the text "macro blocked." These logs tell you the exact file path, the triggering application, and the zone classification that caused the block, invaluable for diagnosing whether the issue is MOTW, Group Policy, or something else entirely.
Office Version and Update Channel Verification
Not all Office versions have this change yet. To verify what version a machine is running, open any Office app → File → Account → About [App]. You'll see the version number (e.g., Version 2208, Build 15601.20148). Cross-reference this against the rollout table: Semi-Annual Enterprise Channel users needed Version 2208 for the change to be active. If machines are on older builds, the default hasn't changed yet, but it will, so planning ahead is smart.
Get-Item [file] -Stream *, and a screenshot of the file's Security properties. That gives the support engineer everything they need to diagnose the issue without multiple back-and-forth sessions.
Prevention & Best Practices
The best time to deal with Microsoft 365 Apps security policy for macros is before your users hit the wall, not after. Organizations that planned ahead when this change rolled out in 2022–2023 avoided the wave of helpdesk tickets that buried IT teams who waited. If you're reading this guide as a proactive measure rather than a crisis response, here's the framework to put in place now.
Start by auditing which macro-enabled files your organization actually uses and where they live. Network shares, local template folders, SharePoint libraries, email attachments, map it all out. For each location category, choose the appropriate trust mechanism: Trusted Locations for folder-based files, Trusted Sites / Local Intranet zone for network shares, Open in Desktop App workflows for SharePoint, and Trusted Publishers for ISV-supplied or internally signed macros. Document these decisions somewhere your future self and your successor can find them.
For any macros your internal team develops, invest in code signing. A code-signing certificate from a reputable CA costs a few hundred dollars per year and lets you deploy macros as a Trusted Publisher across your entire organization, clean, auditable, and future-proof against any further changes Microsoft makes to default macro behavior. It also lets you verify that the macro hasn't been tampered with after signing.
Keep your Office update channel strategy aligned with your security posture. Semi-Annual Enterprise Channel (Preview) is being deprecated as of July 2025, if any of your machines are on SAEC-Preview, migrate them to Current Channel or Monthly Enterprise Channel now. Lagging behind on updates doesn't protect you from this change; it just delays when your users get surprised by it, usually at the worst possible moment.
Finally, test your macro-enabled files through your end-to-end workflow at least once per quarter. Open them from the exact location users access them, on a machine with your standard Group Policy applied. If something breaks after an Office update, you'll catch it in testing rather than in a Friday-afternoon production scenario.
- Run
Get-ChildItem \\server\share -Recurse -Include *.xlsm,*.docm,*.pptm | Get-Item -Stream Zone.Identifier 2>$nullto find all internet-tagged macro files on your network share in one pass - Enable the "Block macros from running in Office files from the Internet" Group Policy now, being intentional about this setting means you control the behavior rather than relying on version-dependent defaults
- Add your organization's internal SharePoint and Teams site URLs to the Trusted Sites zone via Group Policy so users never hit the macro block for internally hosted files
- Train end users to always use Open in Desktop App for SharePoint macro files, a 30-second explainer in your next IT newsletter prevents hundreds of helpdesk tickets
Frequently Asked Questions
Why can't I see the "Enable Content" button anymore in Excel, it just says the macro is blocked?
This is exactly the change Microsoft rolled out starting in 2022. Before the change, Office would show you a yellow "Enable Content" button that let you override the macro block manually. That button is gone now for files tagged as internet-sourced, by design. Microsoft removed it specifically because too many users clicked it without understanding the risk, which made it an effective malware delivery vector. Your options now are to unblock the specific file via its Properties dialog (right-click → Properties → Unblock checkbox on the General tab), move it to a Trusted Location, or have your IT admin set up a Trusted Publisher for signed macros. There's no setting to restore the old "Enable Content" button behavior without materially weakening your Microsoft 365 Apps security posture.
My macros work on one computer but not another, why is it inconsistent?
The most likely explanation is that the machines are on different Office update channels or different build versions. The macro-blocking change rolled out at different times per channel: Current Channel users got it in July 2022, Monthly Enterprise Channel in October 2022, and Semi-Annual Enterprise Channel not until January 2023. So if one machine updated to a newer build and the other is still on an older one, they'll behave differently. Check the version on both machines via File → Account → About [App name] and compare against the rollout dates. The other common cause is that one machine has the file cached locally and already unblocked, while the other is opening it fresh from the network with the Zone Identifier still intact.
Does this macro blocking apply to Mac, iPhone, or Android versions of Office?
No, this specific change only applies to Office on Windows. Office for Mac, Office on iOS, and Office on Android are not affected by the Mark of the Web macro-blocking behavior described here. The NTFS Alternate Data Stream that carries the Zone Identifier is a Windows-specific mechanism, so it simply doesn't exist on other platforms. If your users are hitting macro blocks on Windows but not on their Macs, that's expected and correct behavior given the current Microsoft 365 Apps security policy design.
Can I use a Group Policy to turn this security change off completely and go back to the old behavior?
Technically, yes, but Microsoft strongly advises against it, and I'd second that advice. The "Block macros from running in Office files from the Internet" policy can be set to Disabled to restore the old "warn but allow" behavior. However, this re-opens the exact attack surface that malware campaigns have been exploiting for years. The much better approach is to leave the security change in place and use Trusted Locations, Trusted Publishers, or zone assignments to selectively trust the specific sources your organization needs. That way you're blocking malicious macro files by default while still allowing your legitimate business macros to run, which is exactly the security model Microsoft intended.
We're on Semi-Annual Enterprise Channel, does this change affect us, and should we update?
Yes, Semi-Annual Enterprise Channel picked up the macro-blocking change in January 2023 with Version 2208, so it's already in effect on your machines if they've been updated since then. More urgently: Semi-Annual Enterprise Channel (Preview) is being deprecated beginning July 2025. If any machines in your organization are on SAEC-Preview, they need to migrate to either Current Channel or Monthly Enterprise Channel to stay supported. For standard Semi-Annual Enterprise Channel (not Preview), it remains supported, but keep in mind that SAC users are often multiple months behind on security patches, which creates its own risk profile independent of the macro change.
Does removing Mark of the Web with Unblock-File create any security risk I should know about?
It does remove the protection that Mark of the Web provides for that specific file, so yes, you're making a trust decision. The key is to only use Unblock-File on files you've verified are from a known, trusted source. For files received from external vendors or unknown email senders, don't unblock, instead, ask your IT admin to work with the vendor to provide digitally signed macros through a Trusted Publisher setup. For internal files that ended up with MOTW due to how they were transferred (downloaded from SharePoint, sent via Teams, etc.), unblocking is generally fine because you know the provenance. The real risk is training end users to reflexively unblock everything without thinking, so communicate clearly about when this is and isn't appropriate in your organization's context.