Defender for Cloud Apps session policy

Most MSPs treat Conditional Access as a light switch. Allow or block. Compliant device or not.

That works right up until a director needs OneDrive from a hotel laptop. Or a contractor needs SharePoint from a personal Mac. So you carve an exception, and the exception slowly becomes the policy.

There’s a third option sitting between allow and block. Almost no one in the SMB world turns it on.

It’s called a session policy, and it lives inside Defender for Cloud Apps. If your client is on E5 or Microsoft 365 E5 Security, they’re already paying for it.

What is a session policy, really?

A session policy is a real-time guardrail that fires after the user signs in. It rides along inside the browser tab.

It can block a download. It can block an upload. It can block copy-paste. It can force a sensitivity label on a file before it leaves OneDrive. It can make a user re-prove MFA before doing something sensitive — all without touching the device.

That’s not access control. That’s session control. Think of it as a referee inside the meeting, not a bouncer at the door.

It needs two pieces to fire. A Conditional Access policy in Entra ID that routes the session through Defender for Cloud Apps using Conditional Access App Control. And a matching session policy in the Defender portal that decides what to do once the session is in flight. Microsoft’s own Conditional Access app control overview is worth a read because it shows the reverse-proxy path the session actually takes.

One licensing note. Defender for Cloud Apps is not in Business Premium. You need E5, M365 E5 Security, or the standalone MDCA add-on. Plenty of SMBs already have it bundled and never realise.

Step-by-Step: blocking download to unmanaged devices

The killer scenario. Someone signs in to OneDrive from a personal laptop. They can read. They can edit in the browser. They cannot save a single file locally. No agent, no Intune enrolment, no work touching their device.

Build the Conditional Access policy

In the Microsoft Entra admin centre, go to Protection > Conditional Access > Policies and start a new policy. Scope it to your pilot group. For the cloud app, choose Office 365. Leave Grant on Grant access with no requirements — the heavy lifting happens elsewhere.

Turn on App Control

In the Session block, tick Use Conditional Access App Control and pick Use custom policy from the dropdown. That single tick is what tells Entra to hand the session to Defender. The full guidance lives in the Microsoft Learn how-to.

Move to the Defender portal

Now jump to security.microsoft.com. Under Cloud apps > Policies > Policy management, create a new Session policy. Start from the Block download based on real-time content inspection template — it saves a lot of clicks.

Filter to OneDrive and unmanaged devices

Set Activity source to Office 365 > OneDrive for Business. Add a filter: Device tag = Unmanaged. The action becomes Block file download.

Write a real block message

Don’t ship the Microsoft default. Tell the user why the file won’t download and what to do next. A blank “blocked by policy” page makes users fight the system and ring the helpdesk.

Run it in monitor-only first

Set the policy to Monitor only for a week. Watch the activity log. Confirm you’re catching the right sessions, on the right apps, against the right users. Then flip to Block. Microsoft’s create-a-session-policy walkthrough covers the screens for both modes.

Why this actually changes behaviour

Here’s the real win. Your director still gets OneDrive on the hotel laptop. The board paper opens in the browser. They can read it, comment on it, work through it.

They cannot drop it into the hotel laptop’s downloads folder.

That’s not a compromise. That’s the policy doing what you actually wanted the whole time.

“But why can’t I just block unmanaged devices outright?”

You can. You’ll also block every legitimate contractor, every guest reviewer, every consultant on a personal machine. Block is a single-use tool. Session policy is a scalpel.

Notice what’s missing? No agent on the device. No MDM. No certificate enrolment. The browser gets reverse-proxied through an *.mcas.ms URL and the session is policed in flight. Edge users get it in-browser with no URL change.

A copy-paste summary of what you’ve actually built looks like this:

Session policy: OneDrive – Block download from unmanaged
  Activity source : Office 365 → OneDrive for Business
  Device filter   : Device tag = Unmanaged
  Action          : Block file download
  Block message   : Custom — explain WHY + WHAT TO DO
  Content scan    : All files
  Phase           : Monitor → Block after 7 days

