Month: May 2026

Attack Surface Reduction Rules in Microsoft 365 Business Premium: A Practical Deep Dive

image

If you manage Business Premium tenants for SMB clients, Attack Surface Reduction (ASR) rules are arguably the highest-leverage defensive control you’re not fully exploiting. They ship with Defender for Business (included in Business Premium), they cost nothing extra to enable, and they block the precise behaviours that commodity ransomware and living-off-the-land attacks depend on — Office spawning child processes, Win32 API calls from macros, credential theft from LSASS, and PSExec-style lateral movement. This post assumes you already know what ASR is. The goal here is to help L2/L3 engineers deploy it without breaking line-of-business apps.

Prerequisites the documentation underplays

ASR has hard dependencies that silently downgrade rules to “not configured” if missed. Microsoft Defender Antivirus must be the active AV (not passive, not disabled by a third-party product), real-time protection must be on, and cloud-delivered protection must be on — several rules won’t evaluate without cloud lookups. Verify these under Microsoft Defender portal → Endpoints → Configuration management → Device configuration, and confirm the device shows as “Active” in the device inventory. Tamper Protection must also be enabled tenant-wide; without it, local admins or malware can disable ASR in seconds.

Where to configure in Business Premium

Business Premium gives you two supported paths. The simplified experience lives at security.microsoft.com → Device configuration → Next-generation protection / Firewall, but ASR rules specifically are configured through Intune. In the Microsoft Intune admin center, go to Endpoint security → Attack surface reduction and create an “Attack surface reduction rules” profile targeting Windows 10/11. Avoid mixing this with legacy Endpoint Protection templates or Group Policy — conflicting sources result in the classic “last writer wins” behaviour, and you will spend hours chasing phantom rules. If a device is co-managed or has stale GPOs, check Event Viewer → Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational (event IDs 1121, 1122, 5007) to confirm which source applied.

The rollout pattern that works

Do not flip rules straight to Block. The proven pattern is: enable every rule in Audit mode, leave it for two to four weeks, then review the ASR report at security.microsoft.com → Reports → Attack surface reduction rules. Filter by rule and by device, identify the noisy ones, and build per-rule exclusions before switching to Block. Where available, use Warn mode as a staged step — the user gets a toast and can unblock once, which is invaluable for finance teams running macro-heavy spreadsheets. Warn mode is Windows 10 1809+ only; older builds silently treat it as Block.

Start with the “standard protection” set Microsoft recommends: Block credential stealing from LSASS, Block abuse of exploited vulnerable signed drivers, and Block persistence through WMI event subscription. These have the lowest false-positive rate and the highest return. The two rules that most commonly break things are “Block Office applications from creating child processes” (breaks legitimate mail-merge and older add-ins) and “Block executable content from email client and webmail” (breaks zipped installers).

Pitfalls to pre-empt

Exclusions are path-based and case-sensitive on the file name portion — wildcards work on folders, not extensions. Per-rule exclusions (added in later releases) are preferred over global Defender exclusions; use them so you don’t inadvertently hole-punch the whole AV. If a rule appears to do nothing, check whether the device is in EDR block mode and whether Defender is the active AV — ASR is silently disabled under third-party AV. Finally, ASR events do not always surface as alerts; plumb them into your SIEM via the Defender API or Advanced Hunting (DeviceEvents where ActionType startswith "Asr").

References

CIA Brief 20260502

image

Microsoft 365 Copilot & AI Agents

Microsoft 365 Apps & Productivity

Security & Defender

Identity (Microsoft Entra)

Microsoft Sentinel

Exchange Online

Corporate / Earnings

After hours

Starship – Test like you Fly – https://www.youtube.com/watch?v=ANe_HW4X8oc

Editorial

If you found this valuable, the I’d appreciate a ‘like’ or perhaps a donation at https://ko-fi.com/ciaops. This helps me know that people enjoy what I have created and provides resources to allow me to create more content. If you have any feedback or suggestions around this, I’m all ears. You can also find me via email director@ciaops.com and on X (Twitter) at https://www.twitter.com/directorcia.

