Our Business Isn’t Too Small to Be a Target — It’s the Perfect One

I hear the same line at least once a month. It usually comes near the end of a conversation, after I’ve raised the idea of tightening up someone’s security. The owner leans back, gives a little shrug, and says some version of: “Mate, we’re tiny. Why would anyone bother with us?”

I understand the instinct. When you’re running a ten-person business out of a converted warehouse, the idea that someone in another country has you in their sights feels absurd. You’re not a bank. You’re not a government department. You’re just trying to get invoices out and keep the team paid. Surely the criminals are off chasing bigger fish.

That’s exactly the thinking they’re counting on.

Nobody Is Picking You by Name

Here’s the part most owners get wrong. They picture a hacker hunched over a keyboard, deliberately choosing their business out of all the businesses in the world. That’s not how it works. Almost none of it is personal.

Modern attacks are automated. Software quietly scans enormous ranges of the internet, day and night, knocking on every door it can find and noting which ones are unlocked. It doesn’t know you’re a plumbing supplier in Penrith or a three-person design studio. It only knows your front door opened when it shouldn’t have. To that software, “too small to matter” simply doesn’t exist as a category. There’s only “easy” and “hard.”

And small businesses, on the whole, are easy. No dedicated IT person. Passwords reused across half a dozen logins. Multi-factor authentication switched off because it felt like a hassle. That combination is gold to an attacker, because the effort is low and the payoff is real. A single compromised Microsoft 365 account can read every email, reset other passwords, and quietly send invoices with the bank details changed to theirs. You don’t need to be big to be worth a few thousand dollars of someone’s afternoon.

The Invisibility You Feel Is the Vulnerability They Want

The cruel irony is that the very feeling protecting your peace of mind — “we’re invisible, nobody’s looking” — is the thing that leaves you exposed. Because if you believe nobody’s looking, you don’t bother locking up. You stay on the basic plan. You skip the security review. You assume the defaults are fine.

I had a client go through exactly this last year. Small operation, well run, no reason to think they were on anyone’s radar. One staff member clicked a convincing email, typed their password into a fake login page, and that was it. The attacker sat inside the mailbox for the better part of a week — reading, watching, learning the rhythm of how money moved — before redirecting a genuine client payment. The owner’s first words to me were, “I didn’t think we were big enough for this to happen.”

That’s the trap, summed up in one sentence. Feeling small doesn’t make you safe. It just makes you slow to defend yourself.

The Good News: The Locks Are Already in the Building

Here’s what I tell people, and it’s the part worth holding on to. You don’t need an enterprise budget to stop the overwhelming majority of this. The tools are very likely sitting in the Microsoft 365 subscription you already pay for.

Turn on multi-factor authentication for every account — it’s the single biggest difference you can make, and it blocks the password-stealing attack I just described almost entirely. Switch on the security defaults in Microsoft Entra so the obvious gaps close themselves. Let Microsoft Defender do what it’s built to do: catch dodgy attachments and links before a tired staff member clicks them at 4pm on a Friday.

You can even put Copilot to work here. Ask it in plain English to summarise the recent sign-in activity across your tenant, or to walk you through what your current security settings actually mean. I’ve watched owners who’d never open an admin console suddenly understand their own exposure because Copilot explained it in language that made sense to them, sitting right there in their browser.

None of this is glamorous. None of it makes for an exciting Monday. But it’s the difference between being a hard door and an easy one — and easy is the only thing the software scanning the internet actually cares about.

So drop the idea that you’re too small to bother with. You’re not invisible. You’re convenient. The sooner you stop feeling safe and start being protected, the less interesting you become to the only audience that matters here — and that’s a very good place for a small business to sit.

Defender for Endpoint Web Filtering

A client rings up. Staff are burning half the day on betting sites, or someone clicked something they shouldn’t have, and now they want you to “lock down the web.”

So you go and price a web filter. Cisco Umbrella, DNSFilter, a firewall add-on. Another line item, another agent, another renewal to babysit.

