I get asked a lot how Grok Bot stays current on Microsoft 365. The short answer is connectors. In the Grok Bot app, those connectors are MCP servers — Model Context Protocol endpoints that give the bot live tools, not just whatever it remembered during training.
This post is a step-by-step walkthrough using Microsoft’s official Microsoft Learn MCP server. It needs no tenant sign-in, it is free, and it is useful on day one for MSPs and smart businesses.
What MCP is, in plain words
MCP is an open standard for connecting AI agents to external tools and data. Think of it as a USB plug for AI: the host (Grok Bot) talks to a server over a shared protocol, and the server exposes named tools the agent can call while answering you.
Without MCP, an agent guesses from training data or browses the public web and hopes for the best. With MCP, it can search a trusted source, fetch a full page, or pull a code sample, then ground the answer in that content.
Microsoft publishes a remote Learn MCP server at https://learn.microsoft.com/api/mcp. Official overview: Microsoft Learn MCP Server overview. No authentication is required. There is no charge to use it. It exposes public Learn documentation only — not training records, not your tenant, not your profile.
No sign-in. You do not need Microsoft 365 admin consent to add it. That removes the usual “which account?” friction.
Trusted content. Answers can cite official Learn pages instead of a random blog from 2021.
MSP-shaped tools. The server exposes three tools: search docs, fetch a full article as markdown, and search code samples. That covers Conditional Access, Intune, Graph PowerShell and Copilot licensing.
That is enough. Grok Bot can search the connector catalog for a match, or add a remote MCP endpoint by URL when you give it one. Microsoft Learn’s public endpoint needs no auth token and no tenant access.
If the bot shows a connector confirmation card, approve it. For Learn there is nothing to sign in to — Microsoft’s docs state authentication is not required.
3. Wait for confirmation
When it is connected, the bot should tell you Microsoft Learn is available. On my account it appears as a connected HTTP connector with three tools:
microsoft_docs_search
microsoft_docs_fetch
microsoft_code_sample_search
4. Optional: add other connectors the same way
Once Learn works, add signed-in connectors (Outlook, Teams, OneDrive, Azure and so on) by naming the service in chat — for example, “add the Outlook connector” — and completing any sign-in card. Start with Learn so you see the pattern without a login wall.
Checking that it works
Do not assume the connector is live until you ask a real question:
Using Microsoft Learn, summarise how to create a Conditional Access policy that requires MFA for all users. Include the official Learn link.
A healthy reply will pull current Entra admin centre steps (Conditional Access → Policies, report-only first, exclude break-glass accounts), include a learn.microsoft.com URL, and avoid invented clicks.
I ran that live while writing this. It returned Microsoft’s “Require multifactor authentication for all users” guidance, including the authentication strength grant and the report-only recommendation.
Second check — force a code sample:
Using Microsoft Learn, give me a Graph PowerShell sample that lists users with Get-MgUser. Include the Learn source link.
Live result: samples such as Import-Module Microsoft.Graph.Users then Get-MgUser -Top 5, plus Connect-MgGraph -Scopes "User.Read.All" patterns, each with a Learn URL.
If the bot answers from memory with no Learn links, say: “Use the Microsoft Learn connector and cite the page.”
Example prompts you can copy
Paste these as-is, then tighten them for your tenant or client.
Quick answers
Using Microsoft Learn, what are the eligible prerequisite licences for Microsoft 365 Copilot? Summarise the commercial table and link the page.
Using Microsoft Learn, what does an Intune Windows compliance policy check for firewall, BitLocker and Defender? Bullet list with the Learn link.
Using Microsoft Learn, explain the difference between Require multifactor authentication and authentication strength in Conditional Access. Cite the docs.
Live Copilot check: Learn returned the licence options page — Copilot as an add-on on qualifying Microsoft 365 / Office 365 / Business plans, with Copilot Business aimed at organisations up to 300 users — plus the requirements page covering identity and mailbox prerequisites.
Step-by-step admin guides
Using Microsoft Learn, walk me through creating a Conditional Access policy that requires MFA for all users. Start in report-only. Exclude break-glass accounts. List every click path from the Entra admin centre and include the official URL.
Using Microsoft Learn, give me the steps to create a Windows device compliance policy in Intune that requires Secure Boot, BitLocker and Microsoft Defender real-time protection. Include prerequisites and the Learn link.
Using Microsoft Learn, how do I assign Microsoft Copilot licences in the Microsoft 365 admin centre after purchase? Include the assign-licences doc link.
PowerShell and Graph code samples
Using Microsoft Learn code samples, show Graph PowerShell to connect with Connect-MgGraph and list the first 50 users (DisplayName, Id). Include the source page.
Using Microsoft Learn, find a PowerShell sample that disables a user with Get-MgUser and Update-MgUser. Warn me about hybrid implications and cite Learn.
Using Microsoft Learn, search for PowerShell samples to work with Conditional Access policies. Prefer official samples and link them.
Comparing options
Using Microsoft Learn, compare Microsoft Copilot Chat vs Microsoft 365 Copilot licensing requirements for a 40-seat Business Premium tenant. Table format, with source links.
Using Microsoft Learn, compare requiring MFA for all users vs requiring MFA only for directory roles. When would Microsoft recommend each? Cite the policy pages.
Client docs, checklists and routines
Using Microsoft Learn, draft a one-page checklist for an MSP onboarding a new Microsoft 365 client: MFA baseline, Intune compliance for Windows, and Copilot licence prerequisites. Every checklist item must include a Learn URL.
Every Monday, use Microsoft Learn to check whether Conditional Access MFA baseline guidance has changed this week. Summarise any material change and link the pages. Do not change my tenant.
Read the latest ticket in Outlook about Intune compliance failures, then use Microsoft Learn to pull the matching Windows compliance settings and suggest what to verify. Do not change policies until I confirm.
Those last two prompts are where Grok Bot gets useful for MSP work, not just another chatbot. One runs on a weekly schedule, and the other combines tenant evidence from a signed-in connector with public guidance from Learn.
Tips and limits
Public docs only. Learn MCP does not see your tenant, users, licences or policies.
Content refresh. Microsoft says the knowledge service refreshes incrementally and does a full refresh about once a day, so brand-new articles can lag briefly.
Ask for sources. Tell the bot to include Learn URLs. If it cannot cite one, treat the answer as unverified.
Verify before you run scripts. Test Graph and PowerShell samples in a lab, check scopes, and confirm the Microsoft Graph PowerShell SDK modules.
Report-only first. When Learn returns Conditional Access steps, keep Microsoft’s advice: create in report-only, review impact, then enable.
Terms of use. Using the Learn MCP server means you agree to the Microsoft Learn Terms of Use.
Closing
MCP connectors are how Grok Bot stops guessing and starts working from live tools. Microsoft Learn is the easiest first connector because it is public, free and immediately useful for Microsoft 365 work.
Add it with one chat prompt, test it with a Conditional Access or Copilot licensing question, then keep a short list of copy-paste prompts next to your admin checklist. From there you can layer signed-in connectors for mail, calendar, files and tenants — with Learn sitting underneath as the shared source of truth for “what does Microsoft say right now?”
Every MSP owner I talk to has the same headache: finding good technicians. Not warm bodies who can reset a password, but people who can walk into a mess nobody has seen before and work out what’s actually going on. So here’s a question that’s been nagging me. If we keep pushing our techs to lean on AI for every problem, are we quietly eroding the very skill we’re struggling to hire?
The fix that works until it doesn’t
Picture a fairly typical morning. A junior tech gets a ticket about mail not flowing for a shared mailbox. They paste the error into Microsoft 365 Copilot Chat, ask for a PowerShell fix for Exchange Online, run what comes back, and the ticket closes. Great outcome?
Maybe. But ask that tech why it broke and there’s a decent chance you’ll get a shrug. They solved the symptom without ever building a mental model of the system. Do that a few hundred times and you have someone who is fast on familiar problems and lost the moment the answer is wrong, the situation is unusual, or the AI simply isn’t available.
That’s the risk as I see it. Copy-paste fixes. No root-cause understanding. A growing dependence on a tool that can be confidently mistaken. And, longer term, a junior pipeline that never matures into the senior people who can mentor the next lot. If nobody struggles any more, where do the next seniors come from?
But I’m not going back
Let me be clear, I’m not arguing we ban AI from the service desk. Copilot summarising a long ticket thread in Teams or Outlook saves real time. Having it explain an unfamiliar Intune policy setting or draft a script you then review is genuinely useful.
The problem isn’t the tool. It’s how we’re letting people use it. An answer engine makes you dependent. A tutor makes you better. Same technology, very different result.
What I’d do as an MSP owner
A few practical things I’d put in place:
Explain the why before applying the fix. If a tech can’t tell you, in plain words, why a command will solve the problem, it doesn’t get run on a customer tenant.
Use Copilot as a tutor, not just an oracle. Encourage prompts like “explain what this error means and what could cause it” rather than “fix this”. Ask it to walk through the reasoning, then challenge it.
Review AI-assisted tickets. Have a senior skim a sample each week. Look for thin understanding and coach it.
Practise without the safety net. Run regular no-AI troubleshooting sessions. Break something in a lab tenant and let the team work it out the old way.
Document the reasoning, not just the resolution. “Ran script, fixed” teaches nobody anything. “Mailbox permissions were inherited wrongly after a migration, here’s how I confirmed it” builds team knowledge.
None of this is complicated. It just requires deciding that skill development is still part of the job, even when a faster shortcut exists.
The real question
AI will make good technicians better. I’m fairly confident about that. What worries me is whether it will make new technicians good in the first place, or just make them look good until the day it matters. The MSPs that win the skilled labour fight won’t be the ones that use the most AI. They’ll be the ones that use it to grow people rather than replace their thinking.
So I’ll put it to you: in your business, is AI building your techs’ problem-solving muscle, or quietly doing the lifting for them?
Most workplace AI I use still sits there politely, waiting for me to type something. Microsoft Scout is different, and that’s exactly why I think MSPs and SMBs need to understand how it works before someone in the business goes looking for the download link.
Quick housekeeping first. Microsoft introduced Scout at Build in June 2026 as its first “Autopilot” agent. On 25 September it renamed the product itself to Autopilot, describing it as “previously called Scout”. Yes, same name as Windows Autopilot, the device provisioning service, which is entirely unrelated. The docs still say Scout, so I will too.
So what is it, really?
Scout is an agent that works on your behalf without being prompted every time. The current Frontier release is a desktop app for Windows 11 and macOS. You describe a task in a chat, Scout picks the tools it needs, works through the steps visibly, pauses for your approval on sensitive actions, then hands back the result or saves files to your workspace.
The tools are the interesting bit. Scout can read and write files in an approved workspace folder, run shell commands, drive a browser to fill in forms, and connect to Microsoft 365. That covers Outlook mail and calendar, Teams chats, meetings and transcripts, SharePoint Lists, and files in OneDrive, SharePoint and Teams. It creates Word, Excel and PowerPoint files, remembers your preferences and can spin up parallel sub-agents.
What makes it “always-on” are two background modes. Heartbeat runs check-in prompts every 15 to 120 minutes while you’re away, and Automations run on schedules or triggers you define. The September announcement goes further: Autopilot becomes cloud-hosted, with its own identity, memory and workspace inside your tenant, and you @mention it in Teams, Outlook and documents like a colleague.
Under the hood it’s built on open-source OpenClaw, with Microsoft adding Entra identity and access controls on top.
The permissions story is where you need to pay attention
Scout operates with the user’s existing Microsoft 365 permissions. It can’t see anything the user can’t. That sounds reassuring until you remember how many SMB tenants I see with broad sharing links scattered across SharePoint. An agent that tirelessly works through everything a user can reach will find your oversharing faster than any auditor.
There’s a finer detail buried in Microsoft’s own Responsible AI FAQ. In the Frontier desktop app, model interactions are processed through GitHub Copilot, under separate terms. When that happens, some Microsoft 365 protections, such as data residency, retention, sensitivity label enforcement and eDiscovery, don’t apply to that processing. That’s why admins must complete an attestation before anyone can use it. Read that page before you tick the box.
Getting access is deliberately fiddly. You need Frontier turned on in the Microsoft 365 admin centre, an Intune policy on devices, the attestation form, and a GitHub Copilot Business or Enterprise seat for each user. Miss any one of those and sign-in fails without a clear message, which will make for entertaining helpdesk tickets.
How I’d approach it
Treat this as a pilot for a handful of technically capable people, not a rollout. Clean up permissions and sharing first. Keep the approval prompts on and resist the temptation to click “Always allow”. Lock down heartbeat and automation permissions tightly, because those run when nobody is watching. And budget carefully: Microsoft says Autopilot runs on usage-based billing, not the fixed Copilot licence.
I genuinely think agents that follow through are where this is heading. But an assistant that acts is a very different beast from one that answers. The organisations that do well here will be the ones that realised their governance needed to be ready before the agent arrived, not after.
If you manage Microsoft 365 Business Premium tenants and you are still treating Tamper Protection as a one-click toggle and EDR in block mode as an afterthought, you are leaving real protection on the table. Both are included with Defender for Business — there is no licence excuse — but the production rollout is more nuanced than the docs suggest.
Here is the playbook I run on every BP tenant.
Prerequisites that bite people
Before either feature does anything useful, devices must be onboarded to Microsoft Defender for Endpoint (or Defender for Business) and reporting healthy in the Defender portal. Until onboarding completes, Tamper Protection literally shows as Not Applicable on the device, and the EDR sensor cannot enforce anything.
Three prerequisites that catch MSPs out:
Devices must be Intune-managed or co-managed with the Endpoint Protection workload pointed at Intune. Co-managed devices where the workload still points to ConfigMgr are not supported by the Intune Tamper Protection policy.
Defender antimalware platform must be at 4.18.1906.3 or later. Modern devices are; stale gold images and the odd Server 2016/2019 host often are not.
If you plan to manage AV exclusions through Intune, set DisableLocalAdminMerge = true in your AV policy. Without it, tamper-protected exclusions silently fail to apply.
Verify all of this on a pilot device with Get-MpComputerStatus, checking IsTamperProtected and AMRunningMode, before you flip anything.
Where to configure
For Tamper Protection, do it in Intune, not the Defender portal. Granular targeting beats a tenant-wide toggle every time.
Intune admin centre → Endpoint security → Antivirus → Create policy → Platform: Windows → Profile: Windows Security Experience → Tamper protection (device): On.
For EDR in block mode, the cleanest path is the Defender portal — it is tenant-wide and does not fight your AV policies:
Microsoft Defender portal → Settings → Endpoints → Advanced features → Enable EDR in block mode → Save.
You can also drive it through Intune via the Defender CSP when you need device-group scoping, but for most BP tenants tenant-wide is correct.
Pilot (5–10 devices) — your own techs plus one cooperative power user. Apply the Tamper Protection policy first, leave it 48 hours, then enable EDR block mode tenant-wide. Watch the Action Center for unexpected Blocked/Prevented entries; confirm IsTamperProtected = True and AMRunningMode = Normal (or EDR Block Mode on third-party AV tenants).
Broader pilot (~25%) — one quiet department, ideally not Finance during end-of-month. Run for a full working week.
Full rollout — assign to your “All Workstations” dynamic group.
Sequencing matters. Enabling EDR block mode before Tamper Protection means a misbehaving LOB app can still be silenced by a local admin disabling Defender — which defeats the point.
Top three pitfalls
Passive-mode false sense of security. If a third-party AV is the primary product, Defender drops into passive mode. EDR block mode still fires, but real-time protection, network protection, ASR rules, and indicators are all inactive. Either document this in the customer-facing security baseline or migrate them off the third-party AV.
Tamper Protection blocking your own policy changes. Once on, you cannot edit AV exclusions or disable real-time protection from the device — and sometimes not cleanly from Intune either. Use troubleshooting mode from the Defender portal for short-lived changes; never disable Tamper Protection at scale.
Forgetting the servers. Windows Server 2012 R2/2016 do not auto-passivate when third-party AV is installed. Set the ForceDefenderPassiveMode registry value before onboarding, or you will have two AV products fighting at boot.
Get the prerequisites right, ring the rollout, and these two features quietly become the most boring — and most valuable — controls in your Business Premium stack.
If you manage Business Premium tenants for SMB clients, Attack Surface Reduction (ASR) rules are arguably the highest-leverage defensive control you’re not fully exploiting. They ship with Defender for Business (included in Business Premium), they cost nothing extra to enable, and they block the precise behaviours that commodity ransomware and living-off-the-land attacks depend on — Office spawning child processes, Win32 API calls from macros, credential theft from LSASS, and PSExec-style lateral movement. This post assumes you already know what ASR is. The goal here is to help L2/L3 engineers deploy it without breaking line-of-business apps.
Prerequisites the documentation underplays
ASR has hard dependencies that silently downgrade rules to “not configured” if missed. Microsoft Defender Antivirus must be the active AV (not passive, not disabled by a third-party product), real-time protection must be on, and cloud-delivered protection must be on — several rules won’t evaluate without cloud lookups. Verify these under Microsoft Defender portal → Endpoints → Configuration management → Device configuration, and confirm the device shows as “Active” in the device inventory. Tamper Protection must also be enabled tenant-wide; without it, local admins or malware can disable ASR in seconds.
Where to configure in Business Premium
Business Premium gives you two supported paths. The simplified experience lives at security.microsoft.com → Device configuration → Next-generation protection / Firewall, but ASR rules specifically are configured through Intune. In the Microsoft Intune admin center, go to Endpoint security → Attack surface reduction and create an “Attack surface reduction rules” profile targeting Windows 10/11. Avoid mixing this with legacy Endpoint Protection templates or Group Policy — conflicting sources result in the classic “last writer wins” behaviour, and you will spend hours chasing phantom rules. If a device is co-managed or has stale GPOs, check Event Viewer → Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational (event IDs 1121, 1122, 5007) to confirm which source applied.
The rollout pattern that works
Do not flip rules straight to Block. The proven pattern is: enable every rule in Audit mode, leave it for two to four weeks, then review the ASR report at security.microsoft.com → Reports → Attack surface reduction rules. Filter by rule and by device, identify the noisy ones, and build per-rule exclusions before switching to Block. Where available, use Warn mode as a staged step — the user gets a toast and can unblock once, which is invaluable for finance teams running macro-heavy spreadsheets. Warn mode is Windows 10 1809+ only; older builds silently treat it as Block.
Start with the “standard protection” set Microsoft recommends: Block credential stealing from LSASS, Block abuse of exploited vulnerable signed drivers, and Block persistence through WMI event subscription. These have the lowest false-positive rate and the highest return. The two rules that most commonly break things are “Block Office applications from creating child processes” (breaks legitimate mail-merge and older add-ins) and “Block executable content from email client and webmail” (breaks zipped installers).
Pitfalls to pre-empt
Exclusions are path-based and case-sensitive on the file name portion — wildcards work on folders, not extensions. Per-rule exclusions (added in later releases) are preferred over global Defender exclusions; use them so you don’t inadvertently hole-punch the whole AV. If a rule appears to do nothing, check whether the device is in EDR block mode and whether Defender is the active AV — ASR is silently disabled under third-party AV. Finally, ASR events do not always surface as alerts; plumb them into your SIEM via the Defender API or Advanced Hunting (DeviceEvents where ActionType startswith "Asr").
Most MSPs I work with have shipped App Protection Policies (APP) to a client by now. BYOD iPhone, Outlook Mobile, a PIN, a block on copy-paste to personal apps — done, move on. But when the client’s compliance consultant asks how the data is actually protected, or why a specific action blocks on an unenrolled Android, the hand-waving starts. Here’s what’s actually going on under the covers.
The Intune App SDK, not the OS, is doing the work
An App Protection Policy doesn’t manage the device. That’s the whole point of MAM-without-enrolment. Enforcement lives inside the app itself, courtesy of the Intune App SDK that Microsoft has compiled into Outlook, Teams, Word, Excel, OneDrive, and a growing list of line-of-business apps wrapped with the App Wrapping Tool. When the user signs in with their work identity, the SDK phones home to the Intune service, pulls down the policy that applies to that user plus that app, and starts enforcing it in-process.
That’s why policies are scoped to user and app, not device. The OS on an unenrolled phone has no idea this is happening. The app is quietly running a second policy engine beside the operating system — and a separate wipe scope, which is what lets you revoke org data from a personal device without nuking the phone.
The broker is the hinge
On iOS, Microsoft Authenticator acts as the broker. On Android, it’s Company Portal — even when no device enrolment exists. The broker holds the work identity token and passes it to every SDK-enabled app, which is why one PIN prompt in Outlook covers Teams and Word for the next session. If the broker isn’t installed, APP quietly degrades: the SDK still enforces policy on its own app, but cross-app single sign-on and some advanced integrity checks fall away. A detail worth surfacing in onboarding.
Conditional launch is a local state machine
The under-appreciated piece is Conditional Launch. Every time a managed app resumes, the SDK runs a checklist: is the OS version above the floor, is the device jailbroken or rooted, is the Play Integrity or App Attest result clean, is the user still in good standing with Entra ID, how long since the last check-in? If any requirement fails, the SDK can warn, block, or selectively wipe org data — on its own, from a cached policy, without Intune needing to reach the device at that moment.
The data boundary works the same way. “Save copies of org data” restricted to OneDrive for Business, “Open-in” restricted to other managed apps, encrypted cache at rest — these are decisions made inside the app process by asking the SDK whether the target app is on the allow list and signed in with the same work identity.
Where Conditional Access joins in
The final layer is the Entra ID grant control Require app protection policy. This is what makes APP enforceable rather than optional. The token issued to the app is stamped with a claim confirming the app is compliant with its APP at sign-in. Conditional Access can refuse the token entirely if the app isn’t protected, and with Continuous Access Evaluation the refusal can happen mid-session. That’s the seam between the identity plane and the data plane.
What I’d tell a junior engineer
APP is a policy engine bolted into each app, gated by the broker, validated by Conditional Access. Understand those three layers and the “why did this break” tickets get a lot shorter.
The Essential Eight Mitigation Strategy #3 – Configure Microsoft Office Macro Settings requires organizations to disable Office macros by default for users without a demonstrated business need.1In cloud-only environments using Microsoft 365 Business Premium and Microsoft Intune, this can be achieved through multiple complementary approaches:
Configuration Profiles (Settings Catalog or Imported Administrative Templates)
Attack Surface Reduction (ASR) Rules
Microsoft Defender for Endpoint capabilities (included in Business Premium)
However, there is an important limitation: Microsoft 365 Business Premium includes Microsoft 365 Apps for Business, which has limited support for the Office Cloud Policy Service—only privacy-related policies are supported.2For full macro control policies, you must use Configuration Profiles in Intune instead.3
Microsoft provides pre-built configuration profiles aligned with ACSC guidance. This is the fastest and most reliable method for Essential Eight compliance.
Step-by-Step: Import ACSC Office Hardening Policy
Detailed Steps:9
Create Target User Group
Create an Azure AD security group for “All Office Users”
This group will receive Office apps and hardening policies
Method 2: Manual Configuration Using Settings Catalog
If you prefer granular control, you can manually configure macro policies using Intune’s Settings Catalog.
Step-by-Step: Create Custom Macro Blocking Policy
Create New Settings Catalog Policy
Navigate to: Microsoft Intune admin center (intune.microsoft.com)
Go to: Devices > Configuration policies > Create > New Policy
Platform: Windows 10 and later
Profile type: Settings catalog
Name: “Office Macro Security – Disable All Macros”
Configure Settings for Each Office Application
The following settings must be configured for each Office application (Word, Excel, PowerPoint, Access, Outlook):1415
Microsoft Office 2016 (Global Settings)
Setting Path
Configuration
Microsoft Office 2016 > Security Settings
Automation Security
Enabled
– Set Automation Security level
Disable macros by default
Disable VBA for Office applications
Enabled
Security Settings > Trust Center
Allow mix of policy and user locations
Disabled
Microsoft Excel 2016
Setting Path
Configuration
Excel Options > Security > Trust Center
VBA Macro Notification Settings
Enabled
– VBA Macro Notification
Disable all without notification
Block macros from running in Office files from the Internet
Enabled
Trust access to Visual Basic Project
Disabled
Turn off trusted documents
Enabled
Turn off Trusted Documents on the network
Enabled
Excel Options > Security > Trust Center > Trusted Locations
Allow Trusted Locations on the network
Disabled
Disable all trusted locations
Enabled
Microsoft Word 2016
Setting Path
Configuration
Word Options > Security > Trust Center
VBA Macro Notification Settings
Enabled
– VBA Macro Notification
Disable all without notification
Block macros from running in Office files from the Internet
Enabled
Trust access to Visual Basic Project
Disabled
Turn off trusted documents
Enabled
Turn off Trusted Documents on the network
Enabled
Word Options > Security > Trust Center > Trusted Locations
Allow Trusted Locations on the network
Disabled
Disable all trusted locations
Enabled
Microsoft PowerPoint 2016
Setting Path
Configuration
PowerPoint Options > Security > Trust Center
VBA Macro Notification Settings
Enabled
– VBA Macro Notification
Disable all without notification
Block macros from running in Office files from the Internet
Enabled
Trust access to Visual Basic Project
Disabled
Turn off trusted documents
Enabled
Turn off Trusted Documents on the network
Enabled
PowerPoint Options > Security > Trust Center > Trusted Locations
Allow Trusted Locations on the network
Disabled
Disable all trusted locations
Enabled
Microsoft Access 2016
Setting Path
Configuration
Application Settings > Security > Trust Center
VBA Macro Notification Settings
Enabled
– VBA Macro Notification
Disable all without notification
Block macros from running in Office files from the Internet
Enabled
Turn off trusted documents
Enabled
Turn off Trusted Documents on the network
Enabled
Application Settings > Security > Trust Center > Trusted Locations
Allow Trusted Locations on the network
Disabled
Disable all trusted locations
Enabled
Microsoft Outlook 2016
Setting Path
Configuration
Security > Trust Center
Apply macro security settings to macros, add-ins and additional actions
Enabled
Security settings for macros
Enabled
– Security Level
Never warn, disable all
Assign the Policy
Assignments: Select your target user or device groups
Review + Create
Attack Surface Reduction (ASR) Rules for Essential Eight Compliance
Can ASR Rules Meet Essential Eight Requirements?
Yes, partially. Windows Attack Surface Reduction rules provide critical additional protections that complement macro blocking policies and help meet Essential Eight requirements.1617
ASR rules are included with Microsoft 365 Business Premium via Microsoft Defender for Business and can be deployed through Intune.18
Essential Eight-Relevant ASR Rules
The following ASR rules directly support Essential Eight mitigation strategies:1920
ASR Rules for Office Macro Security
ASR Rule Name
GUID
Essential Eight Alignment
ISM Control
Block Win32 API calls from Office macros
92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b
✅ Required – Prevents macros from making dangerous system calls
ISM-1673
Block Office applications from creating child processes
Review alerts in the Microsoft 365 Defender portal (security.microsoft.com)
Validate ASR Rule Effectiveness
Navigate to: Microsoft 365 Defender portal > Reports > Attack surface reduction rules
Review triggered events for each ASR rule
Identify false positives and create exclusions if needed
Exception Management: Allowing Trusted Macros
Some users may have legitimate business requirements for macros. The Essential Eight framework accommodates this through Trusted Publishers or Trusted Locations.30
Option 1: Trusted Publishers (Recommended)
Trusted Publishers use digital signatures to verify macro authenticity. This is the preferred method for Essential Eight compliance.31
Step-by-Step: Enable Trusted Publishers
Create Exception Group
Create Azure AD group: “Office Macro Users – Trusted Publishers”
Create Azure AD security groups (“All Office Users”, “Macro Exception Users”)
Document current macro usage across organization
Establish exception approval process
Communicate changes to end users
Phase 2: Baseline Policy Deployment
Download ACSC Office Hardening policy from GitHub
Import policy to Intune Configuration Profiles
Download and import OLE prevention PowerShell script
Assign policies to pilot group
Test policy application on pilot devices
Phase 3: ASR Rule Deployment
Create ASR policy in Endpoint Security
Configure 5 Office-related ASR rules in Audit mode
Assign to pilot group
Monitor events in Microsoft 365 Defender for 2-4 weeks
Phase 4: Production Rollout
Review audit logs for false positives
Create ASR exclusions if needed
Switch ASR rules to Block mode
Expand deployment to all users
Configure Trusted Publisher policies for exception users
Phase 5: Ongoing Management
Monitor Defender for Endpoint alerts
Review exception requests quarterly
Validate Trusted Publisher certificates annually
Update policies as new ISM controls are released
Conclusion
Meeting the Essential Eight requirements for disabling Office macros in a cloud-only environment with Microsoft 365 Business Premium is achievable through:
Intune Configuration Profiles: Disable macros at the Office application level using Settings Catalog or imported administrative templates
Attack Surface Reduction Rules: Deploy complementary ASR rules to block macro-related attack behaviors
Exception Management: Use Trusted Publishers for users with legitimate macro needs
Continuous Monitoring: Leverage Microsoft Defender for Endpoint for visibility and alerting
While Office Cloud Policy Service has limitations with Business Premium, Intune Configuration Profiles provide full macro control capabilities needed for Essential Eight compliance. ASR rules successfully accommodate Essential Eight requirements by providing the necessary technical controls, particularly ISM-1673 (blocking Win32 API calls from macros).
The combination of these approaches provides defense-in-depth aligned with ACSC guidance and enables organizations to achieve Essential Eight Maturity Level 3 for macro security.
References
Microsoft Official Documentation
Microsoft Learn – Essential Eight Guidance
Essential Eight configure Microsoft Office macro settings
Implementing Conditional Access policies requiring device compliance in Microsoft 365 requires careful planning and a phased approach to minimize disruption while maintaining security. This comprehensive guide provides step-by-step instructions specifically tailored for small businesses.
1. Prerequisites and Initial Setup
Required Licenses
Microsoft Entra ID P1 or P2 – Required for Conditional Access
Microsoft Intune – Required for device compliance management
Microsoft 365 Business Premium or higher for small businesses
Essential Preparations
Configure Emergency Access Accounts
Create at least two emergency access (break-glass) accounts
Exclude these accounts from ALL Conditional Access policies
Store credentials securely and separately
Create Device Compliance Policies First
Define minimum OS version requirements
Set encryption requirements
Configure password/PIN requirements
Establish jailbreak/root detection settings
Enable User Registration for MFA
Allow users to register authentication methods before enforcing policies
Communicate registration requirements to all users
2. Phased Rollout Strategy
Phase 1: Foundation (Weeks 1-2)
Objective: Establish baseline security and prepare infrastructure
Create policies in Report-Only Mode
Block legacy authentication protocols
Secure the MFA registration page
Target privileged accounts first with phishing-resistant MFA
Phase 2: Pilot Testing (Weeks 2-4)
Objective: Test with limited user groups
Pilot Group Selection
Start with 5-10% of your organization
Include IT staff and willing early adopters
Avoid executives and VIPs initially
Ensure representation from different departments
Creating the Policy in Report-Only Mode
Navigate to Microsoft Entra admin center → Conditional Access → Policies
Create new policy with these settings:
Name: “Require Device Compliance – Pilot”
Users: Select pilot group
Cloud apps: Start with non-critical apps
Grant: Require device to be marked as compliant
Enable policy: Report-only
Phase 3: Gradual Expansion (Weeks 4-8)
Objective: Progressively include more users and applications
Automated Phased Rollout Approach
If using the Conditional Access Optimization Agent (requires Microsoft Security Copilot):
The agent automatically creates a 5-phase rollout plan
Groups are assigned based on risk and impact analysis
Automatic progression between phases based on success metrics
