Author: directorcia

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.

Windows LAPS via Intune: the quiet Business Premium win most MSPs still haven’t shipped

image

Walk into almost any SMB estate and you’ll find the same thing — a local administrator password that was set during imaging three years ago, shared across every device, and written down somewhere nobody wants to admit. It’s the sort of gap that never shows up on a client’s risk register until it does. What surprises me is how many MSPs haven’t yet rolled out Windows LAPS, even though it’s sitting right there inside Microsoft 365 Business Premium — Intune is part of the licence, the feature is part of Windows, and there’s no extra agent to push.

What it actually is

Windows LAPS is the successor to the old “Microsoft LAPS” tool — the one that needed an AD schema extension and a client-side extension pushed by GPO. The replacement is baked into Windows 10, Windows 11, and Server 2019+. Nothing to install. You just tell it what to do.

Each managed device backs its local admin password up to a directory — either on-prem AD or Entra ID. Pick one per device, and for cloud-joined SMB fleets it’s almost always Entra. The password is stored encrypted against an Entra key, and only users holding the right role can read it. The device itself never keeps the current password in the clear once it has rotated.

Deploying through Intune

In the Intune admin centre it lives under Endpoint security → Account protection → create a policy of type Local admin password solution (Windows LAPS). Under the hood you’re configuring the LAPS CSP, but the UI hides that detail.

The settings worth thinking through:

  • Backup directory — Azure AD or Active Directory. Disabled turns it off.

  • Administrator account name — leave blank and it manages the built-in Administrator, which is disabled by default on most modern builds. Name it explicitly if you want LAPS to manage a dedicated local admin.

  • Automatic account management — the newer setting that lets LAPS create and maintain the account for you, so you don’t need a separate provisioning step.

  • Password complexity, length, age — 14+ characters, full complexity, 30-day rotation is a sensible baseline.

Assign the policy to an Entra device group, not a user group — it’s a device-scoped CSP and won’t apply against user targeting.

Rotation, post-authentication reset, and retrieval

The bit that’s genuinely new — and the bit most pros miss — is the post-authentication reset. When the managed account signs in interactively, Windows starts a grace timer. When that elapses, it can rotate the password, sign the account off, or reboot the device. That behaviour alone shuts the door on a technician staying signed in for days with a password someone else might already have read. Scheduled rotation still runs on the age you set, and you can force an on-demand rotation from the device blade in Intune.

Retrieval is the other place it pays for itself. In Intune, open the device and click Local admin password. Or do it from Entra directly — Devices → the device → Local administrator password recovery. The role needed is Cloud Device Administrator, or an Intune role with the right retrieval action. Every read is audited, and by default reading the password triggers a fresh rotation, so a looked-up credential is a one-shot — useful if you’re handing it to a junior tech for a single call.

Worth the morning it takes

Rolling this out across a client tenant is an afternoon’s work per fleet, and it closes a gap most MSPs have been quietly carrying for years. If you’re already selling Business Premium, you’re already paying for it. The only real question left is why it isn’t deployed yet.

Are We Copilot‑Ready?

image

A practical readiness checklist for SMBs using Microsoft 365

Purpose:
Microsoft 365 Copilot works only within the permissions, data, and policies you already have. This checklist helps confirm whether your tenant is ready—or whether Copilot will simply surface problems faster.

You don’t need to score 100%. You do need to know where the risks are.

1️ Identity & Access (Foundation)

✅ We have Entra ID (Azure AD) accounts for all staff
✅ Multi‑factor authentication (MFA) is enforced for all users
✅ Admin roles are limited and reviewed periodically
✅ Former employees and guest users are removed promptly
✅ Conditional Access is in place for risky sign‑ins or devices

If “No” appears here:
Copilot will still work—but with higher security risk.

2️ Licensing Reality Check

✅ We understand the difference between:

  • Copilot Chat (Basic)

  • Microsoft 365 Copilot (Paid / Premium)

✅ We know which roles actually need Copilot licences
✅ We are not assuming “everyone gets it for free”
✅ Business Premium (or E3/E5) is in place for users handling sensitive data