Stop.

If that client is on Microsoft 365 Business Premium, you already sold them a web filter. It’s been sitting inside Defender, switched off, the whole time.

That’s not an upsell. That’s a setting.

What is web content filtering, really?

It watches where your devices go on the web and lets you block whole categories of sites by name. Gambling. Adult content. Peer-to-peer. Hacking. You tick a category, and people in the groups you choose stop being able to reach it, whether they’re in the office or working from a café.

Microsoft calls it web content filtering, and it rides on protection that’s already on the machine. In Edge, the blocks are enforced by SmartScreen. In Chrome, Firefox, Brave and Opera, they lean on network protection. Both of those have to be switched on, or nothing happens.

Here’s the part most people miss. Any category you don’t block gets audited automatically. So before you stop a single site, you get a report of exactly where your client’s staff have been going.

You can’t filter what you can’t see. So start by seeing.

Step-by-Step: turn it on, then point it at something

Switch on the feature

In the Microsoft Defender portal, go to Settings > Endpoints > Advanced features and flip Web content filtering to On. Save.

Create a policy and just watch

Go to Settings > Endpoints > Rules > Web content filtering and add a policy. Target a device group. Don’t block your client’s contentious categories yet. Let the audit data build.

Read the report

Open Reports > Web protection and look at the Web activity by category card. Give it time, there’s up to a 12-hour lag before activity shows up. This is the bit that changes the conversation. You’re no longer guessing what staff do online. You’re looking at it.

Block what actually matters

Now edit the policy and tick the categories the report told you to care about.

Microsoft Defender portal → Settings → Endpoints
   Advanced features → Web content filtering = On
   Rules → Web content filtering → + Add policy
Reports → Web protection → Web activity by category

Notice what’s missing? No PowerShell. No third agent. No new licence. Every step lives in a portal your client is already paying for.

Why this actually changes behaviour

Because you walk into the renewal with evidence, not a hunch.

“Here are 4,000 hits to gambling sites last month, off three machines.” That’s a discussion the business owner can act on. A quote for Umbrella is just a number they’ll push back on.

“But we already quoted them a web filter.” Fine. Now you can show them what they’d be paying for, and that they already own it.

A few things will bite you if you’re not watching for them:

Edge uses SmartScreen, everything else uses network protection. If network protection is in audit mode or off, your blocks are theatre. Lovely report, no enforcement.
Non-Microsoft browsers won’t honour HTTPS category blocks unless QUIC and Encrypted Client Hello are disabled. Leave them on and Chrome quietly routes around you.
Expect lag. Up to 12 hours before activity lands in the report, up to two hours before a block bites. Don’t test it in the first five minutes and declare it broken.

And when you genuinely need an exception, you don’t loosen the whole category. You carve out one site with a custom indicator, which sits above the filter in the order of precedence. Allow always wins over block. That’s your release valve when the boss insists on one specific site.

Run the audit, read the Web protection report, then block with proof in hand.

Web content filtering isn’t there to add a product to your stack. It’s there to delete one.

If you’re billing a client for a separate web filter on top of Business Premium, you’re charging them for something they already own. Show them the report instead.

That’s not filtering. That’s value you can prove.

Defender for Endpoint device control (USB / removable media)

Walk into most small businesses and ask how they stop someone walking out the door with a USB stick full of client data. You’ll get one of two answers.

Either “we glued the ports shut” or “we don’t.”

Both are wrong. One is a sledgehammer. The other is a shrug. And the worst part? The tool that does this properly is already sitting in the licence they’re paying for every month.

If your clients are on Microsoft 365 Business Premium, they have Defender for Business. And device control comes with it. You’re not buying anything. You’re just not turning it on.

Let’s fix that.

What is device control, really?

Forget “blocking USB sticks.” That framing is what gets people stuck.

Device control isn’t a switch. It’s a set of rules about who can do what with which device. Read. Write. Execute. You can let the finance PC read a USB drive but never copy to it. You can allow one approved brand of encrypted stick and deny every other. You can leave Bluetooth alone and only police removable storage.

