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.

Named locations + Conditional Access location-based policies

Most MSPs I talk to have a Conditional Access policy that blocks “high-risk countries”. They built it once, switched it on, and never looked at it again.

Then they sleep well at night.

That’s the problem.

A country block on its own is theatre. The attacker is on a VPN egress inside a country you allow, or a residential proxy, or a mailbox client that already has a refresh token. Named locations are useful — but only if you understand what they actually do, and where they fall down.

What is a named location, really?

A named location is a label. That’s it.

You’re telling Entra ID, “this IP range is my office”, or “these countries are where my staff actually work”. The location doesn’t enforce anything on its own. It’s a building block you then reference inside a Conditional Access policy.

The policy does the work. You decide whether to block, require MFA, or skip a control. The location is just the where.

And here’s the bit that bites people. Location is evaluated after first-factor authentication. The password’s already gone. Conditional Access then decides what happens next. Treat named locations as a layer, not a perimeter.

Step-by-Step: Setting up a country block that actually earns its keep

Portal path only. Report-only first — non-negotiable.

Open Named locations

Sign in to the Microsoft Entra admin centre as a Conditional Access Administrator. Go to Protection > Conditional Access > Named locations.

Create a Countries location

Click + Countries location. Name it something obvious — “Allowed countries — AU only” beats “Country Block 1”. Pick the country (or countries) where your staff actually sign in. Tick Include unknown areas if you want the location to also catch IPs the geo-database can’t classify. I leave that off for allow-lists and on for block-lists. Save.

Create the policy

Go to Policies > New policy. Name it. Under Users, pick All users — then exclude your break-glass accounts. Always. Under Target resources, pick All resources.

Set the network condition

Under Network, set Configure to Yes. Include Any network or location, then under Exclude select Selected networks and locations and pick your “Allowed countries” entry. That gives you “block everything outside my country”.

Grant

Under Access controls > Grant, choose Block access.

Switch to Report-only and review

Set Enable policy to Report-only. Create. Then watch the sign-in logs for at least 48 hours. The report-only results tell you exactly which users would have been blocked. Anyone surprising in there? Investigate. Then flip the policy on.

Why this actually changes behaviour

Here’s the real win. Once you’ve got clean named locations, every other CA policy gets sharper.

The “skip MFA from a trusted location” pattern — careful with that. Marking your office public IP as trusted feels like a productivity gift to users. It’s also the exact thing an attacker on your guest Wi-Fi or a compromised contractor on your VPN will piggyback. My recommendation? Don’t mark anything as trusted unless you have a strong reason and you’ve documented it. Use sign-in frequency and authentication strength to soften MFA friction instead.

“But our staff hate MFA prompts in the office.” Then fix the prompts. Don’t punch a hole in the wall.

The other classic trap is the corporate VPN. If everyone egresses through one public IP in a country you’ve blocked, you’ve just locked your own staff out. Map your VPN exits before you write the policy. Read the network assignment conditions before you write the policy, not after.

Notice what’s missing from all of this? PowerShell. You don’t need it. The portal does the job, and the audit trail is clearer.

A country block doesn’t stop attackers. It thins the noise so the rest of your stack can do real work. If you’re not showing your clients this — and explaining why “trusted location” is a loaded word — you’re leaving security maturity on the table.

That’s the job. Use named locations for that, and not for the warm feeling a checkbox gave you.

DLP and Sensitivity Labels for SMBs: A Practical Copilot Readiness Playbook

Most SMB data protection projects fail for one reason: teams optimize the label taxonomy before fixing access control. That creates a “labeled mess” instead of a governed environment. In practical terms, a “Confidential” label cannot compensate for a SharePoint site still shared with broad legacy permissions.

A safer and faster implementation sequence is: Permissions cleanup -> Sensitivity labels -> DLP tuning -> Copilot enablement. This order aligns with real-world Copilot risk patterns, where oversharing is usually the primary exposure pathway.

The Category Error to Avoid

The common debate in SMB projects is “How many labels should we deploy?” (for example, 4 vs 8 vs 12). That is the wrong first question. The first technical question is: “Are current permissions precise enough for labels to have security meaning?”

If broad groups, stale sharing links, and inherited permissions still expose sensitive locations, adding more labels mostly increases administrative overhead and user confusion. Copilot does not create this condition, but it can reveal it quickly by making discoverable content easier to surface through natural language prompts.

