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.

What’s actually happening inside an Intune App Protection Policy

image

Most MSPs I work with have shipped App Protection Policies (APP) to a client by now. BYOD iPhone, Outlook Mobile, a PIN, a block on copy-paste to personal apps — done, move on. But when the client’s compliance consultant asks how the data is actually protected, or why a specific action blocks on an unenrolled Android, the hand-waving starts. Here’s what’s actually going on under the covers.

The Intune App SDK, not the OS, is doing the work

An App Protection Policy doesn’t manage the device. That’s the whole point of MAM-without-enrolment. Enforcement lives inside the app itself, courtesy of the Intune App SDK that Microsoft has compiled into Outlook, Teams, Word, Excel, OneDrive, and a growing list of line-of-business apps wrapped with the App Wrapping Tool. When the user signs in with their work identity, the SDK phones home to the Intune service, pulls down the policy that applies to that user plus that app, and starts enforcing it in-process.

That’s why policies are scoped to user and app, not device. The OS on an unenrolled phone has no idea this is happening. The app is quietly running a second policy engine beside the operating system — and a separate wipe scope, which is what lets you revoke org data from a personal device without nuking the phone.

The broker is the hinge

On iOS, Microsoft Authenticator acts as the broker. On Android, it’s Company Portal — even when no device enrolment exists. The broker holds the work identity token and passes it to every SDK-enabled app, which is why one PIN prompt in Outlook covers Teams and Word for the next session. If the broker isn’t installed, APP quietly degrades: the SDK still enforces policy on its own app, but cross-app single sign-on and some advanced integrity checks fall away. A detail worth surfacing in onboarding.

Conditional launch is a local state machine

The under-appreciated piece is Conditional Launch. Every time a managed app resumes, the SDK runs a checklist: is the OS version above the floor, is the device jailbroken or rooted, is the Play Integrity or App Attest result clean, is the user still in good standing with Entra ID, how long since the last check-in? If any requirement fails, the SDK can warn, block, or selectively wipe org data — on its own, from a cached policy, without Intune needing to reach the device at that moment.

The data boundary works the same way. “Save copies of org data” restricted to OneDrive for Business, “Open-in” restricted to other managed apps, encrypted cache at rest — these are decisions made inside the app process by asking the SDK whether the target app is on the allow list and signed in with the same work identity.

Where Conditional Access joins in

The final layer is the Entra ID grant control Require app protection policy. This is what makes APP enforceable rather than optional. The token issued to the app is stamped with a claim confirming the app is compliant with its APP at sign-in. Conditional Access can refuse the token entirely if the app isn’t protected, and with Continuous Access Evaluation the refusal can happen mid-session. That’s the seam between the identity plane and the data plane.

What I’d tell a junior engineer

APP is a policy engine bolted into each app, gated by the broker, validated by Conditional Access. Understand those three layers and the “why did this break” tickets get a lot shorter.

Worth bookmarking:

If It’s a Supply Issue… What’s Actually the Constraint?

image

I hear this a lot from MSPs.

“We’ve got demand. Plenty of demand. The problem is supply.”

And on the surface, that sounds right. Phones ringing. Inbound leads. Existing customers wanting more. Projects stacking up. Everyone’s busy.

But here’s the question I think too few MSP owners are really asking:

If it’s a supply issue, what exactly is constrained?

Because most of the time, it’s not what you think.

It’s Rarely the Market

Let’s get this out of the way first. In most regions right now, MSPs don’t have a demand problem. If anything, the opposite is true.

Security requirements are increasing. Compliance expectations are rising. Clients are confused, under-skilled, and increasingly nervous. Microsoft keeps adding more knobs, dials, portals, and acronyms.

There’s work everywhere.

So if growth has stalled, it’s probably not because there aren’t enough customers willing to pay for help.

Which means the constraint is internal.

Frontstage vs Backstage

A useful way to think about this is frontstage versus backstage.

Frontstage is what clients see:

  • Sales conversations

  • Projects

  • Tickets getting resolved

  • New customers onboarding

Backstage is what actually makes all of that possible:

  • Your time

  • Your team’s capability

  • Your systems and processes

  • Your standardisation (or lack of it)

Most MSPs focus their energy on the frontstage. More leads. Better proposals. New offerings. Better marketing.

But when supply becomes the issue, the real bottleneck is almost always backstage.

The Three Real Constraints

In my experience, it usually comes down to one (or more) of these.

1. Your time

If you’re still the escalation point, the sales engineer, the architect, the quality control, and the business owner, then your business can’t scale past you.

That’s not a staffing issue. That’s a design issue.

If every complex decision, every quote, every “just check this” flows through you, then you are the constraint. Not demand.

2. Your team

Many MSPs hire reactively. Someone leaves. Work piles up. You hire to relieve pressure.

But scaling requires capability, not just headcount.

If only one or two people truly understand identity, security, or automation, then growth stalls the moment they’re fully utilised. Everyone else becomes dependent on them, and velocity drops.

A team that can’t operate independently can’t scale sustainably.

3. Your systems

This is the unsexy one. And the most ignored.

If every customer is “a little bit different”, every deployment is bespoke, and every technician does things “their way”, then you’re not running a scalable service business. You’re running a collection of individual heroics.

The more customers you add, the slower everything gets.

That’s not because you’re bad at MSPing. It’s because standardisation, documentation, and automation haven’t been treated as first‑class work.

The Uncomfortable Truth

When MSP owners say “we can’t scale because of supply”, what they often mean is:

“The way we currently operate doesn’t scale.”

And that’s actually good news.

Because markets are hard to fix. You can’t control demand.

But you can redesign how work flows through your business.

You can:

  • Remove yourself as the bottleneck

  • Build repeatable delivery models

  • Train for depth, not just coverage

  • Invest in systems that make average staff effective, not heroic staff exhausted

None of this is glamorous. None of it is quick.

But it’s the difference between being busy and being scalable.

So next time you think you’ve hit a supply ceiling, don’t just ask how do we get more capacity?

Ask the harder question:

What backstage constraint is actually stopping us from growing?

Because that’s where the real work is.