Notice what’s not in there. No list of apps. No list of file types. The whole policy keys off the device tag, because that’s the bit you can trust — Entra knows whether a device is compliant or unmanaged; the user can’t lie about it.

Where MSPs trip up

Three things bite people on the first rollout.

The Conditional Access policy must include the session control. If App Control isn’t ticked in CA, nothing routes to Defender. Many MSPs build the two policies as separate stories. They’re one story.
Native clients bypass MDCA. Outlook desktop, OneDrive sync, Teams desktop — none of them route through the reverse proxy. If you genuinely need to force browser, use the Entra session control Use app enforced restrictions on top, and read the Conditional Access session controls page before you go further.
Certificate chains matter. If the SaaS app has a partial chain, the proxy goes sideways. Test before you scope wide.

My recommendation

If you’ve got a client on E5 or M365 E5 Security and you’re not running at least one session policy, you’re leaving the most valuable thing in their stack switched off. Walk in next Monday with exactly one policy — block download from unmanaged for OneDrive. Monitor for a week. Flip to block. Show them the activity log.

Session policies aren’t there to keep users out. They’re there to let them in without the data following them out.

Most SMB tenants have a guest graveyard

Most SMB tenants I look at have a “Guest Users” list that’s basically a graveyard. People invited for a project that finished in 2022. A contractor whose engagement ended last March. Somebody’s external accountant who hasn’t signed in since the BAS that prompted the invite.

Nobody removes them. Nobody can remember why they were added. Nobody’s even sure who should remember.

That’s not a guest problem. That’s a governance problem.

Now do the same exercise with Global Administrator. Or Privileged Role Administrator. Or that mystery security group somebody pinned to a SharePoint site three years ago and called “Finance – All”. Same pattern. Stale access. No owner. No expiry.

This is exactly what Access Reviews in Entra ID Governance is built to fix — and most MSPs I talk to either don’t know they’re licensed for it or have never actually run one.

Time to fix that.

What is Access Reviews, really?

Access Reviews is a recurring “are you sure?” loop. You point it at a group, an application, a privileged role, or every guest in your tenant. On a schedule you pick, it emails a reviewer — you, the group owner, or the user themselves — and asks them to confirm whether each person still needs the access they’ve got.

If the reviewer says no, or doesn’t reply and you’ve configured “no response = deny”, the access gets removed automatically when the review ends. No tickets. No spreadsheet. No “I’ll get to it next quarter”.

It’s the same job your auditor wants you to do at a desktop level. Just done in the portal, on a timer, with an audit trail attached.

What you need to run one

Licensing trips most people up here. Access Reviews is an Entra ID P2 or Entra ID Governance feature, and licensing is per user, not per tenant. Every user whose access you’re reviewing needs to be covered. Guest accounts don’t need a license to be reviewed, which is the one bit of good news.

Business Premium customers don’t have P2 in the box. If they want this, they need Microsoft 365 E5 or the Entra ID Governance add-on. Tell the client up front — don’t promise the feature and discover the gap at invoice time.

You’ll want Identity Governance Administrator or Global Administrator to set the first review up. Group owners can run reviews on their own groups once an admin enables the toggle in the Access Reviews settings.

Step-by-Step: a recurring guest review

Start here on every tenant. It’s the easiest win.

Open the portal

Sign in to entra.microsoft.com as Identity Governance Administrator. Go to ID Governance > Access Reviews > New access review.

Pick what to review

In Select what to review, choose Teams + Groups, then All Microsoft 365 groups with guest users. This is the magic option. It creates one recurring review that sweeps every M365 group containing guests, across the whole tenant, automatically, forever.

Set Scope to Guest users only.

Pick your reviewers

Pick Group owners with a fallback. Group owners actually know whether Alice from the partner agency still needs Teams access. You don’t. You also don’t want to be reviewer-of-last-resort for fifty groups.

Set the schedule

Recurrence: Quarterly. Duration: 5 days. Long enough that nobody can claim they were on leave. Short enough that the next quarter doesn’t lap it.

Set the settings that actually matter