Reference Architecture for SMB Tenants

Use a minimal, repeatable baseline that can be implemented and operated by small IT teams.

1. Permissions Layer (Foundational)

Identify and remove broad default access patterns (for example, “Everyone except external users” where inappropriate).
Review high-risk SharePoint and Teams locations first: HR, Finance, Leadership, M&A, Legal, payroll artifacts.
Remove stale members from privileged Microsoft 365 groups and Teams.
Expire or revoke old anonymous or org-wide links where business value no longer exists.
Document approved sharing patterns by site type (departmental, project, external collaboration).

2. Label Layer (Classification)

Start with a compact taxonomy, then expand only with evidence.

Public – content approved for unrestricted internal and external use.
Internal – default business content for internal sharing.
Confidential – restricted business-sensitive data.
Highly Confidential (optional) – strongest controls, often encryption-backed.

Keep label names plain and user-comprehensible. If users cannot predict where a label applies, adoption and accuracy collapse.

3. DLP Layer (Policy Enforcement)

Deploy DLP in audit mode first (recommended: 60 days).
Prioritize high-confidence detections first (payment card data, national identifiers, banking information).
Monitor policy hits weekly and triage false positives with business owners.
Move to staged enforcement with user notifications before hard blocking where possible.

4. Copilot Layer (Consumption)

Enable Copilot only after oversharing findings are remediated to an agreed threshold. Treat Copilot enablement as a controlled release with explicit go/no-go criteria, not a licensing event.

Why Copilot Changes the Risk Visibility Model

Traditional oversharing could remain hidden for years because users had to know exactly where to look. Copilot lowers search friction by translating intent into broad retrieval across accessible content. This can expose latent permission mistakes quickly.

Oversharing is best treated as an access-control debt problem, not a labeling deficiency.

In practical operations, Copilot acts like a continuous discovery mechanism for permissions debt. If the tenant is clean, Copilot is productive. If not, Copilot surfaces the debt immediately.

60-Day Implementation Runbook

Phase 0 (Week 0): Scope and Governance

Define data protection owner, security owner, and business escalation path.
Agree target controls and business exceptions process.
Set Copilot readiness criteria before technical work begins.

Phase 1 (Weeks 1-2): Permissions Remediation

Run oversharing assessment on SharePoint and Teams-connected sites.
Rank findings by impact: executive, financial, personal data, contractual data.
Remediate critical sites first and verify effective permissions after each change.
Capture exception approvals where broad sharing must remain.

Phase 2 (Weeks 2-3): Label Deployment

Publish 3-4 labels to a pilot user group.
Validate user understanding with short examples and FAQ guidance.
Adjust label descriptions and policy tooltips based on pilot confusion points.

Phase 3 (Weeks 3-8): DLP Audit Mode

Enable DLP in monitor-only mode.
Collect incidents and tune detection thresholds/rules weekly.
Present day-30 report to stakeholders with false-positive and true-positive analysis.
Issue day-45 enforcement impact notice to users and managers.

Phase 4 (Week 9+): Staged Enforcement and Copilot Rollout

Turn on enforcement for highest-confidence policies first.
Enable Copilot for low-risk pilot cohort.
Review user prompts/incidents for unintended access outcomes.
Expand rollout only when no critical oversharing regressions are detected.

Operational Metrics That Matter

Track leading indicators, not just policy counts.

Permissions hygiene: number of high-risk overshared sites before vs after remediation.
Classification adoption: percentage of newly created docs with valid user-applied labels.
DLP quality: true-positive to false-positive ratio per policy.
Readiness confidence: unresolved critical findings at Copilot go-live.
User impact: helpdesk tickets per 100 users post-enforcement.

Common Failure Modes and Corrective Actions

Failure Mode 1: Label Proliferation

Symptom: taxonomy grows to 8-40 labels with low usage consistency.
Correction: reduce to behaviorally distinct labels users can apply accurately.

Failure Mode 2: Permanent Audit Mode

Symptom: policies remain non-enforcing for months or years.
Correction: define enforcement date at project kickoff and publish milestone reports.

Failure Mode 3: Copilot Before Cleanup

Symptom: sensitive content appears in valid-but-unexpected prompt responses.
Correction: block rollout until critical permissions findings are remediated and re-tested.

Practical MSP Packaging