That’s the part people miss. It’s not on or off. It’s a dial.

And here’s the bit that actually matters for an SMB: it watches before it blocks. Every time someone plugs something in, Defender logs it — the device, the serial number, the user, the machine. You get a record without enforcing a single rule.

You can’t block what you can’t see. So start by looking.

Step-by-Step: turning it on without breaking anything

Open the right blade

Head to the Microsoft Intune admin center and go to Endpoint security > Attack surface reduction. That’s where device control lives. Not where you’d guess, I know.

Audit first, always

Don’t block anything yet. Enable device control in audit mode and leave enforcement alone. Let it run for a week or two across a pilot ring. You’re collecting evidence, not making arrests.

Read the report

In the Microsoft Defender portal, open the device control report and Advanced hunting. Here’s the query that tells you everything that’s been plugged in:

DeviceEvents
| where ActionType == "PnpDeviceConnected"
| extend parsed = parse_json(AdditionalFields)
| extend MediaClass = tostring(parsed.ClassName)
| extend MediaSerialNumber = tostring(parsed.SerialNumber)
| project Timestamp, DeviceName, AccountName, MediaClass, MediaSerialNumber
| order by Timestamp desc

Notice what’s missing? There’s no block in there. That’s a visibility query. You’ll be surprised what shows up — personal phones, dodgy giveaway sticks from a conference, the bookkeeper’s external drive.

Set the dial

Now you write the actual policy: default deny on removable storage, then carve out exceptions for the devices you trust. Scope it to removable media only so you don’t accidentally fight with printers or webcams.

Roll it in rings

Pilot group first. Then a wider ring. Then everyone. Same three-ring discipline you’d use for anything that touches the endpoint. Never enforce tenant-wide on day one.

Why this actually changes behaviour

Here’s the real win. It’s not the block. It’s the conversation the block lets you have.

When a client asks “can someone steal our data on a USB?”, “we glued the ports” sounds paranoid and “we don’t” sounds negligent. Neither builds trust.

“We allow encrypted drives, we log every device that connects, and we can show you exactly what plugged in last month” — that’s a different conversation. That’s the answer that wins the renewal.

Before: “USB is a risk we just live with.” After: “USB is a risk we measure, scope, and report on.”

And it costs nothing extra. You already sold them the licence. This is value you left in the box.

Device control isn’t there to lock the door. It’s there to tell you the door was open the whole time — and let you decide, device by device, who gets a key.

If you’re not showing your clients this, you’re leaving it on the table for someone else to find.

Defender Vulnerability Management

Most people treat Defender Vulnerability Management like a weather report. They glance at the exposure score, nod, and close the tab.

That’s a waste.

The score isn’t the point. The workflow behind it is. And the part almost nobody uses — the bit that actually moves the needle — is the security baselines assessment sitting right next to it.

Here’s the thing. Patching tells you whether software is current. A baseline tells you whether it’s configured the way it’s supposed to be. Those are two completely different questions, and the second one is where most SMB environments quietly fall apart.

What are security baselines, really?

A baseline is a benchmark of configuration settings — things like password policy, BitLocker, account lockout, audit logging — measured against an industry profile.

In Defender, you assess your devices against the CIS or STIG benchmarks, pick a level (L1 is sensible-default, L2 is locked-down), and the tool tells you, device by device, setting by setting, where you comply and where you don’t.

Not “you’re missing 14 patches.” More like “BitLocker isn’t enforced on 9 machines and your audit policy is wide open.” That’s the stuff attackers love and scanners ignore.

The security baselines assessment documentation walks through the profile options if you want the full menu.

Step-by-Step: Build a baseline profile

You’ll need Defender for Endpoint Plan 2 with the MDVM add-on, or the MDVM Standalone licence. Then head to the Microsoft Defender portal → Exposure management → Baselines assessment.

Create the profile