This is where most people skim and lose the whole value of the feature. Slow down.

Auto-apply results to resource: On. Without this, denied users stay in the group until somebody manually clicks apply. They never do.
If reviewers don’t respond: Remove access. Yes, really. If the owner can’t spend two minutes confirming a guest, the guest goes.
Justification required: On. Forces reviewers to type a reason for “keep”. Stops the rubber-stamp click-through.
Mail notifications + reminders: On.

Name it Quarterly Guest Review - All M365 Groups, hit Create, done.

Step-by-Step: privileged groups and admin roles

Same engine, different doorway. PIM for Entra roles and PIM for Groups each have their own access review entry point — not the one above.

For Entra admin roles

Open PIM > Microsoft Entra roles > Access reviews > New. Review every role with active or eligible assignments. Reviewer = the user themselves, because self-attestation forces them to type a justification. Add a second-stage approver if you want belt-and-braces. Recurrence: every 90 days for admin roles. No exceptions.

For privileged groups

If you’re using PIM for Groups to gate access to sensitive things, you can review the eligible members on the same cadence. Same wizard, hosted under PIM. Same settings. Same auto-apply.

Notice what’s missing? PowerShell. None of this needs it. Portal only.

One artefact you can paste into every client runbook

Guest access:     quarterly, 5-day window, owner-reviewed,
                  no response = remove, auto-apply on.
Admin roles:      every 90 days, self-attest + 2nd stage,
                  no response = remove, auto-apply on.
PIM for Groups:   every 90 days, owner-reviewed,
                  no response = remove, auto-apply on.

Notice what’s not in there? Anything called “annual”. Annual reviews don’t do anything except let stale access fester for eleven and a half months. If the cadence isn’t quarterly or better, you don’t have a control — you have a calendar reminder.

Why this actually changes behaviour

Before: “I’ll clean up guests when I get a chance.” After: “The system already did it last Tuesday.”

That’s the shift. Access Reviews moves access cleanup from a thing humans intend to do into a thing that happens whether they intend to or not.

For an MSP the win is bigger. Every client tenant you manage produces a quarterly evidence trail — who reviewed what, what got removed, who signed off. Exactly the evidence the cyber insurer asks for at renewal. Exactly the evidence an SMB1001 or Essential Eight auditor wants on the table. According to the Access Reviews FAQ, reviewers and decisions are captured against each instance, so the audit trail is already there — you just have to turn the reviews on.

You’re not selling “we’ll clean up your guests” anymore. You’re selling governance with a paper trail.

Access Reviews isn’t there to help you remember to remove stale access. It’s there to remove it whether you remember or not.

If you’re not turning this on for your clients, you’re leaving the easiest governance win in Microsoft 365 on the table.

What is Microsoft Agent 365, really?

Most folks I talk to think agents are just Copilot with extra steps. They’re not.

A Copilot prompt is a single user, asking a single question, in a single session. An agent keeps running. It has tools, it has access, it makes decisions, and it does all of that whether you’re watching or not.

Agents don’t sleep. They also don’t ask permission.

That’s the part nobody seems ready for. Last year your tenant had users. This year it has users and agents. Some you bought, some your developers built, some your staff spun up in Copilot Studio over the weekend and forgot about.

So here’s the question I keep asking MSPs: do you actually know how many agents are running in your client’s tenant right now? If the answer is “probably some”, that’s not governance. That’s hope.

Microsoft Agent 365 is the control plane for agents. That’s it. It’s not a new agent. It’s not a new Copilot. It’s the place you go to see every agent in the tenant, decide what each one is allowed to do, and shut down the ones that shouldn’t be there.

Think of it like the Microsoft 365 admin centre, but for non-human accounts. The agents your team built. The agents your vendors sold you. The agent embedded inside that SaaS app marketing signed up for last quarter. All of them, in one registry, with one set of policies.

It went generally available on 1 May 2026 at USD$15 per user per month, and it pulls Microsoft Entra Agent ID(opens in new window), Microsoft Purview, and Microsoft Defender into a single agent lifecycle story. The official overview lives on Microsoft Learn(opens in new window).