If you want to be part of a dedicated Microsoft Cloud community with information and interactions daily, then consider becoming a CIAOPS Patron – www.ciaopspatron.com.

Watch out for the next CIA Brief next week

Why So Many MSPs Never Scale (And It’s Not the Market)

image

TONS of businesses never scale, and it’s rarely because the market is too competitive, margins are too thin, or clients are too demanding.

Most of the time, it’s because the owner can’t get a grip on their own issues.

In the MSP world, this shows up in a very specific way: the owner sees themselves AS the business.

Not running the business.
Not owning the business.
But being the business.

And that’s where scaling quietly dies.

When You Are the Business, Everything Is Personal

If your identity is welded to your MSP, every problem hits harder than it should.

A client complaint isn’t feedback — it’s an attack.
A staff mistake isn’t a process gap — it’s proof you’re failing.
A slow month isn’t normal variance — it’s existential panic.

So what happens?

You micromanage.
You hoard decisions.
You jump back into tech work “just to be safe”.
You delay hiring because no one can do it “as well as you”.

From the outside, it looks like dedication.
From the inside, it’s fear dressed up as responsibility.

And fear does not scale.

Separation Is the First Real Growth Lever

The moment things start to change is when you separate who you are from what your business does.

This isn’t about being cold or detached.
It’s about creating space.

When your MSP is something you own — not something you are — a few important things happen:

• You ride highs and lows better
• You think more calmly
• You make better decisions

Why? Because problems stop being personal.

A bad quarter becomes a data point.
A client loss becomes a signal.
A broken process becomes… a process to fix.

Not a judgement on your worth.

That emotional distance is not weakness. It’s leverage.

Calm Thinking Beats Heroic Effort Every Time

Most MSP owners think scaling is about working harder, being smarter, or “just pushing through”.

In reality, scaling is mostly about not panicking.

Panicked businesses make short‑term decisions:

  • Discounting to win the wrong clients

  • Delaying price rises they know are overdue

  • Overloading good staff because hiring feels risky

  • Chasing every opportunity instead of choosing the right ones

Calm businesses do the opposite.

They design roles instead of reacting to gaps.
They document because they expect people to follow systems.
They invest because they’re planning for the future, not bracing for impact.

Calm comes from separation. Separation comes from identity clarity.

Scarcity Is an Identity Problem

Here’s the uncomfortable truth: most “scaling problems” are actually scarcity problems.

And scarcity almost always lives in the owner’s head.

If you believe:

  • “Clients are hard to replace”

  • “Good staff are impossible to find”

  • “If I stop doing this myself, it will fall apart”

Then every decision is defensive.

But when you stop seeing your MSP as a reflection of you, something shifts.

You start approaching growth from abundance instead of panicked scarcity.

You realise:

  • Clients come and go — systems remain

  • Staff are attracted to clarity, not chaos

  • Your job is to build the machine, not be the machine

That’s when scaling stops being stressful and starts being strategic.

The Business Is the Product — Not You

If your MSP can’t function without your constant presence, you don’t have a business. You have a very demanding job.

Real scale begins when the business becomes something that can be observed, improved, and grown — independently of your mood, energy, or ego.

Detach your identity.
Build with intention.
Lead with calm.

That’s how MSPs actually scale.

Not louder.
Not faster.
But clearer.

Building Conditional Access That Actually Works: Requiring Intune‑Compliant Devices

image

Requiring Intune‑compliant devices via Conditional Access is one of the most impactful controls available to Microsoft 365 Business Premium tenants. It’s also one of the easiest ways to accidentally break access if you don’t understand how the moving parts fit together.

This article walks through the end‑to‑end mechanics, not just the clicks, so L2/L3 engineers understand why policies behave the way they do.

Architecture: What Happens During Sign‑In