The most successful SMB engagements package this work as Copilot Readiness and Data Access Hardening, not as a one-time “label deployment” project.

Deliverable 1: Oversharing assessment and remediation log
Deliverable 2: Compact label taxonomy and end-user guidance
Deliverable 3: DLP audit report at day 30 and day 60
Deliverable 4: Copilot go-live risk sign-off
Deliverable 5: Quarterly policy and permissions review cadence

Key Data Points to Use with Clients

Purview Suite for Business Premium add-on was announced at $10/user/month (September 2025).
Combined Defender + Purview Suites for Business Premium add-on was listed at $15/user/month.
Working SMB implementations commonly succeed with 3-4 labels, not large taxonomies.
A 60-day DLP audit window is a common practical baseline before enforcement.
Published incidents show that Copilot oversharing exposure typically traces back to legacy permissions.

Conclusion

For SMB tenants, the winning strategy is not maximum policy complexity. It is disciplined sequencing and operational follow-through. Start with permissions. Add a minimal label model. Run DLP in time-boxed audit mode. Enforce in stages. Then enable Copilot.

If you remember one line, use this: Clean access first, classify second, enforce third, accelerate last.

Microsoft Defender for Business: The MSP Reality Check

The short version: Microsoft Defender for Business scored 100% detection coverage across all 16 attack steps in the 2024 MITRE ATT&CK Enterprise evaluation. It also ships with no native multi-tenant console, no included 24/7 SOC, and an admin portal MSP operators openly describe as “a damn mess.” Both facts are true. Most MSPs have only priced one of them.

If you are an MSP selling Microsoft 365 Business Premium to sub-300-seat clients, you have almost certainly had the conversation: “Does Business Premium include endpoint protection?” The answer is yes—and that is exactly where the problem starts.

Defender for Business (DfB) is not the question. The question is what an MSP is actually delivering when it ticks the Business Premium box, onboards the tenant, and moves on. This post works through the technical reality of DfB in MSP deployments: what the product genuinely does well, where the operational gaps sit, what the practitioner community has settled on as the minimum viable wrap, and what the liability exposure looks like when the wrap is missing.

1. The Detection Engine Is Real—Stop Arguing About It

Defender for Business runs the same agent technology as Defender for Endpoint Plan 2 (MDE P2), the enterprise-tier EDR included in Microsoft 365 E5. The product ships:

Next-generation antivirus with cloud-delivered protection and behaviour-based detection

Behavioural EDR—endpoint detection and response with timeline and forensic telemetry

Automated Investigation and Remediation (AIR)—auto-triage and containment of common threat patterns without waiting for an analyst

Attack Surface Reduction (ASR) rules—policy-driven controls that block the abuse of common Windows features (Office macros, LSASS access, script execution chains, etc.)

Web content filtering and network protection

Threat & Vulnerability Management (TVM)—a simplified posture view that highlights missing patches, misconfigurations, and software exposure across managed endpoints

The 2024 MITRE ATT&CK Enterprise evaluation, independently scored by MITRE Engenuity, recorded Microsoft Defender XDR at 100% detection coverage across all 16 attack steps and all 80 sub-steps. This is the same underlying agent technology DfB uses. Calling Defender for Business “just antivirus” in 2026 is not a security assessment—it is an indicator that the person has not looked at the product since 2021.

Confidence note (HIGH): The MITRE result is independently scored and publicly verifiable at attackevals.mitre-engenuity.org. G2’s 30-review aggregate for DfB sits at 4.5/5, with the dominant negative theme being “complex to configure”—not “missed threats.”

What DfB does NOT include versus MDE Plan 2 / E5

Clarity on the gaps matters because MSP decisions about upgrade paths depend on them:

Full Advanced Hunting with the complete KQL schema and 30-day cross-tenant query capability is absent. DfB has a stripped view only.

Custom detection rules at scale—the API-driven workflow for building organisation-specific KQL detections is an E5/MDE P2 feature.

Microsoft Threat Experts / Defender Experts for Hunting is an add-on entitlement, not included at any Business Premium tier.

Full TVM prioritisation workflows, including contextual risk scoring and remediation ticket integration, are more limited in DfB than in MDE P2.

For most sub-300-seat SMB clients, the missing features are not the bottleneck. The bottleneck is operational—and it starts at the management layer.

2. The Management Gap Is the Real MSP Problem