Notice what’s missing? You. The user. Agent 365 isn’t an end-user tool. It’s for admins, MSPs, and security folks. It’s the dashboard your clients don’t see — and the one that keeps them out of trouble.

Step-by-Step: Finding the agents already in your tenant

The first thing I’d do in any tenant is just look. You’ll be surprised.

Sign in to the Microsoft 365 admin centre

Go to admin.microsoft.com as a Global Admin or AI Administrator.

Open the Agents workload

In the left navigation, expand Agents and select Overview. That’s the Agent 365 dashboard. If the tenant has a qualifying licence, you’ll see Agent 365 branding. If it doesn’t, you still get the baseline agent management view.

Review the registry

Select All agents. This lists every agent the tenant knows about — Copilot Studio agents, declarative agents, SharePoint agents, third-party agents, and anything registered via the new Agent 365 API. Each one shows its owner, source, and current status. The admin centre docs(opens in new window) walk through the columns.

Hunt for ownerless agents

Filter by owner. Anything marked ownerless is a red flag — that’s an agent doing things in the tenant with no human accountable for it. Assign an owner or block it. Don’t leave it.

Apply a policy

From an agent card, set access policies — who can run it, what data it can touch, whether it needs review before it publishes. Use the policy templates rather than rolling your own.

Before Agent 365, the question was “what agents are we using?” After Agent 365, the question is “what agents are we allowing?” Different question, different answer.

Why this actually changes the game

Here’s the real win. Agents inherit risk in a way users don’t. A user clicks a phishing link and one mailbox is compromised. An agent with delegated access and a bad prompt can touch SharePoint, send mail, and rewrite records — at machine speed, across hundreds of users — before anyone notices.

That’s why Agent 365 leans on Entra Agent ID to give every agent a first-class identity. No more agents hiding behind a generic service account. Each one shows up in sign-in logs, audit logs, Conditional Access, and Defender. You can revoke an agent the same way you’d revoke a user.

That’s not a feature. That’s a fundamental shift in how you secure a tenant.

My recommendation?

If you’re an MSP, start the conversation with your clients this quarter. Open the admin centre. Show them the agent list. Most of them have no idea what’s in there, and the longer they don’t know, the bigger the eventual cleanup.

If you’re not showing your clients this, somebody else will — and they’ll be the ones writing the agent governance policy on your client’s tenant.

Agent 365 isn’t there to add another dashboard to your day. It’s there to stop the shadow AI mess before it starts.

Intune compliance policies + Conditional Access integration

Most people I speak to think the work of locking down devices in Microsoft 365 is creating the Intune compliance policy. They tick the boxes — BitLocker on, minimum OS, no jailbreaks — hit Save, and walk away feeling secure.

They aren’t.

A compliance policy on its own does precisely nothing to a sign-in. It’s a label. Intune looks at a device, decides “compliant” or “not compliant”, and writes that state back to Entra ID. That’s it. Nothing is blocked. Nothing is challenged. The policy is information, not enforcement.

The enforcement lives somewhere else entirely. It lives in Conditional Access.

If you’re not wiring those two things together, you’ve done half a job. And the half you skipped is the half that actually protects the tenant.

What is an Intune compliance policy, really?

Think of a compliance policy as a health check that runs on the device and ships the verdict back to your tenant. Encrypted? Patched? Joined to your tenant? Defender running? Out comes a true/false, and Entra ID writes it onto the device record.

That verdict is now available as a signal. Anything that can read Entra signals — and Conditional Access is the big one — can use it to make access decisions.

So the compliance policy is the sensor. Conditional Access is the gate. You need both, or you have neither.

Step-by-Step: wiring compliance to Conditional Access

Portal only. No PowerShell. This is what I do on every Business Premium tenant I touch.

Fix the tenant default first

Open the Intune admin center, go to Devices > Compliance > Compliance policy settings.

Find the setting Mark devices with no compliance policy assigned as. It ships set to Compliant.

Change it to Not compliant. Save.