When a user signs into a cloud app (Exchange Online, SharePoint, Teams):

  1. Microsoft Entra ID evaluates applicable Conditional Access policies

  2. If a policy requires a compliant device, Entra queries Intune
  3. Intune returns a binary verdict: Compliant or Not compliant
  4. Access is granted or blocked accordingly

Microsoft explicitly states that Conditional Access relies on Intune compliance state and will not function as intended without an Intune compliance policy in place. [learn.microsoft.com]

This is not a soft dependency — no compliance policy means every device fails the check.

Step 1: Define “Compliant” in Intune (Before Touching Conditional Access)

In the Intune admin centre (intune.microsoft.com):

Devices → Compliance policies → Create

At minimum for Windows endpoints in Business Premium, Microsoft supports compliance checks such as:

  • BitLocker enabled

  • Secure Boot enabled

  • Minimum OS version

  • Antivirus and firewall present

These controls form the inputs to Conditional Access — they do nothing by themselves. [learn.microsoft.com]

Operational tip:
Assign compliance policies to user groups, not devices. Conditional Access evaluates user sign‑ins, not device objects.

Step 2: Create the Conditional Access Policy

In the Microsoft Entra admin centre (entra.microsoft.com):

Protection → Conditional Access → Policies → New policy

Core configuration (baseline):
  • Users
    • Include: Target user group (do not start with All users)

    • Exclude:

      • Emergency access (break‑glass) accounts

      • Service accounts (where applicable)

Microsoft explicitly recommends excluding emergency access accounts to avoid tenant lockout. [learn.microsoft.com]

  • Target resources

    • Start with: Exchange Online or Office 365

    • Expand later to “All cloud apps”

  • Grant

    • ✅ Require device to be marked as compliant

  • Enable

    • ✅ Report‑only (initially)

This exact flow is documented by Microsoft as the supported deployment approach. [learn.microsoft.com]

Step 3: Report‑Only Mode Is Not Optional

Report‑only mode evaluates the policy without enforcing it. This allows you to:

  • Confirm which users would be blocked

  • Identify unmanaged or unenrolled devices

  • Detect users authenticating from unsupported platforms

Microsoft strongly recommends Report‑only mode before enforcement for Conditional Access policies of this type. [learn.microsoft.com]

Validation path:

  • Entra ID → Sign‑in logs

  • Filter: Conditional Access → Report‑only

  • Review failure reasons

Step 4: Common Failure Scenarios (Seen in the Wild)

“User prompted repeatedly for MFA then blocked”
  • Device is Entra ID joined but not enrolled in Intune
  • No compliance policy applies to the user
“macOS or BYOD phones blocked unexpectedly”
  • Platform not covered by a compliance policy

  • Device enrolment incomplete
“Policy works for admins but not staff”
  • Admins often use already‑managed devices

  • Staff devices lag behind in enrolment

Microsoft documents that Conditional Access can only evaluate compliance for MDM‑enrolled devices. [learn.microsoft.com]

Step 5: When Not to Use Compliant‑Only Access

Microsoft explicitly provides alternative templates where compliance is one of several controls, not the only one, such as:

  • Compliant device OR Microsoft Entra hybrid joined OR MFA

This is recommended where full device management is not realistic. [learn.microsoft.com]

Production Roll‑Out Recommendation

For Business Premium tenants, Microsoft’s own Zero Trust guidance aligns to:

  1. Require MFA first

  2. Enrol devices into Intune

  3. Require compliant devices for core workloads

  4. Expand to all cloud apps once stable [learn.microsoft.com]

Official Microsoft References

Margin Compression: When Cost‑to‑Serve Rises Faster Than Revenue

image

If margins collapse, nothing else matters.

Not growth.
Not MRR.
Not headcount.
Not how many logos are on your website.

This is why margin compression is the number one silent killer in the MSP industry right now.