Across r/msp threads spanning August 2022 through January 2025—the most sustained practitioner conversation about DfB in MSP deployments—the dominant complaint is not detection quality. It is operability at scale.

“There is supposed to be auto remediation, but every tenant has a blank page in the settings… Logging into each tenant (delegation won’t work on these pages) is a PITA, and manually requesting remediation for the following day or later. Typical Microsoft, great idea, so lacking in cohesive execution.”

— GremlinNZ, MSP operator, r/msp canonical thread

“They need to make the Defender portal easier to use. It’s a damn mess right now.”

— ancillarycheese, MSP operator, r/msp

“We use Defender for Business WITH SentinelOne… as a stand-alone EDR solution—I wouldn’t recommend it. Without CIPP and other tools it becomes problematic to manage.”

— blindgaming, MSP operator, r/msp

The core structural problem is this: security.microsoft.com does not support delegated multi-tenant access in the same way that the Microsoft 365 admin portals do. An MSP with 40 tenants cannot manage Defender for Business alerts across all of them from a single pane of glass using native Microsoft tooling alone. Each tenant requires a separate login context. Delegation through GDAP helps with permissions but does not solve the unified-view problem.

This is not a minor UX complaint. It is a scalability ceiling. An MSP tech managing 20 tenants who needs to check for active incidents across all of them each morning is looking at 20 individual logins, 20 separate portal states, and 20 alert queues with no aggregated view. At that point, either the techs burn out or the alerts go unchecked—and in a security context, unchecked alerts are the same as no alerts.

The contrast with single-tenant environments

It is worth noting that the r/sysadmin community—practitioners managing one tenant rather than twenty—runs consistently more positive on DfB than r/msp:

“It’s pretty decent, and you’re only going to be able to do better if you move to a much higher-end EDR like CrowdStrike or SentinelOne. But Microsoft is no slouch here.”

— canadian_sysadmin, r/sysadmin

“Windows Defender for Endpoint/Business is a world leading solution. That being said it is best managed and monitored through your Microsoft 365 Business license with Intune and native management.”

— Avas_Accumulator, r/sysadmin

The split in sentiment is not about the product. It is about deployment context. In a single-tenant environment the multi-tenancy gap does not exist. In an MSP environment running 20–200 tenants, it is the dominant operational constraint.

3. Microsoft Does Not Include a 24/7 SOC with Business Premium

This is the single most consequential fact MSPs fail to communicate to clients, and the one most likely to produce a liability incident when it surfaces during a breach.

Microsoft’s managed SOC offering—Defender Experts for XDR—is sold separately. It has no public per-seat price. It is gated behind an interest form and is clearly positioned as an enterprise offering. There is no indication it is accessible to sub-300-seat SMB clients at a commercially viable price point.

The practical consequence for MSPs is blunt:

DIY 24/7 monitoring—viable only for MSPs with a staffed NOC/SOC running around the clock, which is rare at the SMB-MSP tier.

Defender Experts for XDR—enterprise-priced, opaque, and not practically accessible for Business Premium clients.

Third-party SOC partner—Huntress, Blackpoint, Field Effect, Arctic Wolf, or Pax8-distributed MDR offerings layered on top of DfB.

The liability gap: A CFO at a 40-seat SMB hears “Business Premium includes Microsoft Defender” and reasonably concludes they have bought managed security. They have not. They have bought a detection engine. Whether anyone reads the alerts—and how fast—is entirely determined by the MSP’s service design, and if that is not documented in the MSA, neither party knows what they have bought.

4. The Minimum Viable MSP Wrap Stack

The practitioner community on r/msp has, over three years of iteration, converged on a standard architecture for running Defender for Business at MSP scale. None of the components are optional if the MSP wants to deliver an operationally sound result:

Layer 1: Access Management

GDAP (Granular Delegated Admin Privileges)—required for MSP access to customer tenants using the principle of least privilege. Replaces the legacy DAP model. Without GDAP properly configured, the MSP is either operating with excess privilege or managing access manually per tenant—neither is acceptable from a security or audit perspective.

Layer 2: Multi-Tenant Management

Choose one or more of:

Microsoft 365 Lighthouse—Microsoft’s own multi-tenant management portal for MSPs serving SMB clients. Provides an aggregated view of device compliance, alerts, and user risk across tenants. Improving but still limited for deep Defender operations.