That one setting is the difference between “any device in my tenant counts as good” and “a device has to earn it”. You’d be amazed how many tenants I audit where this is still on the default.

Build the compliance policy

Same portal. Devices > Compliance > Policies > Create policy. Pick Windows 10 and later (start there — do iOS and Android next).

Use the settings catalog options to set sensible rules — require BitLocker, a minimum Windows build, Defender real-time protection on, Defender signatures up to date. Don’t try to be heroic on day one. Set what you can defend with a straight face. Microsoft’s own walkthrough is the canonical reference.

In Actions for noncompliance, do not leave the default of “Mark device noncompliant: 0 days”. Give yourself a grace window — 1 to 3 days — and add a Send email to end user action a day earlier. People deserve a heads-up before they’re locked out of email.

Assign to a pilot user group. Not all users. A pilot group.

Build the Conditional Access policy

Now flip over to the Entra admin center: Entra ID > Conditional Access > Policies > New policy.

Users: include your pilot group. Exclude your break-glass account. Always.

Target resources: All resources.

Grant: Require device to be marked as compliant. Save.

And here’s the critical bit — set Enable policy to Report-only. Not On. Report-only.

Users:       Pilot group
Exclude:     Break-glass account
Resources:   All resources
Grant:       Require device to be marked as compliant
Enable:      Report-only

Notice what’s missing? MFA. That belongs in a separate policy. One policy, one job. Stack them, don’t fuse them.

Watch report-only for a week

Sign-in logs > Report-only tab. You’re looking for users who would have been blocked and shouldn’t have been — usually a missing enrollment, a personal device that needs the App Protection path instead, or a service account.

When the report-only data is clean, flip the toggle to On. Microsoft’s compliant-device CA template walks the same path.

Why this actually changes behaviour

“But MFA is already on. Isn’t that enough?”

It isn’t. MFA proves the user. Compliance + CA proves the device. Token theft doesn’t care about your MFA prompt — it cares whether the device the token landed on is one you trust. This is the bit MFA-only tenants are missing.

It also collapses three messy conversations down to one. “Is this laptop ours? Is it patched? Is it encrypted?” All of it rolls into one signal — compliant, or not. Conditional Access reads that one signal and decides. No more inventory spreadsheets. No more guessing.

And if you’re an MSP, this is the most defensible artefact you can show a client during an incident. The device was non-compliant. Access was blocked. That’s a finished sentence.

A compliance policy isn’t there to make a list of bad devices. It’s there to make sure they never sign in.

Privileged Identity Management (PIM) for Entra roles

Walk into most SMB tenants and check who holds Global Administrator. You’ll find at least one. Often three. Sometimes more. All permanent. All active. All the time.

That’s standing privilege. And it’s the biggest gift you can hand a token thief.

Most MSPs I talk to know about Privileged Identity Management. They’ve seen it in the Entra admin centre. They just don’t switch it on for clients, because they assume it’s an enterprise thing — too expensive, too complicated, too overkill for a 25-seat business.

Wrong on all three.

What is PIM, really?

PIM is just-in-time admin access. You stop being a Global Administrator all day every day, and start being eligible for it. When you need the role, you put yourself in for a fixed window, with a justification and a record. A few hours later it drops off. You’re back to a normal user.

That’s not least privilege as a slogan. That’s least privilege as a clock.

You can layer MFA on activation, approval workflows where one admin signs off on another’s elevation, and access reviews that quietly remind you each quarter that someone’s eligibility hasn’t been used in 90 days. All portal-driven. No scripts. Microsoft’s overview of PIM is worth a read, but the licensing point is the one that trips everyone up.

PIM needs Entra ID P2 or Entra ID Governance. That’s not in Business Premium. But — and this is the part MSPs miss — you only need to licence the admins, not every seat. Three admin accounts is your premium. Compare that to one incident.

Step-by-step: switching on PIM for Global Administrator

Run through this in the Entra admin centre. Sign in as a Global Administrator and licence the admin accounts you want under PIM first.

Park a break-glass account

Before touching a role, create a dedicated break-glass admin. Permanent active Global Administrator. Long random password in your password manager. Excluded from every Conditional Access policy. Document it somewhere you can find at 2am.