If unclear:
Expect confusion, helpdesk tickets, and poor adoption.

3️ SharePoint & OneDrive Permissions (The Big One)

✅ SharePoint sites have clear owners
✅ Access is based on need, not convenience
✅ “Everyone” or “Anyone with the link” sharing is controlled
✅ Old project sites are archived or cleaned up
✅ We’re comfortable with Copilot summarising what users can access

Reality check:
Copilot doesn’t break permissions—it makes them obvious.

4️ Sensitivity Labels & Data Classification

✅ Sensitivity labels exist (even if only a few)
✅ Labels are applied to key documents and libraries
✅ Staff understand “Public vs Confidential” at a basic level
✅ We know Copilot respects sensitivity labels
✅ We are aware auto‑labelling may change labels automatically

Minimum viable setup:
Public / Internal / Confidential is often enough to start.

5️ Data Loss Prevention (DLP) Basics

✅ DLP is enabled for email and files
✅ Alerts or user warnings exist for sensitive data sharing
✅ We accept that Copilot follows the same DLP rules
✅ IT monitors DLP incidents (not just blocks them)

Without DLP:
Copilot can still answer—but may summarise data you’d rather it didn’t.

6️ Devices & Work Locations

✅ Devices are managed (Intune or equivalent)
✅ We know which devices are corporate vs personal
✅ Business data access is restricted on unknown or unmanaged devices
✅ Staff regularly work from approved locations

Why this matters:
Copilot uses the same trust signals as Outlook, Teams, and SharePoint.

7 Governance & Change Management

✅ Someone owns Copilot decisions (not “everyone”)
✅ We have user guidance for:

  • What Copilot is

  • What Copilot is not ✅ Staff know they remain responsible for final output
    ✅ We are prepared to say “not yet” to some AI use cases

Copilot readiness is organisational, not just technical.

8 Helpdesk & User Expectations

✅ Helpdesk knows Copilot behaviour changed in April 2026
✅ We can explain “why Copilot looks different now”
✅ We know where Copilot is expected to work (and where it won’t)
✅ We’ve set expectations around quality, limitations, and review

Silence here = frustration later.

✅ Copilot‑Ready Summary

  • Mostly ✅ → You’re ready to enable Copilot safely

  • Several ⚠️ → Fix fundamentals first

  • Many ❌ → Copilot will amplify risk and confusion

Rule of thumb:

If you wouldn’t be comfortable with an intern reading and summarising your Microsoft 365 data, Copilot isn’t the problem—your tenant is.

From tribal knowledge to Copilot skills: seven patterns every MSP should write down

image

Every MSP I’ve worked with has a playbook. Some of it is written down. Most of it lives in the head of the engineer who’s been there longest. When that engineer is sick, on leave, or finally takes the holiday they’ve been promising themselves for two years, the playbook walks out the door with them.

That’s the gap I’ve been thinking about lately. We’ve built systems that handle tickets, monitor endpoints, and bill clients. We have not done a great job of capturing the judgement — the way a senior engineer triages a queue at 7am, the questions they ask before onboarding a new client, the tone they take when a CEO’s mailbox is broken on a Monday morning.

Microsoft 365 Copilot, with the right scaffolding, finally gives us somewhere to put that judgement. Not as a chatbot. As a set of repeatable skills your team can run consistently every time.

Why bother turning workflows into skills

A skill, in this context, is a short markdown file that tells Copilot how to handle a specific kind of work. It’s the difference between asking your assistant a vague “help me with this client” and handing it a defined process — what to ask, what to gather, what to produce, where the guardrails sit.

The payoff isn’t raw speed. It’s consistency. Every new starter at every client gets onboarded the same way. Every QBR pack tells the same story in the same shape. Every outage update lands in your house voice, at the right interval, instead of being workshopped at 9pm by a tired engineer.

I’ve drafted seven of these as examples to show what’s possible. Walk through them with me.

The client-facing rhythm

Four of the skills cover the moments that define your client relationship.