CIPP (Community Intune and Partner Portal)—open-source MSP management platform with strong M365 coverage. Widely used in the community for tenant management, user operations, and policy deployment.

Inforcer—commercial MSP management layer with strong Business Premium policy management. Specifically designed for MSPs running large numbers of Microsoft tenants.

Layer 3: Policy Hardening

Intune-enforced security policies are the mechanism by which ASR rules, device compliance baselines, and Defender configuration actually land on endpoints. DfB in default configuration is not a hardened deployment. An MSP that onboards a tenant, enables DfB, and does not push a policy baseline is leaving a significant proportion of the product’s protective capability unused.

Critical policies that must be configured intentionally:

ASR rules—in Audit mode by default; must be switched to Block mode per rule after validating impact

AIR configuration—automated remediation level (Full vs. Semi-require-approval) per device group

Tamper protection—on by default in DfB but worth verifying across all enrolled devices

Network protection and web content filtering category configuration

Device isolation policy for high-severity incidents

Layer 4: The 24/7 SOC Layer

The alert that fires at 7:14pm on a Friday needs to be read and acted on within minutes, not at 9am Monday. For most MSPs this means a third-party MDR partner. The most commonly recommended option in the practitioner community is Huntress Managed EDR.

“Ditch your current AV spend for Huntress and use Microsoft Defender. Huntress manages a lot of the MS Defender features… from a multi-tenant monitoring/management/alerting perspective, this is the best solution on the market today.”

— amw3000, MSP operator, r/msp canonical thread (consistently upvoted 2022–2025)

Huntress was named a Microsoft Verified SMB Solution in November 2024 and announced an expanded Microsoft Defender collaboration in July 2025. The fact that Huntress chose to build on Defender rather than displace it is the strongest possible product-level endorsement of the DfB engine—and simultaneously the clearest acknowledgement that the engine alone is not sufficient for MSP-scale operations.

Alternatives to Huntress for the SOC layer: Blackpoint Cyber, Field Effect, Arctic Wolf, and Pax8-distributed MDR offerings. The choice of partner matters less than the fact that a choice has been made and that it is priced into the client’s service agreement.

5. What Happens When the Wrap Is Missing

A 40-seat accounting firm signs onto Business Premium on the MSP’s recommendation. The MSP onboards them in a week—Intune basic policy, MFA, Conditional Access, Defender for Business switched on across all endpoints. The client’s CFO asks once whether they are now “covered” for ransomware. The MSP says yes, in writing. Eleven months pass without an alert worth investigating.

On a Friday in month twelve, a partner clicks a payroll-themed phishing link from a hotel Wi-Fi. Defender flags the executable, isolates the device, and writes the incident to the security portal at 7:14pm. Nobody opens the portal until Monday at 9am. By then the attacker has used the seventy-two-hour window to pivot through the partner’s saved credentials into the firm’s tax software vendor and exfiltrate two seasons of client returns.

The post-incident review is short. The detection worked. The agent did exactly what Microsoft’s MITRE result said it would. What did not work was the part that was never bought, never built, and never priced—the layer that reads the alert at 7:14pm on a Friday and acts on it. The MSP had sold a licence. The client had assumed they bought a service. Both were correct. Both were also wrong about what the other one meant.

6. The Cost Economics—Why DfB + Wrap Beats the Alternatives

The Business Premium upgrade conversation is often framed as “is Defender for Business worth $9.50 per user per month?” That is not the right question. The $9.50 Business Standard to Business Premium delta delivers:

Defender for Business (EDR)

Microsoft Intune (MDM/MAM)

Azure Information Protection / Microsoft Purview Information Protection

Conditional Access (Entra ID P1)

Defender for Office 365 Plan 1 (anti-phishing, Safe Links, Safe Attachments)

Valued individually, the $9.50 delta is almost always defensible for any SMB with more than a basic threat profile. The correct question is whether the MSP has priced the wrap on top of it—because that is what determines whether the $9.50 produces security outcomes or merely a compliance checkbox.

Product	Price	Notes
M365 Business Standard	$12.50 / user / month	No EDR included
M365 Business Premium	$22.00 / user / month	DfB + Intune + CA + AIP + Defender for Office 365 P1
Defender for Business (standalone)	$3.00 / user / month	EDR only, same 300-seat cap
MDE Plan 2 (standalone)	$5.20 / device / month	Full EDR + Advanced Hunting + Threat Experts eligibility
CrowdStrike Falcon Go	$59.99 / device / year (~$5.00/month)	Closest single-vendor SMB alternative
Huntress Managed EDR	Per-agent (contact Huntress)	Layered on top of DfB; includes 24/7 SOC and <8 min median response