This is the one account PIM doesn’t touch. Skip this step and you’ll lock yourself out the first time MFA goes sideways.

Open ID Governance

ID Governance → Privileged Identity Management → Microsoft Entra roles → Roles.

Configure role settings for Global Administrator

Select Global Administrator → Role settings → Edit. Microsoft documents every option here; the ones that earn their keep look like this:

Activation maximum duration:   4 hours
Require MFA on activation:     Yes
Require justification:         Yes
Require approval to activate:  Yes (2 approvers, not self)
Permanent eligible assignment: Disallowed
Notification on activation:    All Global Admins

Notice what’s missing? PowerShell. None of this needs it.

Move existing GAs from active to eligible

Assignments → find each Global Administrator → use the assign roles flow to make them eligible instead. Same permissions — only when they ask for them.

Schedule an access review

Under Access reviews, set up a quarterly review of all eligible Global Administrators. Configure it to auto-remove on no response. The clients who think this is overkill are the clients who’ll have an ex-staffer with admin rights twelve months from now.

Why this actually changes behaviour

PIM isn’t a tool. It’s a posture. The second a Global Admin has to type a reason and wait for approval, two things happen — they stop using GA for the trivial stuff, and someone else sees every elevation.

“But our admins will hate this.”

They’ll hate it for a week. Then they’ll forget it’s there, because activation is two clicks. And the first time you can prove with an audit log that no privileged account was active during an incident, you’ll wonder how you ran tenants any other way.

A standing Global Admin is a key under the doormat. PIM is the locksmith.

If you’re not setting this up for your clients, you’re leaving the front door open and calling it security.

Defender XDR unified incident queue

Most MSPs I talk to are still triaging Defender alerts one console at a time. Open Defender for Endpoint, jump to Defender for Office 365, check Entra sign-in logs, back to the device timeline. Five tabs, five clocks, no story.

That’s not response. That’s archaeology.

Defender XDR fixed this. The unified incident queue sits in the Microsoft Defender portal and stitches signals from Endpoint, Office 365, Identity, Cloud Apps and Entra into a single container called an incident. One incident, one timeline, one place to act.

If you’re still working from individual alert lists, you’re doing the correlation work the platform already did for you.

What is the unified incident queue, really?

An alert is one signal — a flagged email, a process anomaly, a risky sign-in. An incident is what Defender builds when it stitches several of those alerts into one attack story across products. Same user, same device, same attacker IP, same hour, one incident.

You stop looking at noise and start looking at attacks. Microsoft frames it exactly that way in Incidents and alerts in the Microsoft Defender portal.

Notice what’s missing? Sentinel. You don’t need it to get value from this queue.

Step-by-Step: Working an incident properly

Open the queue

In security.microsoft.com, expand Investigation & response > Incidents & alerts > Incidents. That’s your home page now. Pin it.

Triage the top of the list

Sort by Severity. For each new incident, assign an owner, set status to In progress, and add a tag like ransomware-suspect or bec-suspect so the rest of your team can filter on it. Microsoft walks through this on Manage incidents in Microsoft Defender.

Open the attack story

Inside the incident, click Attack story. You get a graph — users, devices, files, mailboxes — with events in order. This is where the correlation pays off. You’re not joining tabs in your head anymore.

Hunt for the rest of it

If the incident feels like one footprint of a bigger campaign, open Hunting > Advanced hunting and run a KQL query against the relevant table. Bookmark the Advanced hunting overview(opens in new window) — it lists every table the queue can see across all the Defender workloads.

A starter:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("Invoke-WebRequest","DownloadString","certutil")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine

Notice what’s missing? PowerShell. You’re not running this from a remote shell. It runs in the portal, against the same data the incident was built from. That’s the point.

Save the good queries as detections

Any hunting query you’d happily wake up to at 3am can become a custom detection rule. From Advanced hunting, hit Create detection rule. Defender runs your query on a schedule and the matches feed straight back into the incident queue. The flow is documented in the Custom detections overview.