Client onboarding is the first. The new MSA is signed, and somewhere between sales and service delivery, things get dropped. The skill gathers the structured client profile — domains, contacts, service tier, compliance obligations — and produces three artefacts every time: a welcome email, an internal Teams announcement to the delivery team, and a technical checklist for the engineer. Wire it into the tenant via Graph so domain checks and the initial license inventory happen up front. Schedule the day-7, day-30, day-90 touchpoints into Outlook before the engineer even picks up the work.

Employee onboarding is the same idea at the user level. New starter, Monday start, the client manager has asked for “the usual setup.” With a skill driving it, the usual becomes auditable: identity provisioned, license assigned from a role template (not copied from a colleague — that’s how entitlement drift starts), Intune enrolment, mailbox memberships, a manager briefing, and a quick-reference card the new hire actually opens on day one. Surface every drafted communication for review. Never auto-send.

QBR preparation is where most MSPs leave money on the table. The data is already there — tickets in the PSA, patch status in the RMM, Secure Score and license utilisation in the tenant. Pulling it together into a story takes hours. A skill turns it into a repeatable build: scorecard, security posture, license rightsizing, projects, roadmap. Compute every percentage with code, never by eye — a wrong MFA percentage in a QBR undermines the whole pack. Use the pptx generation to produce the deck and a Word leave-behind for the people who want detail. The trick is to lead with theme and support with data, not the other way around.

Incident communications is the one nobody wants to think about until it’s needed. When Exchange Online wobbles on a Tuesday morning, your engineers should be fixing the problem, not workshopping the wording of the customer email. The skill drafts the four stages — initial notification, progress update, all-clear, post-incident review — using only confirmed facts from Microsoft’s Service Health dashboard or your own monitoring. Never speculate about root cause in a customer-facing message. Promise an update time, not a fix ETA. Send via the channel you started on; don’t fragment.

The operational backbone

The other three skills run quietly in the background and pay you back every week.

Ticket triage applies a real Impact × Urgency matrix to your inbound queue. Most MSPs let priority drift to whatever the user typed in the subject line. With a skill driving it, every ticket gets classified the same way, security signals automatically bypass the matrix, and the engineer gets a drafted first response they can paste straight into the PSA. You’ll find it catches the “third password reset this week” pattern and quietly suggests a root-cause review — the kind of thing a good Tier 2 engineer does naturally and a stretched team often misses.

License rightsizing is the easiest commercial conversation you’ll have all year. Almost every tenant carries 10–25% waste — disabled accounts still licensed, E5 users who haven’t opened a Power BI report in a year, shared mailboxes nobody downgraded after the staff member left. The skill pulls full license inventory and sign-in history through Graph, applies a rule set, and produces a numbered list of decisions for the client with a dollar value next to each. Run it before every renewal. Run it again three months later.

Security baseline check is the one I’d implement first if I were starting fresh. Pick a standard — Essential Eight, CIS Microsoft 365 Foundations, or your own house baseline — and let the skill walk through every control. Conditional Access posture, MFA coverage, DMARC, Intune compliance, backup test recency. Each control gets a Pass, Partial, or Fail with cited evidence. The deliverable isn’t a Secure Score screenshot. It’s a 90-day remediation plan with named owners and real dates. That’s what survives an audit.

How to actually roll this out

Don’t try to deploy all seven at once. That’s how good initiatives die in busy MSPs.

Pick the one that hurts most this month. For most teams, that’s either ticket triage or QBR prep. Run it manually for a fortnight — meaning, your senior engineer literally walks through it for every relevant case and notes the spots where the prompt needs more local detail. Add your tier names, your SLA wording, your house security baseline, the SKUs you actually sell, the language your clients respond to.

Store the skill files where your team can edit them. Treat them like internal documentation — versioned, reviewed, owned by a named person. A skill nobody updates is a skill that quietly stops matching how the business actually works, and then it starts producing confidently wrong output, which is worse than no skill at all.

Keep a human in the loop on every customer-facing or change-making step. None of these skills should send a client email, remove a license, or modify a Conditional Access policy without explicit review. The aim is to make the engineer faster and more consistent — not to remove the engineer from the decision.