For clients already paying $22.00/user for Business Premium, DfB is sunk cost. The marginal question is the SOC layer—and layering Huntress on top of the included DfB engine almost always produces better economics than replacing Defender with a competing EDR, because the competing EDR still does not include 24/7 human response at the Huntress price point.

7. When to Move Beyond Defender for Business

DfB has a hard ceiling of 300 seats per tenant. At 301 users, the organisation must move to Microsoft 365 E3 (which includes MDE Plan 1) or E5 (which includes MDE Plan 2). This is a contractual limit, not a technical one.

The soft thresholds where MSP guidance should flip to E5 / MDE P2 before reaching 300 seats:

Regulated workloads—HIPAA, PCI-DSS, CMMC Level 2 or higher. These require documented custom detections, extended retention, and SOC reporting that DfB’s simplified tooling cannot produce.

Elevated threat profile—clients with significant third-party integrations, supply-chain exposure, high-value IP, or a documented history of targeted attacks. The Advanced Hunting / KQL gap becomes material at this profile.

Contractual SOC requirement—clients whose cyber insurance, board mandate, or regulator requires a named 24/7 SOC with documented SLAs. Defender Experts for XDR or a contracted MDR partner with E5 tooling is the appropriate response.

Multi-geo or cross-tenant consolidation—organisations with subsidiaries or complex ownership structures where cross-tenant Advanced Hunting is operationally required.

8. The Framework That Settles the Debate

“I see far too many MSPs ‘turn on’ Defender for Business and then move on. That’s not implementation. That’s box-ticking. Defender for Business is a serious security platform—but only if it’s deployed properly, configured intentionally, and monitored consistently.”

— Robert Crane, CIAOPS, Microsoft MVP

This is the most useful single sentence for framing the MSP decision. The product does what it says. The gap is not in the technology—it is in the implementation discipline. Specifically:

Deployed properly—GDAP configured, all endpoints enrolled in Intune, DfB policy pushed to all device groups, not just the easy ones.

Configured intentionally—ASR rules reviewed and moved to Block mode per environment; AIR level set deliberately (Full automation for most SMB, semi-require-approval for environments where business operations cannot tolerate false-positive isolations); TVM findings reviewed on a scheduled cadence.

Monitored consistently—a named process, supported by a named tool or partner, that reads and acts on alerts within a defined SLA. Not “we check the portal when we think of it.”

The MSPs failing with DfB are not failing because the product does not detect threats. They are failing because they have sold a licence and delivered an engine, when what the client needs is the engine plus the configured policies plus the monitoring layer that makes the engine operationally useful.

9. Alert Volume and the Noise Question

Microsoft’s official position after MITRE ATT&CK Enterprise 2024 is high detection coverage with minimal false positives. SentinelOne’s competing write-up of the same evaluation claimed their product produced “88% less noise” than Microsoft. As a competitor source this requires appropriate scepticism, but the directional claim aligns with MSP practitioner experience: DfB in default configuration, across a large number of tenants, produces significant alert volume.

The relevant counter-evidence:

AIR is a genuine differentiator. Multiple MSP operators note that Automated Investigation and Remediation catches and closes the majority of routine alerts before a tech ever sees a ticket. The noise problem is substantially worse for MSPs who have AIR configured at Semi (manual approval) than for those running Full automation.

TVM is useful in passive mode. Even without active alert response, DfB’s vulnerability and posture data surfaces actionable hardening recommendations that are independent of alert volume.

The noise threshold varies by ASR rule configuration. An environment with ASR rules tuned against the specific application baseline will generate substantially fewer false positives than one running with audit-mode defaults or globally applied Block rules on mixed-use devices.

The practical implication: alert volume management is a configuration problem, not a product problem. MSPs who complain about noise and have not audited their ASR rule states, AIR configuration, and detection exclusions are working on the wrong variable.

10. MSP Checklist: Minimum Viable DfB Deployment

Use this as a deployment validation checklist. Each item represents a gap that, if left open, reduces the client’s actual security outcome regardless of the licence they are paying for.