That’s the loop. Hunt once, detect forever.

Why this actually changes behaviour

“Where do I start?” becomes “What story is Defender telling me?”

When the queue is your home page, your team stops chasing alerts and starts closing incidents. The numbers you report to clients become incidents closed, median time to triage, active attack stories — not raw alert counts nobody can interpret.

The custom detection layer is where MSPs separate themselves. The product gives you the correlations Microsoft thought of. The rules you write are the correlations your clients need. Stack a few by vertical — finance, legal, construction — and you have a productised security service the next MSP down the road doesn’t.

The unified queue isn’t there to give you fewer alerts. It’s there to make alerts something you can actually work.

When Your LLM Goes Down: Are MSPs Designing a New Single Point of Failure?

Over the past year, I’ve watched something fascinating—and slightly uncomfortable—happen inside MSPs and their clients’ businesses. AI tools, particularly Microsoft 365 Copilot, have gone from “interesting experiment” to “critical part of how work gets done” at a pace I don’t think many people fully appreciate yet.

And that raises an uncomfortable question we haven’t really answered:

What happens when the LLM isn’t there?

Not slow. Not “a bit less helpful.”
Actually unavailable.

AI Has Quietly Moved Into the Critical Path

In some of the environments I’m seeing, Copilot isn’t just helping draft emails or summarise meetings. It’s shaping decisions.

Staff are using it to draft client responses, interpret data, build proposals, prepare board slides, and make sense of complex information faster than they ever did before. Managers are using it to think through options, not just document outcomes.

That’s important, because it means AI has crossed a line. It’s no longer a convenience layer. It’s becoming part of the business process itself.

From an MSP perspective, that should set off the same internal alarm bells as any other critical dependency. Because if your client’s process assumes Copilot is available, then Copilot downtime is no longer “an inconvenience”. It’s downtime.

The New Form of Business Continuity Risk

We’re very good, as an industry, at talking about disaster recovery in traditional terms. Backups. Redundancy. Failover. RPOs and RTOs.

But AI introduces a different kind of risk—cognitive dependency.

Here’s a simple scenario I’ve already seen play out in smaller ways:

A staff member is used to Copilot summarising long email threads before client calls. One day it’s unavailable. They’re still expected to run the meeting, but they haven’t read the full thread because the process evolved around “the AI will summarise it”.

No data was lost. No system was breached. But productivity drops, confidence drops, and errors creep in.

Now scale that to proposal preparation, reporting, or internal decision-making processes that assume AI assistance.

We haven’t lost data—but we’ve lost thinking capacity under time pressure.

“The AI Will Be Back Soon” Is Not a Strategy

One of the more dangerous assumptions I hear is:
“Microsoft will fix it quickly.”

Maybe. Probably. But that’s not business continuity planning. That’s hope.

As MSPs, we need to start asking different questions during AI discussions:

What manual process exists if AI is unavailable for a day?
Do staff know how to complete the task without AI, or have we trained that muscle out of them?
Which workflows are AI‑assisted—and which are AI‑dependent?

This isn’t about rejecting AI. I’m fully in favour of using Copilot when it genuinely improves outcomes. But professional-grade technology adoption has always meant understanding failure modes, not just success stories.

Designing AI‑Resilient Workflows

The smarter MSPs I’m working with are starting to treat AI like any other tier‑one system:

Document the “AI unavailable” version of key workflows
Set expectations with clients that AI enhances productivity but is not guaranteed
Train staff to validate, understand, and reconstruct work without AI assistance
Decide consciously where AI is optional versus where it must never be the only path

Ironically, the organisations doing this best often get more value from Copilot, not less. Why? Because they understand it as an accelerator—not a replacement for thinking.

The Question MSPs Should Be Asking Right Now

AI isn’t going away. Dependency will increase, not decrease. That makes this a leadership issue, not a technical one.

So here’s the question I think every MSP owner should be asking themselves:

If Copilot vanished tomorrow, which of my clients’ processes would break—and would they even realise why?

If the answer makes you uncomfortable, that’s a good thing.