Give it a name, choose your benchmark (CIS or STIG), choose your OS, choose your level. Start at L1. You can tighten later — leading with L2 just buries you in red.

Scope it to a device group

Don’t boil the ocean. Point it at one group — a handful of servers, or the managed laptops — and let it run.

Read the results by setting, not by score

Open the profile and sort by compliance. Each failing setting lists exactly which devices miss it. This is your work queue.

Now the part that earns its keep: exceptions

Here’s the reality every MSP knows. Some findings you can’t fix. The line-of-business app needs that legacy setting. The client won’t approve the downtime. The vendor says “don’t touch it.”

So what do most people do? Nothing. The finding sits there, red, forever — and after a while everyone stops looking because the dashboard is always angry.

That’s the trap. A permanently-red dashboard is the same as no dashboard.

The fix is the exception workflow. When you genuinely can’t remediate something, you file an exception — with a justification and an expiry date — and that finding drops out of your active exposure number. It doesn’t vanish. It’s parked, documented, and time-boxed.

Request the remediation first

For anything you can fix, connect Defender to Intune (it’s a toggle in the portal) and raise a remediation request straight from the recommendation. It lands in Intune as a tracked task instead of a Post-it note. The remediation request process covers the Intune connection.

File an exception for the rest

For the genuine “we can’t touch that,” create an exception with a real reason and a review date. The exceptions overview explains the justification types and how exceptions affect your exposure score.

“Doesn’t an exception just hide the problem?”

No. Hiding is when you ignore the red and hope. An exception is a decision — recorded, owned, and due for review. The difference is accountability.

Why this actually changes behaviour

Once you’re running baselines plus a disciplined exception workflow, “we can’t patch that one” stops being a silent gap. It becomes a documented, time-boxed choice with someone’s name on it.

That’s not a security feature. That’s a governance habit.

And it’s the exact thing that turns a vague “yeah, we’re secure” into a report you can hand a client.

If you’re not showing your clients their baseline posture and the exceptions you’ve signed off on, you’re leaving value — and trust — on the table.

The exposure score was never the deliverable. The conversation it lets you have is.

Defender for Cloud Apps session policy

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

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

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

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

What is a session policy, really?

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

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

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

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

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

Step-by-Step: blocking download to unmanaged devices

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

Build the Conditional Access policy

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

Turn on App Control

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

Move to the Defender portal

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

Filter to OneDrive and unmanaged devices

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

Write a real block message

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

Run it in monitor-only first

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

Why this actually changes behaviour

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

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

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

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

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

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

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

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

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

Where MSPs trip up

Three things bite people on the first rollout.

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

My recommendation

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

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

Most SMB tenants have a guest graveyard

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

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

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

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

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

Time to fix that.

What is Access Reviews, really?

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

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

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

What you need to run one

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

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

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

Step-by-Step: a recurring guest review

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

Open the portal

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

Pick what to review

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

Set Scope to Guest users only.

Pick your reviewers

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

Set the schedule

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

Set the settings that actually matter

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

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

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

Step-by-Step: privileged groups and admin roles

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

For Entra admin roles

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

For privileged groups

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

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

One artefact you can paste into every client runbook

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

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

Why this actually changes behaviour

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

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

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

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

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

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

What is Microsoft Agent 365, really?

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

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

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

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

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

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

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

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

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

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

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

Sign in to the Microsoft 365 admin centre

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

Open the Agents workload

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

Review the registry

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

Hunt for ownerless agents

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

Apply a policy

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

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

Why this actually changes the game

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

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

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

My recommendation?

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

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

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

Intune compliance policies + Conditional Access integration

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

They aren’t.

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

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

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

What is an Intune compliance policy, really?

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

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

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

Step-by-Step: wiring compliance to Conditional Access

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

Fix the tenant default first

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

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

Change it to Not compliant. Save.

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

Build the compliance policy

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

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

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

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

Build the Conditional Access policy

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

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

Target resources: All resources.

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

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

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

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

Watch report-only for a week

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

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

Why this actually changes behaviour

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

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

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

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

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