On paper, many MSPs look healthy. Revenue is climbing. Client counts are up. Service catalogues are expanding. But underneath that surface-level success, net margins are flat at best—and often shrinking. The business is working harder for the same outcome, or worse, less profit. Multiple industry analyses point to the same culprits: labour, vendor/software spend, and a widening mismatch between scope and price, with labour consistently the largest cost line for most MSPs.

This is brutal because it hides in plain sight.

The profitability illusion

Margin compression doesn’t usually show up as a dramatic collapse. It shows up as a slow bleed.

You win a few more clients.
You add a couple more technicians.
You roll out another security tool “for free” to stay competitive.
You absorb a few extra requests because “it’s just easier”.

Your MRR graph keeps pointing up, so everything must be fine… right?

Except EBITDA isn’t moving. Cash flow feels tighter. Owners stop paying themselves properly. Every problem feels urgent because there’s no margin buffer left. That’s the illusion: growth masking decay.

Industry commentary has been calling this out more loudly over the last year. MSPs are growing, but profits aren’t keeping pace. The core issue isn’t sales—it’s that cost‑to‑serve is rising faster than contract value, driven by operational complexity and unpriced work.

Why cost‑to‑serve keeps exploding

Let’s be blunt about what’s changed.

Labour costs are rising
Good technicians are expensive. Great ones are rarer and cost more. Wage inflation, retention pressure, burnout, and higher expectations all push labour costs up. For most MSPs, labour is the single largest expense, and even small efficiency losses compound quickly.

Security workload per endpoint has exploded
Endpoints are no longer “patch and forget”. Each one now carries identity, conditional access, EDR, alert triage, reporting, compliance evidence, and incident response expectations. The workload per user has multiplied, but many contracts haven’t.

Fixed‑price contracts were written for a simpler era
“All‑you‑can‑eat” sounded great when environments were smaller, flatter, and less regulated. Today, that same pricing model absorbs cloud sprawl, security alerts, identity issues, SaaS churn, and board‑level reporting—without a matching price increase.

Scope creep is now systemic
This isn’t the odd favour. This is unbounded complexity baked into the operating model. New vendors roll out defaults. Microsoft changes behaviour. Security baselines shift. Clients expect it all to be “included”. The contract never gets revisited.

The result? MSPs are expected to deliver more, faster, and safer—without adding headcount and without raising prices. That maths simply doesn’t work.

Labour: the biggest margin leak

When people talk about margin problems, they often blame tools first. And yes, vendor and software costs matter. Tool sprawl hurts. Licensing creep is real.

But labour is where margins truly die.

Every extra ticket minute. Every manual process that should have been automated. Every alert that requires human triage. Every undocumented workaround that only “that one senior tech” knows.

Those minutes add up to hours. Those hours add up to FTEs. And those FTEs are increasingly hard to fund under legacy pricing models. This is why so many MSP margin leaks trace back to time—unbilled, under‑priced, or poorly controlled. [level.io]

Why this problem is so dangerous

Margin compression doesn’t announce itself.

You don’t get an alert. You don’t get an email. Your PSA won’t warn you.

What you get instead is exhaustion. Constant pressure. The feeling that you’re always behind, even though you’re “successful”.

And here’s the real danger: once margins are gone, you lose options.

You can’t invest. You can’t absorb shocks. You can’t say no to bad clients. You can’t slow down long enough to fix the model.

That’s why this is problem #1. Not because it’s flashy—but because it quietly removes your ability to respond to everything else.

The uncomfortable truth

You cannot out‑sell margin compression. You cannot hire your way out of it. And you definitely can’t ignore it.

If your cost‑to‑serve is rising faster than your revenue, growth will make things worse, not better.

The MSPs that survive the next phase of this industry won’t be the ones with the most clients. They’ll be the ones who understand their margins, price complexity properly, and stop pretending that “unlimited” still exists.

Because in 2026, unlimited delivery with fixed pricing isn’t a value proposition.

It’s a slow, quiet business killer.