That discomfort is the early warning system telling you it’s time to evolve disaster recovery thinking for the age of AI.

Windows Update for Business rings via Intune

Most of the Windows patching pain I see at SMB sites isn’t a Windows problem. It’s a governance problem.

Devices are enrolled. Updates are technically arriving. But there’s no ring. No pilot. No deadline. Patch Tuesday lands, somebody’s accounting machine reboots in the middle of a BAS run, the partner blames “Windows”, and the whole patching conversation gets put off for another quarter.

That’s not a tooling gap. That’s a configuration gap.

And here’s the kicker — Microsoft renamed the whole thing in April 2025. Windows Update for Business is now Windows Update Client Policies, and the deployment service is folded into Windows Autopatch, which is now included with Microsoft 365 Business Premium. If you’re still hand-rolling rings on a Business Premium tenant and ignoring Autopatch, you’re doing more work than you need to.

What update rings really are

An update ring is a Windows Update client policy. It tells the Windows Update client on the device when to look, how long to wait, when to install, and when to reboot. Nothing more.

It’s not a patch repository. It’s not a scanner. It’s a set of timing instructions the device honours when it talks to Microsoft’s update endpoints.

Once you accept that, the rest gets simpler. You’re not pushing patches. You’re staging trust.

Step-by-Step: build a three-ring rollout in Intune

Portal only. No PowerShell.

Open the unified updates dashboard

Sign in to intune.microsoft.com, then go to Devices > By platform > Windows > Manage updates > Windows updates and click the Update rings tab. This is the new unified surface — Microsoft’s docs on managing update rings live here.

Create the Pilot ring

Click Create profile. Name it WUR – Pilot. Quality update deferral: 0 days. Feature update deferral: 0 days. Automatic update behaviour: Auto install at maintenance time. Deadline for quality: 2. Deadline for feature: 2. Grace period: 2.

Assign to a device group of 3-5 representative machines. Not user groups. Devices.

Create the Broad ring

Same shape. Name it WUR – Broad. Quality deferral: 3. Feature deferral: 7. Same deadline/grace as Pilot. Assign to the bulk of your fleet.

Create the Critical ring

WUR – Critical. Quality deferral: 7. Feature deferral: 30. Assign to the boss’s machine, the EFTPOS PC, the design workstation — whatever you can’t afford to surprise.

Three rings. That’s it. Don’t build five.

The deferral / deadline / grace mental model

People get this wrong constantly. Here’s the model in one block.

Deferral  → how many days AFTER Microsoft releases the update
            before the device is even offered it.
Deadline  → how many days AFTER the device sees the update
            before it's force-installed.
Grace     → how many days AFTER install before reboot is forced.

Notice what’s missing? Patch Tuesday as a reference point. The deadline counts from when that device scanned and saw the update — not the calendar. Microsoft moved to this model deliberately to make restart timing predictable across a fleet.

Set them. Don’t leave any of the three blank. Blank means forever on a sleepy laptop.

Why this actually changes behaviour

The mistake isn’t choosing the wrong deferral. The mistake is leaving the pause button in users’ hands.

In the ring settings, set Option to pause Windows updates to Disable. Otherwise a user can park their patches for 35 days, and you’ll find out at the next quarterly review.

Set automatic update behaviour to Auto install at maintenance time with active hours configured. The device patches itself. The user keeps their day. The MSP stops being the villain.

“Why do my updates keep nagging me?”

They don’t, anymore. You set active hours. The reboot finds its time, not yours.

Copilot doesn’t get tired. Neither does Windows Update. Use that.

A word on Autopatch

If the tenant is Business Premium, you now get the full Windows Autopatch service — rings auto-built, rollback on signal, 95% currency SLO. On those tenants, don’t assign hand-built rings to Autopatch-managed devices. They’ll fight each other.

My recommendation? Business Premium tenants → Autopatch. Everything else → three rings, the shape above, locked down so users can’t pause.

Update rings aren’t there to slow patching down. They’re there to remove the conversation about patching completely.

If your clients are still asking when their machines will reboot, you haven’t finished the job.