And track the saves. The first time the QBR skill cuts your prep from six hours to two, write that number down. The first time the rightsizing skill finds $4,000 a year of waste in a client’s tenant, write that down too. Those numbers are what you’ll show your team when you ask them to maintain the next skill, and what you’ll show your accountant when they ask why the Copilot licenses were worth it.

7 example skills MSPs could drop into their own setup. Each one targets a real, recurring pain point. They are located in my Github repo here – https://github.com/directorcia/Office365/tree/master/Cowork-Skills

client-onboarding.md – Standardizes the first 30 days of a new MSA — kickoff pack, technical checklist, recurring touchpoints

qbr-prep.md – Builds a defensible Quarterly Business Review pack — service scorecard, security posture, license optimization, roadmap

ticket-triage.md – Applies a consistent Impact × Urgency framework to the support queue, drafts first responses

incident-comms.md – Drafts every stage of outage comms — initial notification, hourly updates, all-clear, post-incident review

license-rightsizing.md – Finds unused, oversized, and duplicated M365 licenses and quantifies the savings

security-baseline-check.md – Runs an Essential Eight / CIS / house-baseline gap analysis and stages remediation

employee-onboarding.md – Provisions a new starter end-to-end — identity, licenses, devices, Day-1 experience

Each follows the same SKILL.md structure (frontmatter + when-to-use, inputs, workflow, guardrails, done-when), so they should slot straight into a personal skills folder. They’re all in your output folder ready to download. See this post:

https://blog.ciaops.com/2026/04/23/creating-custom-copilot-cowork-skills-that-actually-matter-for-smbs/

for more information about implementing Microsoft 365 Copilot Cowork skills in your own environment.

What’s available natively in Microsoft 365

The skills can pull directly from:

  • Microsoft 365 via Graph — mailboxes, calendar, Teams chats, SharePoint/OneDrive files, people directory, sign-in activity, license assignments, Conditional Access policies, Secure Score

  • Web search — vendor status pages, public DNS lookups, pricing references

  • Files the user uploads — exports from other systems dropped into the workspace

  • Ask User Question — anything the user can answer

Mapped per skill

client-onboarding – New client details, tenant info User input + Graph for tenant/domain verification. Mostly user-driven.

qbr-prep – Tickets, patch %, backup status, licenses, Secure Score

Mixed — Secure Score and licenses come from Graph; tickets, patch, backup need exports from your PSA/RMM/backup tools because there’s no MCP connector for ConnectWise/Halo/NinjaOne/Datto today.

ticket-triage – A list of open tickets. Currently the user pastes them in or drops a CSV export. No live PSA integration.

incident-comms – Outage facts, vendor status. User input for the facts; web search for vendor status pages.

license-rightsizing – License inventory, last sign-in, mailbox state. Almost entirely Graph API — this one works end-to-end with what’s available.

security-baseline-check – CA policies, MFA stats, DMARC, Intune compliance, Secure Score .Mostly Graph — CA, MFA, Secure Score, Intune all reachable. DMARC needs a DNS lookup (web search workaround).

employee-onboarding – Role template, manager, license SKU. User input + Graph to actually create the user, assign groups, license.

The honest gap

The MSP-specific data sources — PSA, RMM, EDR consoles, third-party backup, documentation platforms (IT Glue / Hudu) — don’t have native connectors here. Skills that need them currently fall back to:

  1. The user pasting an export

  2. Dropping a CSV/XLSX into the workspace

  3. The skill explicitly flagging “data not available, please provide”

Two practical paths forward if you want these to be more autonomous:

  • Short term: each skill assumes a standard export format (e.g., “drop your PSA ticket CSV with these columns”) and works from that.

  • Longer term: a custom MCP connector for the PSA/RMM in your stack — that’s where it becomes genuinely hands-off.

What to do next

The hard part of running an MSP has never been the technology. It’s been keeping a team of busy people doing the right thing the same way every time. Codified Copilot skills are the closest thing I’ve seen to a real answer to that — and they finally put the data already sitting in your clients’ tenants to work.

Pick one. Write it down. Run it for a week. See what changes.