Area	Required Action	Common Miss
Access	GDAP configured with least-privilege roles for all MSP technicians	Legacy DAP still in place, or GDAP roles not scoped to minimum required
Enrolment	All Windows endpoints enrolled via Intune / Entra hybrid join; DfB policy applied to all device groups	Unmanaged devices not onboarded; DfB policy applied only to a subset of groups
ASR Rules	Each ASR rule reviewed in Audit mode, validated against app baseline, then moved to Block for applicable rules	All rules left in Audit mode; Block applied globally without application validation causing false positives
AIR	Automation level set to Full for standard device groups; Semi only where business continuity requires manual approval	Left on default Semi requiring approval; MSP never approves pending actions; threats sit isolated but unresolved
Multi-tenant view	M365 Lighthouse, CIPP, or Inforcer configured to aggregate alerts and compliance state across all tenants	MSP techs logging into each tenant individually; alert review not on a defined schedule
SOC layer	Named 24/7 response partner (Huntress, Blackpoint, etc.) contracted and integrated with DfB telemetry	No after-hours response; client believes Business Premium = managed security
Documentation	Client MSA clearly specifies what is and is not included; incident response SLA documented	MSA silent on security scope; client assumes coverage that does not exist
TVM review	Scheduled cadence (monthly minimum) for reviewing TVM findings and converting to remediation tickets	TVM data collected but never acted on

Key Statistics

Metric	Value	Source
DfB standalone price	$3.00 / user / month	MSPoweruser
M365 Business Premium	$22.00 / user / month	Microsoft
M365 Business Standard	$12.50 / user / month	Microsoft
DfB seat cap	300 users / tenant	Microsoft Learn
MITRE ATT&CK Enterprise 2024—Microsoft detection coverage	100% across 16 attack steps / 80 substeps	Microsoft Security Blog, Dec 2024
SentinelOne “noise” claim vs Microsoft (MITRE 2024)	“88% less noise”—competitor source	SentinelOne
Huntress Managed EDR median response	<8 minutes	Huntress
CrowdStrike Falcon Go SMB pricing	$59.99 / device / year	CrowdStrike
G2 aggregate rating—DfB	4.5 / 5 (30 reviews)	G2 Reviews 2026
Huntress Microsoft partnership milestone	Microsoft Verified SMB Solution, November 2024	Huntress blog

Closing: The Question That Actually Matters

The debate about whether Defender for Business is “good enough EDR” has been settled since the 2024 MITRE evaluation. It is a legitimately strong detection engine. It is not a complete security program.

The question for every MSP selling Business Premium is not “is DfB real EDR?” It is: who in your organisation owns the alert at 2am on a Sunday?

If you can name that person or that service, and it is priced into the client’s agreement, and the policies are configured rather than defaulted, and TVM findings are reviewed on a schedule—then Defender for Business at sub-300 seats is extraordinarily hard to beat economically. The $9.50 Business Premium delta, plus a Huntress-tier SOC layer, competes with anything in the SMB market at a price point no competing vendor can match.

If you cannot name that person, and the client signed an MSA that does not address security scope, and the ASR rules are in Audit mode, and nobody has checked the portal since onboarding—then the client believes they have managed security and the MSP is one incident away from finding out the difference.

Turning on Defender for Business is not implementation. It is the starting line.

Sources

Microsoft Learn. Compare Microsoft Defender for Business plans. learn.microsoft.com/en-us/defender-business/compare-mdb-m365-plans

Microsoft Learn. What’s included in Microsoft Defender for Business. learn.microsoft.com/en-us/defender-business/mdb-overview

Microsoft. Microsoft 365 Business Premium pricing. microsoft.com

Microsoft Security Blog. Microsoft Defender XDR demonstrates 100% detection coverage in 2024 MITRE ATT&CK Evaluation: Enterprise. 11 Dec 2024. microsoft.com/en-us/security/blog

MITRE Engenuity. ATT&CK Evaluations Enterprise 2024. attackevals.mitre-engenuity.org

Microsoft. Defender Experts for XDR. microsoft.com

SentinelOne. 2024 MITRE ATT&CK Evaluation results. sentinelone.com

Huntress. Managed EDR product page. huntress.com

Huntress. Huntress expands Microsoft Defender collaboration. Jul 2025. huntress.com

Huntress. Huntress named Microsoft Verified SMB Solution. Nov 2024. huntress.com

CrowdStrike. Falcon Go for small business. crowdstrike.com

r/msp. Do any of you use Microsoft Defender for Business. Aug 2022 (active comments through 2024). reddit.com/r/msp

r/msp. Defender for Business: This is the way for clients <300 users. Nov 2021. reddit.com/r/msp

r/sysadmin. Microsoft Defender for Business. Mar 2022. reddit.com/r/sysadmin

G2. Microsoft Defender for Business reviews 2026. g2.com

NinjaOne. How to Set Up Microsoft Defender for Business in MSP Environments. 31 Oct 2025. ninjaone.com

MSPoweruser. Microsoft Defender for Business standalone $3 pricing announcement. mspoweruser.com

Robert Crane / CIAOPS. Blog and posts on Defender for Business deployment. blog.ciaops.com

Pricing and product details subject to change. Verify current figures at publish time.

Endpoint Privilege Management in Intune: a deployment that actually sticks

Endpoint Privilege Management (EPM) is the cleanest answer Microsoft has shipped for the local-admin problem. Done well, it lets your tenants run as standard users while still installing approved apps and updating drivers — auditable, just-in-time, no helpdesk ticket. Done badly, you ship a half-configured agent that produces noise, breaks line-of-business apps, and convinces the customer that “least privilege” is somebody else’s problem. Here is how to make EPM stick at an MSP.

The licensing trap nobody warns you about

EPM is not included in Microsoft 365 Business Premium. It needs Microsoft Intune Plan 1 plus either the Intune Suite add-on or the standalone EPM add-on. If your customer is on BP only, you have a quoting conversation before you have a deployment conversation. Confirm assignments under Tenant administration → Intune add-ons before you create a single policy.

While you are there, validate the other prerequisites people skip: devices must be Microsoft Entra joined or hybrid joined, Intune-enrolled (or ConfigMgr co-managed), 64-bit only, and on supported builds — Windows 11 24H2/23H2/22H2/21H2 or Windows 10 22H2/21H2 with the listed cumulative updates. EPM also needs clear line of sight to its endpoints without SSL inspection — this single item kills more pilots than anything else.

See EPM deployment planning for the full prerequisite matrix.

Where to configure

Everything lives in the Intune admin center at Endpoint security → Endpoint Privilege Management. There are two policy types you need to understand:

Elevation settings policy — provisions the EPM agent on the device, sets the default elevation response, and turns on reporting. One per device-targeted persona.
Elevation rules policy — defines which binaries can elevate, how (Automatic, User confirmed, Support approved, or Elevate as current user), and using which signal (file hash, certificate, or metadata). Up to 100 rules per policy.

Do not configure rules first. The agent does not exist on the endpoint until the settings policy lands. See the EPM overview.

The rollout pattern that actually works

Three rings, audit-first — same as every other Intune deployment that survives contact with users:

Audit ring (week 1–2). Deploy only an elevation settings policy to a pilot device group. Set Default elevation response = Require support approval, Send elevation data = Yes, Reporting scope = Diagnostic data and all endpoint elevations. No rules yet. Let it bake. EPM data is processed once every 24 hours, so resist the urge to declare it broken on day one.
Pilot ring (week 3–4). Use the Overview dashboard and the Frequently unmanaged elevations and Frequently approved by support tiles to identify the real top 5–10 elevation candidates. Build rules for those — prefer publisher certificate + file path over file hash, because hashes change with every app update. Roll into a 20–30 user pilot.
Production ring (week 5+). Widen progressively. Once managed-elevation coverage is high, deploy an account protection policy to remove standing local admin from the user group on those devices. That is the actual goal — the rules are just the bridge.

Build rules from Creating elevation rules. Watch coverage from EPM reports.

Top pitfalls

Certificate-rule sprawl. A certificate-only rule allows any binary signed by that publisher to elevate. Some vendors sign their entire catalogue — including tools you did not intend to elevate — with one cert. Always pair certificate with file name or path.
SSL inspection on the proxy. EPM telemetry travels over a pinned channel. Decrypt it and the device reports as “not applicable” with no useful error. Add an exclusion before you blame the agent.
Forgetting to remove local admin. Shipping rules without ever taking standing admin off the user group means EPM is theatre, not control. The whole point is the standard user.

Get those three right and EPM is a near-magical capability for an MSP. Get them wrong and it is just another agent on the box.