RobsonRitch Cyber Security

Author: patrick

  • Microsoft ISOC: Where Defender and Sentinel Are Heading

    Microsoft has announced one of its biggest shifts in security operations strategy in years: the Integrated Security Operations Center (ISOC) in Microsoft Defender.

    The pitch is simple. XDR, SIEM, threat intelligence, automation and AI all live in one place, and that place is the Defender portal. Defender and Sentinel stop being two largely separate experiences.

    If you run a Microsoft-heavy estate, don’t treat this as just another feature release. It tells you where Microsoft expects your SOC to live.

    What is ISOC?

    ISOC brings the following together inside Defender:

    • Microsoft Defender XDR
    • SIEM capabilities traditionally associated with Sentinel
    • Threat intelligence
    • Security automation
    • AI-assisted operations
    • Case management
    • Security analytics
    • Workbooks and reporting

    Microsoft describes it as a shared foundation where analysts and AI agents work from the same signals, context and workflows.

    My view: stop thinking of Defender as “the XDR” and Sentinel as “the SIEM”. Microsoft already has. Defender is now being positioned as the primary SecOps interface.

    Why Microsoft is doing this

    If you’ve worked in a SOC running both products, you know the friction. Defender covers endpoint, identity, email, cloud apps and incident correlation. Sentinel covers log aggregation, analytics, custom detections, automation, hunting and long-term retention.

    In practice that meant two portals, two data models and two sets of workflows. Analysts lose time pivoting between them mid-incident, and everyone ends up with a slightly different picture of the same attack.

    Microsoft’s answer is shared signals, context, controls and workflows for human analysts and AI agents alike. The problem is real and the fix is sensible. Whether the AI half lives up to the billing is a separate question, and we’ll come back to it.

    How it fits together

    ISOC has three layers.

    Signals. Built-in telemetry from Defender for Endpoint, Identity, Office 365, Cloud Apps and Cloud, plus Entra Identity Protection and Azure Activity Logs. That’s native visibility across the Microsoft stack without much plumbing.

    Context. Incidents, assets, identities, threat intelligence, user behaviour and security posture correlated into a single model.

    Action. Automated disruption, investigation workflows, playbooks, AI-assisted response and incident handling. Microsoft calls this the “integrated protection loop”.

    It’s a tidy model. The value will come from how well the context layer works with your real, untidy data.

    What you can use today

    ISOC is in preview, so treat everything below accordingly.

    Native case management. You can run investigations in Defender without a separate SIEM experience. For me this is the most practical addition. Less context switching, centralised investigations and shared evidence handling are the sort of gains analysts notice on day one.

    Workbooks. Executive dashboards, threat monitoring, posture reporting and operational metrics, without a traditional Sentinel deployment. Smaller teams that wanted reporting but not a full SIEM build will like this.

    Natural language to SOAR. This is the most interesting addition. You describe a workflow in plain English, such as “isolate a device when ransomware indicators are detected and notify the incident response team”, and ISOC generates the automation framework.

    It’s a genuine time-saver. But I’d treat the output as a first draft. Read it, test it, and don’t let a generated playbook that isolates devices anywhere near production unreviewed.

    Enhanced automation rules. Incident enrichment, automated response, alert suppression and workflow orchestration, directly in Defender.

    Threat intelligence. With an ISOC workspace you get IOC management, threat tracking, campaign monitoring and intelligence-driven detections.

    UEBA. Also tied to the workspace. Expect user anomaly detection, insider risk indicators, behaviour baselining and entity correlation.

    What’s coming next

    Microsoft has dropped plenty of hints.

    Project Perception. ISOC is being built as the operational foundation for this initiative. Expect multi-agent investigations, autonomous threat hunting, AI-led response recommendations and continuous security optimisation.

    The “Agentic SOC”. Microsoft keeps using the phrase. It describes human analysts, Security Copilot and autonomous agents working in one environment. I’d judge it on what ships, not on the slide decks. The direction is clear, but “autonomous” will earn trust slowly in any SOC that has to answer to an auditor.

    More SIEM consolidation. Expect analytics rules, hunting, automation, threat intelligence and security content management to become consumable straight from Defender.

    Microsoft has not announced the retirement of Sentinel, and existing customers continue unchanged.

    Licensing

    Current eligibility requires one of the following:

    • Microsoft Defender Suite
    • Microsoft 365 E5
    • Microsoft 365 E7

    You’ll also need an Azure subscription to create a workspace.

    Two things to note. There’s no minimum seat count, which is welcome. But Education and Frontline SKUs aren’t eligible yet.

    How to enable ISOC

    1. Check your licensing. Confirm you hold Microsoft 365 E5, E7 or the Defender Suite.
    2. Check your Sentinel status. The preview currently targets customers without an active Sentinel workspace. Microsoft is explicit that you should not disconnect a production Sentinel workspace just to get into the preview. Please don’t.
    3. Go to security.microsoft.com. Eligible tenants should start seeing ISOC onboarding experiences.
    4. Create an ISOC workspace (optional). You’ll need this for UEBA, threat intelligence, Content Hub, CI/CD integration and third-party ingestion. It needs Azure permissions and a subscription link.

    How to stop ISOC being enabled (for now)

    Plenty of organisations won’t be ready during preview, and that’s a perfectly reasonable position. Common reasons are existing Sentinel investments, SOC process maturity, regulatory concerns, change control and integration dependencies.

    If that’s you, here’s what I’d do.

    Keep your Sentinel deployment as it is. Microsoft’s own guidance is to stay on your existing Sentinel experience during this phase. It’s currently your strongest control.

    Restrict workspace creation. Creating an ISOC workspace needs Azure permissions (Microsoft Learn). Review who holds Owner, Contributor, Security Administrator and Sentinel Administrator roles involved in onboarding. In many tenants that list is longer than anyone expects.

    Put change governance around it. Before anyone switches it on, review operational processes, automation impact, integrations and retention implications. Test in non-production first.

    Treat it like any other preview. Security Copilot, Defender for Cloud previews and new Sentinel features should all go through architecture review before onboarding. ISOC belongs in the same queue.

    What this means for Sentinel customers

    The question everyone’s asking is whether Sentinel is going away.

    For now, no. Microsoft says nothing changes for existing customers and the Sentinel offering continues. Existing customers will be able to move to ISOC from November 2026 if they meet the eligibility requirements (Microsoft).

    But read the direction of travel:

    • Defender becomes the primary SecOps experience
    • Sentinel capabilities increasingly surface in Defender
    • AI-driven operations become native
    • Protection and operations get more tightly linked

    You don’t need to panic. You do need a plan.

    Final thoughts

    ISOC is arguably Microsoft’s most important security platform change since Microsoft 365 Defender launched. The vision of XDR and SIEM in one place, with native automation, threat intelligence and shared workflows for analysts and agents, is a strong one.

    For security architects, the main point is that Microsoft no longer treats SIEM, XDR and AI as separate products. Telemetry, investigation, automation and response are heading into a single platform.

    If you’re an early adopter, start evaluating now and be honest about the operational impact. If you run a mature Sentinel deployment, take a measured approach. Let Microsoft finish the platform and define the migration path over the coming year, and spend the time getting your governance and processes ready.

  • Microsoft Purview DSPM: The Data Security Tool Most Organisations Actually Need

    If you spend your days in Microsoft 365 security, you’ll recognise this pattern. Most organisations think they understand their data. They don’t.

    They know where some of it lives. They know where they hope it lives. They rarely know where it all lives.

    That’s the exact problem Microsoft Purview Data Security Posture Management (DSPM) solves.

    For years, we’ve poured our attention into identities, endpoints and infrastructure. Fair enough — attackers hit those areas daily. But data is still what criminals are after when the attack finally lands.

    DSPM drags the conversation back to the data itself.

    About time, frankly.

    What Is Microsoft Purview DSPM?

    Purview DSPM gives you visibility into sensitive data across your estate and flags where the risk sits. It boils down to four questions:

    • What sensitive data do we actually have?
    • Where does it live?
    • Who can get to it?
    • How well is it protected?

    It isn’t a bolt-on product. DSPM pulls together intelligence you’re probably already generating through:

    • Data Loss Prevention (DLP)
    • Sensitivity labels
    • Insider Risk Management
    • Data Security Investigations
    • Activity monitoring and reporting

    Instead of hopping between five different portals trying to piece together a picture, you get one view of data risk.

    The Real Problem DSPM Solves

    Every time I run a security assessment, the same pattern shows up.

    The customer is confident their sensitive data is under control.

    Then we look.

    Within a few hours, we’re usually staring at:

    • Thousands of unclassified files
    • SharePoint sites shared far too widely
    • Sensitive documents open to entire departments
    • Old data nobody remembered existed
    • Staff sharing information externally with no bad intent whatsoever

    None of this is sophisticated. It’s simply what happens after years of growth, mergers, and “quick” collaboration decisions nobody ever revisited.

    DSPM shines a light on it. It moves security teams away from guesswork and toward evidence — which, in my experience, completely changes the conversation with leadership.

    Data Discovery Is Worth More Than People Expect

    Sensitive data discovery is one of DSPM’s strongest features.

    Microsoft continually scans the environment, identifies sensitive information, and checks how exposed and protected it actually is.

    Sounds routine. It isn’t, once you see the output.

    Most organisations turn up a surprising volume of:

    • Financial information
    • Personal data
    • HR records
    • Customer information
    • Commercially sensitive documents

    sitting in places nobody ever intended it to be.

    This is shadow data, and it’s often the biggest risk in the building, purely because nobody’s watching it. DSPM is built to dig this stuff out and put a number on the risk it carries.

    In practice, discovery alone tends to justify the licence cost before you’ve done anything else.

    Oversharing Is the New Front Line

    Security teams used to spend their energy on external attackers.

    These days I spend just as much time talking about oversharing.

    Microsoft 365 made collaboration effortless. Great for productivity. Not so great for risk.

    A file doesn’t need to be public to be exposed. It just needs to be visible to the wrong colleague.

    DSPM includes workflows aimed specifically at spotting and reducing oversharing, particularly across Microsoft 365 and AI-enabled services.

    This matters more as Copilot rolls out.

    Copilot only sees what a user already has permission to see. If permissions are too loose, Copilot doesn’t create a new problem — it just finds your existing one faster.

    That’s not a Copilot issue.

    It’s a governance issue you were always going to have to fix.

    DSPM lets you find it before Copilot does.

    DSPM and AI: More Useful Than the Marketing Makes It Sound

    There’s a lot of noise about AI security right now. Some of it’s worth your time. Most of it isn’t.

    The genuinely useful part of DSPM is that it tackles AI security from the data side, not the model side.

    Microsoft has built in dedicated visibility into AI apps, agents and data interactions — so you can watch for oversharing, odd access patterns and potential exfiltration through Copilot and other AI tools.

    I think that’s the right way round.

    Most AI risk is data risk wearing a new outfit. Classify, protect and govern the data properly, and a lot of the AI worry sorts itself out.

    Turning Visibility Into Action

    A dashboard full of problems isn’t much use on its own. I’ve sat through enough of those reviews to know that.

    What I rate about DSPM is that it doesn’t stop at “here’s your risk.” It gives you a path: apply a label, build a DLP policy, investigate the odd activity, cut back the exposure. It also tracks whether your posture actually improves over time.

    That’s the difference between “I found a problem” and “I fixed a problem” — and in my experience, that’s exactly where most projects stall.

    My View

    Purview DSPM isn’t the flashiest product in the Microsoft security line-up. It won’t steal headlines the way Security Copilot or Defender XDR does.

    But it solves the problem I run into most often on customer sites: organisations don’t actually know their own data estate.

    That blind spot is where the risk lives.

    DSPM gives you a genuinely practical way to find sensitive data, understand where it’s exposed, spot oversharing and work out what to fix first. It pulls together several Purview capabilities into one coherent view instead of five disconnected ones.

    If you’re investing in Microsoft 365, Purview or Copilot, I’d treat DSPM as foundational, not optional. That’s increasingly where I land with every customer I advise.

    Because you can’t protect data you can’t see.

    And for most organisations I work with, that’s still the hardest question on the table.

  • Moving from Entra Connect Sync to Cloud Sync: what you actually need to know before you touch anything

    Let’s start with the headline, because it changes the tone of the rest of this post: Microsoft confirmed in April 2026 that Entra Connect Sync is being retired. Cloud Sync becomes the default sync engine, and tenant notifications have been rolling out in phased waves since July 2026, based on which features each environment actually needs from Cloud Sync before it’s safe to move.

    Worth being precise about what that means, because there’s a fair amount of noise around it. It isn’t a single hard cut-off for everyone — Microsoft’s own guidance is that you’re not required to migrate until the features you depend on are supported in Cloud Sync, and you can request an exception if you’re genuinely not ready. But it is a retirement, not a suggestion. If you’re still running Connect Sync, you’re already somewhere in that queue, whether or not the notification has landed in your tenant yet.

    Don’t confuse this with the other Connect Sync deadline doing the rounds — the mandatory upgrade to version 2.5.79.0 or later by 30 September 2026, after which synchronisation stops working entirely if you haven’t updated. That’s a security hardening requirement, not the retirement itself. They’re two different clocks. If you’re behind on patching, sort that first before you even start thinking about migration timelines.

    I’ve sat through enough of these migrations now to know the pattern: someone reads a “Cloud Sync is the future” blog post, spins up an agent in a test tenant over lunch, and declares the project basically done. Then Hybrid Azure AD Join breaks, or a group with 60,000 members refuses to sync, and suddenly it’s a very different conversation with the customer.

    So this post is the version I wish someone had handed me before my first Cloud Sync migration: what’s actually happening with the retirement, what Cloud Sync changes, what to check before you start, and where people trip up.

    Why bother moving at all?

    Connect Sync has done its job well for a decade. And now, with a retirement date attached to it rather than just a lack of new features, “increasingly a job nobody wants to own” becomes “a job that’s going away regardless.” That changes how you prioritise this internally — it’s no longer purely a modernisation project you can defer indefinitely.

    It’s a Windows server, sat on-prem, with a sync engine, a database, and a scheduler that somebody has to patch, back up, and babysit. When it falls over at 2am, it’s your problem, and usually it’s your problem alone, because most environments only run one.

    Cloud Sync flips that around. The configuration lives in Entra ID and you manage it from the Entra Admin Centre. What’s left on-prem is a lightweight provisioning agent — genuinely lightweight, not “lightweight” in the way vendors usually mean it.

    The bit I actually care about as a consultant: you can run several active agents at once. Connect Sync gives you an active/passive pair if you’re disciplined about it. Cloud Sync gives you proper active/active, so one agent falling over doesn’t take sync down at all. For anyone who’s been paged because the one Connect Sync box died overnight, that alone is worth the migration.

    Other things worth knowing:

    • Agents update themselves. No more scheduling patch windows for the sync server.
    • Disconnected forests are supported natively — no VPNs or trust relationships needed just to sync identities.
    • New Microsoft sync features land here first, sometimes exclusively.
    • The infrastructure footprint shrinks considerably — no SQL Server (or ADAM/AD LDS) to maintain.

    None of this means Connect Sync is bad. It means Microsoft has stopped investing in it the way they invest in Cloud Sync, and that gap will only widen.

    Before you touch a single agent: check whether you actually can move

    This is the step people skip, and it’s the one that causes the awkward client calls later.

    Cloud Sync doesn’t do everything Connect Sync does. Not yet, and in some cases maybe not ever. Go through this list honestly before you promise anyone a migration date.

    Scale. Cloud Sync currently tops out at 150,000 objects per AD domain, and groups are capped at 50,000 members. If you’re a large enterprise with sprawling security groups, check your actual numbers — don’t assume you’re fine.

    Hybrid Azure AD Join. This is the one that catches people out most often. Connect Sync supports it. Cloud Sync currently doesn’t. If your organisation still relies on Hybrid Azure AD Join for device management, that’s not a footnote — it’s a blocker, and it needs its own conversation (and likely its own plan, possibly involving Entra Join instead) before Cloud Sync becomes viable for you.

    Custom sync rules. If you’ve got a sync engine full of custom inbound/outbound rules, attribute transforms, and clever filtering that some contractor built five years ago and nobody’s touched since — go and actually read it. Cloud Sync has an attribute-mapping expression builder, and it’s decent for straightforward transforms. It is not the Connect Sync rules engine. If your rules are doing anything genuinely complex, expect rework, not a like-for-like port.

    Forest design. Cloud Sync handles single forests, multiple connected forests, and multiple disconnected forests. Fine for most setups. If you’ve got a complicated cross-forest arrangement, go through Microsoft’s feature comparison line by line rather than assuming it’ll just work — cross-forest is exactly where the edge cases live.

    If any of this rings alarm bells, that’s not a reason to abandon the idea. It’s a reason to scope properly before you start, rather than discovering the gap mid-migration.

    Prerequisites: the boring bit that saves you later

    Document what you’ve actually got. Not what you think you’ve got — what’s actually configured. OU filtering, which object types sync, Password Hash Sync settings, PTA and Seamless SSO config, every custom rule, directory extensions in use, group writeback, and anything tied to Exchange hybrid. I promise you this document will matter more during troubleshooting than during planning.

    Export your Connect Sync configuration. Use the built-in import/export settings feature before you change anything. It’s a five-minute job and it’s your safety net if something goes sideways.

    Check your authentication story separately from sync. This is genuinely good news, and it’s worth saying plainly: PTA and Seamless SSO are configured independently of the sync engine, so they keep working through the migration. Authentication is not the thing that breaks here. Sync scoping and attribute behaviour are.

    Get the provisioning agents deployed. Install them on supported servers ahead of time, and deploy at least two. This isn’t gold-plating — a single agent just recreates the single-point-of-failure problem you were trying to get away from.

    How to actually run the migration

    There’s one rule that matters more than any other: never sync the same objects through both engines at once. Microsoft is explicit that this isn’t supported, and I’ve seen what happens when someone tries it anyway — duplicate writes, confused attribute states, and a support case that takes far longer to unpick than the migration itself would have taken done properly.

    The way round this is scoping by OU. Cloud Sync takes ownership of specific OUs while Connect Sync keeps managing the rest, and you move the boundary a bit at a time.

    Phase 1 — Pilot. Pick a small OU: test users, test groups, non-production service accounts. Nobody important. Validate attribute flow, password sync, group membership, and general provisioning behaviour. Cloud Sync’s on-demand provisioning is genuinely useful here — you can trigger sync for one specific user and watch exactly what happens, rather than waiting for a scheduled run and hoping.

    Phase 2 — Configure Cloud Sync properly. Set up forest connectivity, OU scoping, attribute mappings, and Password Hash Sync. Don’t rush this bit — test it thoroughly before you let it anywhere near a production OU.

    Phase 3 — Put Connect Sync into staging mode. This is the checkpoint that matters most. Staging mode lets Cloud Sync take over as the active engine while Connect Sync stays configured and ready as a rollback path. Before flipping anything live, check your object counts match, provisioning is behaving, group memberships are correct, and password sync is actually working — not just “looks fine at a glance.”

    Phase 4 — Widen the net. Move more OUs across once the pilot’s proven itself. Validate after every phase, watch sync health properly, and resist the temptation to move everything at once because the pilot went smoothly. It always looks easy until the OU with the awkward legacy group turns up.

    Phase 5 — Cut over fully. Once everything’s migrated, check sync health, confirm provisioning, verify authentication is still solid, and go through the provisioning logs properly. Only decommission the old Connect Sync infrastructure once you’re genuinely confident, not just hopeful.

    Where people actually get burned

    Splitting related objects across two engines. This is the mistake I see most often in staged migrations — users move to Cloud Sync while their groups stay on Connect Sync, or vice versa. The two engines don’t share an understanding of object relationships, so group memberships start behaving oddly in ways that are genuinely painful to debug afterwards. Move related objects together. Users and their groups go in the same phase.

    Assuming feature parity that doesn’t exist. Organisations that have been running Connect Sync for years have usually accumulated a fair bit of custom logic nobody fully remembers building. Go through your custom attribute flows, sync rules, device sync requirements, and group writeback dependencies properly before you commit to a date. Not everything has a direct equivalent in Cloud Sync, and finding that out mid-migration is a bad time to find it out.

    Testing the pilot too lightly. “It provisioned a test user” is not a pilot. A proper pilot covers password changes, group membership updates, attribute updates, anything Exchange-related, and joiner/mover/leaver scenarios. Those last three are where the real-world mess lives — a user changing department, a contractor’s account being disabled, someone getting rehired eight months later. If your pilot doesn’t touch those, it hasn’t actually told you much.

    Is it worth doing?

    Yes, generally — but on a timeline that matches your actual complexity, not the one a vendor slide deck implies.

    If you’re running straightforward user and group sync, this is a genuinely quick win, and honestly one of the more satisfying migrations to run: less infrastructure, less patching, less 2am paging.

    If you’ve got Hybrid Azure AD Join dependencies, heavy custom sync rules, or a large or complex environment, take the time upfront. Do the readiness assessment properly. Run a pilot that actually tests the edge cases, not just the happy path.

    Move in phases, validate at every step, and keep Connect Sync as your safety net until you’re actually confident — not just optimistic. That’s the difference between a migration that goes quietly and one that ends up as a war story at the next conference.

  • Intune Enterprise Application Management: is it actually worth the hype? 

    Microsoft quietly folded several Intune Suite features into Microsoft 365 E5 licensing a while back, and most customers I speak to still haven’t noticed. I covered the wider Intune Suite changes in a previous post. This time I want to focus on the one that’s changed how I deploy applications day to day: Enterprise Application Management, or EAM. 

    If you manage endpoints for a living, application packaging is probably the job you complain about most. Not because it’s difficult, but because it’s relentless. You package Chrome, it updates. You package Adobe Reader, it updates. You blink, and half your estate is running something with a CVE against it. EAM is Microsoft’s attempt to take that grind off your plate, and having run it in a few production tenants now, I think it’s one of the more genuinely useful things to land in Intune in a while. 

    What EAM actually is 

    Strip away the marketing, and EAM is a Microsoft-curated app catalogue sitting inside Intune. Instead of you sourcing an installer, building a Win32 package, writing detection rules and testing an uninstall string, you pick the app from the catalogue and Microsoft has already done that work for you. 

    It covers the usual suspects: Chrome, Firefox, Zoom, 7-Zip, Notepad++, Webex, Power BI Desktop, and a growing list of others. Microsoft owns: 

    • Onboarding the app into Intune 
    • Keeping the deployment package current 
    • Version tracking and supersedence 
    • Security patching as new releases land 

    None of this is new in concept. Third-party patching tools have existed for years. What’s different is that it’s built into Intune itself, with no extra agent and no extra console to log into. 

    Why this problem needed solving 

    A typical Win32 deployment in Intune looks something like this: get the installer, wrap it, write install and uninstall commands, build detection logic, set requirement rules, test it, deploy it, then repeat every time the vendor ships an update. For an internally built line-of-business app, fine, you only do that occasionally. For Chrome, which ships a new version roughly every month, it’s a treadmill. 

    Now multiply that across a realistic estate. Most organisations I work with are running something close to this list on every device: 

    • Adobe Acrobat Reader 
    • Notepad++ 
    • 7-Zip 
    • Google Chrome 
    • Mozilla Firefox 
    • Zoom 
    • VLC Media Player 
    • Cisco Webex 
    • Power BI Desktop 

    Every single one of those is a live update problem and, if it falls behind, a live security problem. That’s the bit EAM is aimed at, and it’s the right bit to aim at. 

    Setting one up 

    This is genuinely one of the least painful parts of the Intune admin experience. Go to Apps, All Apps, Add, and choose Enterprise Application Catalogue App. Search the catalogue, pick your application, and Intune builds the deployable object for you. 

    From there you’re just doing the normal admin work: assignments, availability, scope tags, notification behaviour, restart grace periods. No packaging, no detection scripting, no fiddling with silent install switches at 6pm on a Friday because the vendor changed them again. 

    Automatic updates, and how they actually behave 

    This is the feature that matters most, in my view. When Microsoft refreshes a catalogue app, the package and metadata update behind the scenes, and you choose whether new versions roll out automatically or wait for your review. 

    I’d push back gently on going fully automatic for everything, everywhere, on day one. I’ve seen a vendor update break a plugin dependency in the wild, and if you’ve gone fully hands-off you find out from your service desk instead of from testing. Automatic updates for browsers and utilities, yes. A short pilot ring for anything with real business dependencies, always. 

    Why security teams should care 

    A large share of the exploited vulnerabilities I see in incident reviews aren’t in Windows itself. They’re in the browser, the PDF reader, the compression tool, the conferencing client — the applications nobody thinks about until they’re on a CVE list. Keeping that layer current is one of the highest-leverage things you can do for your attack surface, and it’s also one of the most neglected, because it’s tedious. 

    EAM won’t fix a badly configured firewall or a weak identity story, but it closes a gap that gets exploited constantly: known-vulnerable, unpatched third-party software sitting on end-user devices for months because nobody got around to repackaging it. 

    It also ties in cleanly with things security teams already care about, without needing a separate project to justify it: 

    • Microsoft Defender Vulnerability Management remediation 
    • Cyber Essentials Plus and ISO 27001 patching requirements 
    • Zero Trust principles around reducing attack surface and removing unsupported software 

    If your vulnerability management reports keep flagging the same handful of outdated applications every month, EAM is the practical fix, not another policy document. 

    Supersedence: don’t skip this part 

    EAM plugs into Intune’s supersedence engine, which lets you retire old versions cleanly as new ones roll in — upgrading Adobe Reader builds, moving Chrome Enterprise channels along, that sort of thing. 

    Set this up properly. I’ve been into more than one tenant where three generations of the same application were all still assigned, because nobody ever went back and cleaned up the old packages after EAM took over. Write down what’s approved, what version is current, and when old packages get retired. EAM does the mechanical work; someone still has to own the decisions. 

    Keep an eye on it — don’t deploy and forget 

    Deployment is the easy part. The bit people skip is watching whether it actually worked. Inside Intune, check install status by device and by user, and keep an eye on your application assignment and endpoint analytics reports. 

    As a rule of thumb, I want deployment success sitting comfortably above 95%, and I want to know immediately if a particular vendor’s installer starts failing more often than the others — that’s usually the first sign something’s changed upstream. Track update compliance and flag devices still on unsupported versions. None of this is glamorous, but it’s what turns EAM from a nice demo into something you can actually stand behind in an audit. 

    EAM and Autopilot: a genuinely good pairing 

    If you’re provisioning devices through Windows Autopilot, EAM applications fit in well. Devices enrol, catalogue apps install automatically, and updates carry on being managed after the fact without you touching the build again. 

    Browsers, PDF readers, collaboration tools, remote support software, core productivity apps — these are the categories I’d put through EAM first in a new build. It cuts real time out of provisioning and takes ongoing maintenance off the image entirely. 

    A few things I’d tell any team starting out with EAM 

    Start with your worst offenders 

    Don’t onboard everything at once. Start with the applications that update most often and sit on the most devices — usually browsers and PDF readers. That’s where the effort saved is highest. 

    Run update rings, same as Windows Update 

    Pilot, IT team, early adopters, then everyone else. It’s an extra bit of process, but it means a bad vendor update hits ten machines, not ten thousand. 

    Work with your vulnerability management team, not around them 

    Let Defender Vulnerability Management findings tell you which applications to prioritise for automated maintenance. It’s a better prioritisation signal than guesswork. 

    Retire the old Win32 packages 

    Once an EAM version is validated, get rid of the legacy package. Running both indefinitely just creates confusion about which one is actually in control of a given device. 

    Watch the deployment reports, weekly if you can 

    Installation failures, version compliance, update success rate. If nobody looks at these, you won’t know EAM has quietly stopped working for a subset of devices until someone complains. 

    Pilot everything, even Microsoft’s own packages 

    Microsoft maintaining the package doesn’t mean the vendor’s update can’t still break something on your estate. Test before you push wide, the same as you would with anything else. 

    Where EAM won’t help you 

    It’s not a replacement for proper Win32 packaging, and Microsoft hasn’t pitched it as one. Line-of-business applications, custom internal software, anything needing heavy customisation or vendor-specific install parameters, and legacy software with awkward dependencies — that’s still manual packaging territory. 

    A mature Intune environment ends up running both approaches side by side. That’s not a shortcoming of EAM, it’s just the reality of enterprise application estates: some things are common enough for Microsoft to maintain centrally, and some things are yours to own. 

    Where I land on this 

    Enterprise Application Management is one of the more immediately useful things E5 customers have picked up recently, and it doesn’t need a big project plan to start getting value from it. Hand the packaging and update treadmill to Microsoft, and your team gets time back for governance, security work, and the things that actually need a human making a judgement call. 

    For security-minded organisations specifically, the win isn’t really convenience — it’s exposure. Fewer outdated applications sitting on endpoints means fewer easy wins for an attacker, better numbers in your vulnerability reports, and a stronger story for Cyber Essentials Plus, ISO 27001, or whatever framework you’re being measured against. 

    Pair it with Windows Autopilot and Defender, get your reporting discipline right, and EAM stops being a nice-to-have feature and starts being a genuine part of how you keep an estate current at scale. I’d rather spend my time on that than repackaging Chrome for the fortieth time this year. 

  • Cloud PKI in Microsoft Intune: Finally, Certificates Without the On-Prem Headache

    In my last post, I talked about how a chunk of what used to live only in the Intune Suite has quietly become part of standard Microsoft 365 E5 licensing. Cloud PKI is, for my money, one of the best of that bunch.

    If you’ve ever built or inherited an AD CS environment, you’ll know exactly why.

    The problem with “proper” PKI

    PKI has underpinned enterprise security for decades. Certificate-based Wi-Fi, VPN, device trust — none of it works without a CA somewhere issuing and revoking certs.

    The trouble has always been the “somewhere”. Traditional PKI means servers, patching, backups, disaster recovery plans, and usually at least one person who quietly dreads what happens if the CA falls over.

    I’ve sat in more than one post-incident review where the root cause traced back to an expired intermediate certificate nobody was watching. It’s rarely glamorous, but it’s exactly the kind of thing that takes down authentication for an entire site.

    Microsoft Cloud PKI is Microsoft’s attempt to take that operational weight off your plate and hand it back as a managed service inside Intune.

    What it actually is

    Cloud PKI is a certificate authority service that lives in Intune. You create root and issuing CAs, build certificate profiles, and push certificates to managed devices — no AD CS servers, no NDES box, no Certificate Connector sitting on a VM somewhere quietly getting forgotten about.

    It covers the usual certificate workloads: Wi-Fi, VPN, device identity, user identity, and the passwordless and phishing-resistant scenarios everyone’s chasing at the moment.

    Why this matters more than it might look

    On paper it’s “PKI, but cloud”. In practice, it removes an entire category of infrastructure risk.

    Every NDES server I’ve come across has been a bit of a soft spot — internet-facing, fiddly to patch, and rarely high on anyone’s priority list until something goes wrong. Cloud PKI takes it out of the equation entirely.

    That matters for organisations trying to shrink their on-prem footprint generally, not just for PKI specifically. Fewer servers means fewer things that can be misconfigured, fewer patch cycles, fewer 2am calls.

    How the hierarchy works

    Cloud PKI keeps a structure that’ll feel familiar if you’ve worked with PKI before: a root CA, with one or more issuing CAs underneath it.

    Microsoft hosts and manages the root — you control issuance policy and trust. Issuing CAs handle the day-to-day work of actually issuing certificates, and you can create more than one to split things by business unit, environment, region, or use case.

    It’s the same design thinking as an on-prem PKI hierarchy, minus the servers.

    What you actually gain

    A few things stand out to me.

    Automated lifecycle management is the big one. Renewal, revocation, issuance — all policy-driven. Expired certificates are one of the most avoidable causes of outage in enterprise IT, and this genuinely helps close that gap.

    It’s also just… in Intune. Creating CAs, building profiles, assigning them, checking status, revoking — all in the same console you’re already living in. If you’re an Intune admin, there’s very little new to learn here, which isn’t something I say about many Microsoft security features.

    And there’s the obvious security upside of certificate-based authentication over passwords: stronger device identity, harder to phish, and a genuine step towards passwordless.

    Where I’d actually use it

    Wi-Fi and VPN authentication are the obvious wins — push a certificate, users connect without ever seeing a credential prompt. I’ve seen how much support-desk noise disappears once Wi-Fi stops relying on users typing passwords correctly.

    Device authentication for Conditional Access is the other one worth calling out — proving a device is what it claims to be before it gets anywhere near corporate resources.

    Fitting into Zero Trust

    Microsoft frames Zero Trust as verify explicitly, use least privilege, and assume breach. Certificates are a genuinely useful tool for the first of those — they give you cryptographic proof of identity, not just a password someone typed correctly.

    Put it together with Entra ID, Conditional Access, Intune compliance policies, and Defender for Endpoint, and you get something like this: a device enrols, Cloud PKI issues it a certificate, the device becomes compliant, Conditional Access checks compliance and identity, and access is granted only to trusted users on trusted devices.

    None of these pieces are new individually. What Cloud PKI does is make the certificate piece far less painful to stand up — which means more organisations will actually bother.

    Before you migrate

    I wouldn’t rip out an existing AD CS estate overnight, and I don’t think Microsoft expects anyone to either.

    Worth checking before you commit: smart card requirements, any legacy applications tied to specific certificate templates, third-party network kit expecting a particular CA, and anything regulatory that dictates where and how your CA has to be hosted.

    Most organisations I’ve spoken to are running Cloud PKI alongside their existing PKI for a while, migrating workload by workload rather than in one go. That’s the sensible approach.

    Is it worth it?

    If you’re already on Microsoft 365 E5, Cloud PKI is effectively sitting in your tenant right now, unused. That alone makes it worth a look.

    More importantly, it removes one of the genuine, longstanding blockers to doing certificate-based authentication properly: the infrastructure overhead. I’ve watched plenty of good security initiatives stall because nobody wanted to own another CA server. This takes that excuse away.

    It’s not going to replace every PKI deployment overnight, and it shouldn’t. But if you’re building out Wi-Fi, VPN, or device-identity scenarios and haven’t looked at Cloud PKI yet, it’s a genuinely worthwhile half hour of your time.

  • Deploying Microsoft Intune Endpoint Privilege Management: What Actually Works

    Most organisations I work with have been chasing least privilege for years. Strip out local admin rights, shrink the attack surface, limit what a compromised account can do. All good instincts.

    The trouble is what happens on Monday morning when someone genuinely needs to install a printer driver or run an update that insists on admin rights. That’s the gap EPM was built to close.

    Microsoft Intune Endpoint Privilege Management (EPM), part of the Intune Suite and now part of Microsoft 365 E5, lets standard users run specific approved things with elevated rights—on demand, for that one task, without ever making them a local admin. No more, no less.

    This is the deployment playbook I use with clients: how EPM actually works under the hood, how to roll it out without a support desk meltdown, and the configuration choices that separate a good deployment from one that just moves the risk around.

    What EPM actually does

    EPM elevates specific applications, scripts, installers and processes. The user stays a standard user throughout. That distinction matters more than it sounds — you’re not granting a person more power; you’re granting a process more power, for as long as it needs it.

    Under the hood, EPM policies decide:

    • Which applications are allowed to elevate
    • Who is allowed to trigger that elevation
    • Whether the user has to explain why
    • Whether someone else has to approve it first
    • Whether it happens automatically or on request
    • What gets logged when it does

    Get this right, and you’ve got Zero Trust in practice rather than Zero Trust as a slide in a deck.

    The architecture, briefly

    Three pieces do the work:

    The EPM service sits in the cloud, bolted onto Intune. It manages policy and reporting.

    The Intune Management Extension (IME) is the bit already running on your endpoints that pulls those policies down.

    The EPM client components sit on the device itself, evaluating each elevation request as it happens.

    When someone launches something that needs admin rights, EPM checks it against your rules, decides whether to allow it, runs that one process elevated if approved, and ships the audit trail straight back to Intune. The user’s session itself never changes. Only the process does.

    Licensing — check this before you get excited

    EPM needs one of the following sitting on every user you want covered:

    • Microsoft 365 E5
    • Microsoft Intune Suite
    • The Intune EPM add-on

    It works on Windows 10 and 11, on Entra-joined or Entra hybrid-joined devices. Devices need to be enrolled in Intune with the Management Extension installed — if that’s not already ticking along on your estate, sort that first.

    I’ve seen more than one EPM pilot stall for a fortnight because nobody checked licensing coverage until after the policies were built. Do this bit first.

    Plan before you configure anything

    Here’s the mistake I see most often: someone gets excited about EPM, builds a few elevation rules based on gut feel, and rolls it out. Three weeks later, the helpdesk is drowning in tickets because nobody actually knew what needed admin rights in the first place.

    Before touching a policy, find out what’s actually elevating today. Look at:

    • Line-of-business applications with dodgy installers
    • Legacy software that’s never been rewritten to behave
    • Update mechanisms that insist on admin rights for no good reason
    • Device management and monitoring tools
    • Developer toolchains
    • Anything bespoke and internal

    Microsoft Defender for Endpoint and advanced hunting queries are genuinely useful here — they’ll show you real elevation attempts rather than what you assume is happening. Your existing software deployment reports are worth a look too.

    This discovery phase is unglamorous, and it’s the single biggest predictor of whether the rollout goes smoothly.

    Roll it out in phases — don’t be a hero

    A big-bang EPM deployment across the whole estate is asking for trouble. I always recommend three phases.

    Phase 1 — Discovery. A small pilot group: IT admins, security team, application owners, a few power users. Use them to work out what your elevation scenarios actually look like before anyone else sees a prompt.

    Phase 2 — Controlled pilot. Push EPM to a limited slice of real production users. Watch the user experience closely, check application compatibility, make sure reporting and audit events are landing where you expect.

    Phase 3 — Enterprise rollout. Expand in waves — by department, device type, region, risk profile, whatever makes sense for your organisation. Waves, not one big switch.

    Configuring EPM

    Step 1 — Turn it on. In the Intune admin centre, go to Endpoint Security → Endpoint Privilege Management, enable it, and assign the policy to the device groups you actually mean to target.

    Step 2 — Build your elevation settings policy. This is where you decide how elevation feels for the user. There are four flavours:

    Automatic elevation — the app elevates automatically, with no prompt. Fine for trusted business apps and standardised, well-understood tools. I wouldn’t reach for this outside of software you genuinely trust without question.

    User confirmed elevation — a prompt the user has to accept. Good for the odd admin task and medium-risk tools.

    User justification — the user has to type a reason before it elevates. This is where I’d put anything remotely sensitive — administrative utilities, security tooling, that sort of thing. The justification text is more useful than people expect when you’re investigating something later.

    Approval required — someone else has to say yes first. Reserve this for your genuinely high-risk admin tools and privileged maintenance work. It’s friction, and friction is the point.

    Elevation rules — how you identify what’s allowed to run

    Three ways to match an application, each with a real trade-off.

    File hash. The most secure option, full stop. Nothing gets through unless it’s the exact binary you approved. The catch is maintenance — every update means a new hash, so this works best for tools that don’t change often, like dedicated security utilities.

    File certificate. Matches on the publisher’s signing certificate rather than the exact file. Much less maintenance, and it survives normal software updates without you lifting a finger. The trade-off is you’re trusting the publisher more broadly, so this is best kept for Microsoft software and vendors you genuinely trust.

    File path. Matches on where the file lives. It’s the easiest to set up and, frankly, the one I’d avoid wherever possible — a folder path is trivial to abuse if an attacker can drop something into it. Use this only when hash or certificate matching genuinely isn’t an option.

    Configuration choices that actually matter

    1. Remove local admin rights first

    EPM isn’t meant to sit alongside widespread local admin access — it’s meant to replace it. If you deploy EPM but leave half your estate with standing admin rights, you’ve added a control without removing the risk it was meant to address. Pull permanent local admin memberships where you can, bring in proper privileged access management, and use EPM to handle the genuine exceptions.

    2. Lean on certificate rules

    For most enterprise software, certificate-based rules give you the best balance of security and sanity. Avoid broad path-based rules altogether, and think twice before going hash-only on anything that updates frequently — you’ll be maintaining that rule forever.

    3. Make people justify PowerShell, CMD, and friends

    PowerShell, Command Prompt, Registry Editor, Device Manager, MMC snap-ins — require justification and full audit logging on all of them. When something goes wrong later, having a written reason attached to every elevation is genuinely useful, not just a box-ticking exercise.

    4. No wildcard rules. Ever.

    Don’t allow entire folders or generic paths to elevate. C:\Temp\*, Downloads folders, user profile directories — these are exactly where an attacker would drop a payload, and a wildcard rule hands them the keys. If you find yourself writing a wildcard to save time, that’s the moment to stop and find the specific rule instead.

    5. Wire it into Microsoft Defender for Endpoint

    Defender gives you visibility into elevated process execution, incidents and investigations that EPM alone won’t show you. Your security team should correlate EPM events with endpoint telemetry, not treat them as two separate data sets.

    6. Use RBAC properly

    Don’t let one team own policy creation, application approval and reporting all at once. Split those responsibilities through Intune’s role-based access control. It’s a small thing that meaningfully reduces the risk of someone quietly approving their own elevation request.

    7. Time-limit your approvals

    If you use approval workflows, require a business reason, cap how long the approval lasts, and review them regularly. Elevation that never expires isn’t really elevation — it’s just admin rights with extra steps.

    8. Audit everything, properly

    Capture elevation requests, approvals, justifications, elevated launches and policy matches. Keep that data for as long as your security policy requires. When an incident happens, this data tells you what actually ran and why.

    Keep watching after go-live

    EPM deployments don’t finish at go-live — that’s when the real work starts. Review regularly:

    • Which applications are being elevated most
    • Failed elevation attempts
    • Approval requests coming through
    • What people are writing in the justification field
    • Any device generating unusually high elevation activity

    A sudden spike in elevation activity is worth investigating properly. It might just be a new tool rolling out, or a training gap, but it might also be someone poking around where they shouldn’t be. Treat it as a signal, not noise.

    EPM isn’t the whole story

    EPM meaningfully reduces risk compared with handing out local admin rights, but don’t mistake it for a complete security control. It’s one layer.

    Pair it with Microsoft Defender for Endpoint, Attack Surface Reduction rules, Application Control for Business (the WDAC rebrand), Conditional Access, Privileged Identity Management, security baselines and device compliance policies. Together, that’s a layered defence that actually earns the label Zero Trust rather than just borrowing the phrase.

    Mistakes I see again and again

    • Migrating everyone at once instead of phasing it
    • Leaning too hard on path-based rules because they’re quick
    • Skipping the discovery phase and finding out what needs elevation the hard way
    • Not monitoring elevation events once the policy is live
    • Handing out approval permissions too broadly
    • Letting developers elevate whatever they like, whenever they like
    • Treating EPM as a substitute for proper application control rather than a companion to it

    Fix these early, and the rest of the deployment tends to look after itself.

    My Final thoughts

    Of everything in Intune, EPM is one of the controls I’d genuinely encourage every organisation still running local admin rights to look at seriously. It lets you get rid of standing admin access without users feeling like they’ve been locked out of doing their jobs — which, in my experience, is usually the thing that kills these projects before they start.

    The deployments that go well share the same pattern: proper discovery up front, a phased rollout, sensible governance, and monitoring that doesn’t stop once the project’s marked complete. Pair EPM with Defender for Endpoint, Application Control and your wider Zero Trust controls, and it becomes a genuinely load-bearing part of your endpoint security strategy — not just another policy nobody looks at again.

    If you’re still sitting on widespread local admin rights, EPM is a practical, well-trodden way to start taking that away — without your users noticing much difference to how they work.

  • Microsoft 365 E5 Just Got Considerably More Useful for Endpoint Security

    If you’re running Microsoft 365 E5, go and check your tenant. There’s a good chance you’re now licensed for tools you’ve been meaning to buy for the last two years.

    As of July 2026, Microsoft has folded several premium Intune Suite capabilities directly into E5 licensing, no add-on required. I’ve been doing endpoint security work in this space for a while, and this is the kind of license change that quietly changes project priorities. It’s not flashy, but it matters.

    Microsoft’s own announcement covers the details here and here. This post is my take on what actually matters to the people who have to implement it.

    Why This Actually Matters

    Endpoint management used to mean pushing out policies and calling it a day. That’s not the job any more.

    Security teams are now expected to strip out admin rights, secure a workforce that’s half at home and half in the office, get off ageing certificate infrastructure, and actually see what’s happening across their device estate — usually with the same headcount they had five years ago.

    Microsoft including these capabilities in E5 by default tells you where they think endpoint security sits now: not as a nice-to-have bolt-on, but as core Zero Trust capability. I’d agree with that read.

    What You Actually Get

    Microsoft 365 E5 already included everything in E3. Now it also picks up a set of Intune Suite features that used to need separate licensing.

    Rolled in from the E3 side:

    • Intune Remote Help
    • Intune Advanced Analytics
    • Intune Plan 2
    • Microsoft Tunnel for Mobile Application Management

    New on top for E5 customers specifically:

    • Endpoint Privilege Management (EPM)
    • Microsoft Cloud PKI
    • Enterprise Application Management (EAM)

    Let’s go through each one, because a bullet list doesn’t tell you why you’d care.

    Endpoint Privilege Management: the one I’d deploy first

    This is the headline feature, and honestly, it’s the one I’d tackle first if I were prioritising a rollout.

    Every environment I’ve worked in has the same story: users get local admin because taking it away breaks something, or generates a wave of helpdesk tickets nobody has time for. And every environment I’ve worked in also knows that standing admin rights are one of the easiest wins for a ransomware operator or anyone else trying to move sideways through a network.

    EPM gives you a middle ground. Users stay standard users day to day. Specific approved applications can run elevated. Elevation can be just-in-time rather than permanent, governed by rules you control, and every elevation event gets logged.

    In practice, that means an engineer doesn’t need full local admin just to run Wireshark or SQL Server Management Studio. You allow those specific tools to elevate, and the rest of the machine stays locked down. It’s the least-privilege principle without the political fight of ripping admin rights away wholesale.

    Microsoft Cloud PKI: retire the certificate server nobody wants to touch

    Every organisation I’ve walked into that still runs on-premises Certificate Authorities is running them for the same handful of reasons: Wi-Fi authentication, VPN authentication, and device or user certificates.

    And every one of those CAs comes with the same baggage — infrastructure to patch and maintain, certificate lifecycles someone has to track manually, high-availability requirements, and the quiet risk of a CA server nobody’s touched a security update on in eighteen months. You know the one.

    Cloud PKI moves certificate issuance, renewal, and revocation into Intune, hosted by Microsoft. For anyone genuinely trying to get off legacy infrastructure rather than just talking about it, this is a real opportunity to switch off that server room CA for good.

    Enterprise Application Management: less time repackaging Win32 apps

    Packaging and maintaining Win32 applications is unglamorous work, and it eats far more admin time than it should.

    Test the update, repackage it, redeploy it, repeat next month. Most endpoint teams have at least one person who spends a disproportionate chunk of their week on exactly this.

    EAM pulls from Microsoft’s own catalogue of pre-packaged, kept-current applications, so a good chunk of that churn disappears. For an organisation managing a few thousand endpoints, that’s not a minor convenience — it’s hours back every week and users getting patched software faster.

    Intune Advanced Analytics: fewer surprises from the helpdesk

    Visibility is still where most endpoint management falls down. You usually find out a device is struggling when the user rings the helpdesk, not before.

    Advanced Analytics gives you device performance, endpoint health, user experience and app reliability data, and Microsoft has recently added near real-time device queries, Multi-Device Query, and AI-assisted analytics through Security Copilot.

    The practical upshot: you can spot a device that’s about to have a bad boot time, or an app that’s crashing across a subset of your estate, before it turns into forty tickets. That’s the difference between reactive firefighting and actually running the environment.

    Intune Remote Help: support without a third-party tool

    Remote support tooling is one of those things everyone has, and almost everyone has bolted on from a third party with its own login, its own audit trail, and its own gaps.

    Remote Help sits inside the Microsoft security stack instead — Entra authentication, role-based access, compliance-aware access, and every session logged and auditable. For hybrid teams, that’s one fewer vendor relationship and one fewer audit trail to reconcile at year end.

    Intune Plan 2: the frontline and specialty device stuff

    If your estate is all corporate Windows laptops, this section won’t excite you much. If you’ve got shared devices, rugged Android handhelds, or Zebra scanners on a warehouse floor, it will.

    Plan 2 covers specialty and shared device management, stronger Android controls, and Zebra firmware update management. Retail, logistics, manufacturing and healthcare environments tend to get the most out of this — it’s the difference between managing frontline devices properly and managing them by exception.

    Microsoft Tunnel for MAM: BYOD without full enrolment

    BYOD is still a genuine headache. Users don’t want their personal phone fully enrolled and managed, and honestly, I don’t blame them.

    Tunnel for MAM gives you per-app VPN access to internal resources without requiring full device enrolment, so corporate data stays protected without Microsoft — or you — needing visibility into someone’s personal photos and apps. It’s a reasonable compromise, and one that tends to get much less pushback from users than full MDM enrolment.

    Security Copilot: still separately licensed, but worth watching

    Security Copilot itself isn’t part of this bundle — that’s a separate licence — but Microsoft keeps deepening the integration with Intune: natural language queries against Intune data, AI-assisted KQL generation, risk scoring for EPM elevation requests, and vulnerability remediation guidance.

    I’d treat this as a direction of travel rather than a reason to buy anything today. Microsoft is clearly building towards AI-assisted administration as a standard part of endpoint management, not a novelty. Worth keeping an eye on, not worth rushing into.

    What This Means If You’re Already on E5

    If you’re already licensed for Microsoft 365 E5, none of this requires a procurement conversation. It requires a deployment plan.

    Realistically, that means:

    • Turning off standing local admin rights via EPM
    • Planning the retirement of your legacy on-premises CA
    • Cutting down repackaging effort with EAM
    • Actually using the visibility Advanced Analytics gives you
    • Consolidating remote support onto Remote Help

    In my experience, a lot of organisations already own tooling they’ve never turned on. This is a good example — Intune Suite used to be viewed as a nice-to-have upsell, and many teams quietly filed it under ‘later’. For a lot of E5 customers, later is now.

    My Final Thoughts

    This is one of the more significant endpoint licensing changes I’ve seen in a while, and it didn’t get nearly enough attention when it landed.

    Bundling EPM, Cloud PKI, EAM, Advanced Analytics, Remote Help and the rest into E5 makes genuinely enterprise-grade endpoint management accessible to organisations that would previously have had to build a business case for every one of these separately.

    If you’re working towards Zero Trust and you’re already on E5, this is worth an afternoon of your time. Go and check what you’re actually entitled to before you plan your next quarter — I’d put money on there being at least one capability in here you’re already paying for and not using.

  • Securing AI in Microsoft Cloud Tenants: What Actually Matters

    AI is everywhere in the Microsoft stack now. Copilot for Microsoft 365, Copilot Chat, Azure OpenAI, Fabric, Security Copilot, custom agents built in Azure AI Foundry.

    Pick almost any client, and at least one of these is either live or “under evaluation.” In my experience, “under evaluation” usually means someone in finance has been using it for three months already, and nobody in IT knows.

    Here’s the bit nobody wants to hear: AI doesn’t introduce a brand-new category of security problem. It shines a very bright light on the mess that was already there.

    Identity, permissions, data governance. If your tenant was leaky before Copilot arrived, Copilot will find the leak for you. Faster and more thoroughly than any auditor ever could.

    So “securing AI” isn’t really a separate project. It’s getting the tenant right first, then switching AI on. Do it the other way round, and you’re just automating your existing problems, at speed.

    What you’re actually worried about

    Strip away the marketing language and the concerns are pretty consistent across every client I’ve worked with:

    • Oversharing of sensitive information
    • Confidential data turning up somewhere it shouldn’t
    • Unauthorised access surfaced through AI-generated answers
    • Data leaking out through prompts and outputs
    • Shadow AI — people using tools nobody signed off on
    • Prompt injection
    • Data poisoning
    • Excessive permissions sitting quietly in Microsoft 365
    • Unmanaged AI apps connecting to corporate data
    • Regulatory exposure

    Nine times out of ten, when I go digging, it’s the same story. Copilot didn’t create a new vulnerability. It just surfaced a permissions problem that’s been sitting there for years.

    If someone has access to a SharePoint site, a Teams channel or a OneDrive folder, Copilot can potentially pull that content into an answer. It’s not being clever or malicious. It’s just doing exactly what it was given permission to do.

    Which gets you to the one line worth remembering out of this whole post:

    AI can only protect data as well as the permissions protecting that data already do.

    Everything else is detail.

    Build the foundation before you flip the switch

    Before any AI service goes near production data, get the basics solid.

    Identity first. It’s still the primary boundary, AI or not. Conditional Access, MFA everywhere, phishing-resistant MFA for admins, Privileged Identity Management, Identity Protection risk policies, Continuous Access Evaluation.

    None of this is new advice. It’s the same list I’ve been giving clients for years. AI just raises the stakes if you get it wrong.

    Concretely: MFA for every user. Preferably phishing-resistant MFA where possible. Legacy authentication blocked outright. Device compliance enforced. Access from risky locations restricted.

    Skip this step, and AI just becomes another door for an attacker to walk through with a stolen password.

    Data protection is the control that actually matters most. Microsoft’s AI services respect the permissions and labels you already have in place. Which is good news, but only if those permissions and labels are worth respecting.

    Get Purview Information Protection properly configured — Public, Internal, Confidential, Highly Confidential — and make the labels do something, not just sit there as metadata. Encrypt content, restrict sharing, apply markings, block downloads where it matters, control external access.

    Before you switch anything on, use Purview Data Map and Data Classification to find out where your personal data, financial records, IP, source code and customer data actually live. You cannot protect what you haven’t located.

    And tidy up your data lifecycle while you’re at it. Retention labels, retention policies, records management, deletion schedules. Less stale data lying around means less for AI to accidentally expose.

    This is unglamorous work, and it’s exactly the kind of thing that gets deprioritised until it causes an incident.

    Securing Microsoft 365 Copilot specifically

    Copilot is usually the first AI service through the door. Because it reads organisational content directly, permissions become the whole ballgame.

    Run a proper permission assessment before deployment: SharePoint permissions, OneDrive sharing, Teams memberships, Microsoft 365 Groups, external sharing settings.

    I have never once done this exercise for a client and come away empty-handed. There’s always an “Everyone” permission somewhere. An overshared library nobody remembers creating. Guest access granted for a project that ended two years ago. A Teams membership list that’s basically a company history lesson.

    Fix these before Copilot goes live, not after.

    Target SharePoint oversharing specifically—anonymous links, “Anyone” links, legacy sharing settings, broad access groups. SharePoint Advanced Management, Purview and Access Reviews will all help you find the excessive access. Use them together rather than relying on one.

    Then configure Copilot itself through the Microsoft 365 Admin Centre, Purview and Entra ID: control which groups get Copilot, monitor usage, apply DLP policies, and restrict plugins and connectors where you need to.

    On connectors specifically, treat every one as a new data source, because that’s exactly what it is. Check the permissions, who owns the underlying data, the access scope and the sensitivity of what’s exposed.

    Only turn on connectors you’ve actually assessed. “We’ll review it later” is how shadow data sources happen.

    Purview as the backbone of AI governance

    If there’s one platform I’d tell you to invest in properly, it’s Purview. It sits underneath almost every other control in this post.

    Set up DLP policies for financial data, personal information, healthcare records, IP and source code. Apply them across Microsoft 365, Teams, SharePoint, Exchange, and Copilot interactions. This is what stops sensitive information from leaking out through an AI conversation rather than an email.

    Use Insider Risk Management to watch for the patterns AI can accelerate — data exfiltration, unusual access, mass downloads, access to sensitive files. AI doesn’t create insider risk, but it can make an insider a lot faster.

    And use Communication Compliance to monitor prompt content, user interactions, and policy violations. This matters more the more regulated your industry is. I’d treat it as close to mandatory in financial services or healthcare.

    Locking down Azure OpenAI

    Plenty of organisations are building custom AI applications on Azure OpenAI. That’s a different conversation to Copilot, because you’re now responsible for the architecture, not just the configuration.

    Network security first: Private Endpoints, Azure Virtual Networks, Network Security Groups, Azure Firewall. Avoid public exposure wherever possible.

    The pattern I want to see is:

    Users → Application → Private Endpoint → Azure OpenAI

    Not:

    Users → Internet → Azure OpenAI

    That second pattern still turns up more often than it should.

    For authentication and authorisation, use Managed Identities, Entra ID authentication and RBAC. Shared keys, hardcoded credentials and overly generous permissions have no place here. And yes, I still find hardcoded keys in application code more often than I’d like to admit.

    Handle prompts properly: input validation, output filtering, prompt inspection, content filtering. This is your main defence against prompt injection.

    Turn on Azure AI Content Safety to catch harmful content, malicious prompts, offensive language and unsafe outputs. For anything customer-facing, I’d consider this non-negotiable.

    Prompt injection deserves its own section

    Prompt injection is the AI-specific threat that keeps coming up in client conversations, and for good reason. It’s genuinely new, genuinely tricky, and genuinely underestimated.

    It looks like this: “Ignore previous instructions.” “Reveal confidential information.” “Access hidden data.” Simple wording, sometimes buried inside a document the AI is asked to summarise rather than typed directly by a user.

    Mitigating it takes layers: strong system prompts, content filtering, retrieval validation, clear data access boundaries, and human approval for anything consequential.

    The rule I give every client is simple. Never assume an instruction generated by AI is trustworthy just because it came from AI. Validate before you act, every time.

    Zero Trust applies to AI too

    Microsoft has been banging the Zero Trust drum for years, and the same three principles hold up for AI without needing much translation.

    Verify explicitly — user identity, device health, location, risk signals, every time. Use least privilege — RBAC, PIM, Just-in-Time access, regular Access Reviews. Assume breach — monitor AI interactions, user behaviour, data access patterns and application activity as if something has already gone wrong, because eventually it will.

    Treat AI workloads as an attack surface, not as a trusted internal tool. That mental shift alone changes how a lot of these deployments get designed.

    Actually watching what’s happening

    None of the above matters if you can’t see it happening.

    Defender XDR gives you visibility over user activity, identity threats, endpoint risks and cloud application access.

    Defender for Cloud Apps is where you’ll find shadow AI, and I mean that literally. Every single engagement I’ve run this discovery exercise on has turned up employees using public AI tools nobody in IT knew about. It’s never zero.

    Feed AI logs into Microsoft Sentinel and monitor prompt activity, access events, authentication anomalies and data access behaviour. Set alerts for large-scale data access, unusual prompt activity, high-risk sign-ins and sensitive data exposure.

    If you’re not alerting on these, you’re relying on hope as a strategy.

    Governance is not optional paperwork

    Technical controls only get you so far. You need an actual governance framework sitting alongside them.

    Write an Acceptable Use Policy that says plainly which AI tools are approved, which use cases are off-limits, what the data handling rules are, and what’s expected of users.

    Run risk assessments — data sensitivity, regulatory obligations, business impact, security requirements — before a solution goes live, not as a retrospective exercise.

    The more mature organisations I work with have stood up an AI review board to look at new AI projects, risk assessments, data access requests and compliance questions before they get approved. It sounds bureaucratic. It saves an enormous amount of pain later.

    Don’t forget Security Copilot itself

    It’s easy to focus entirely on the AI tools users touch and forget that Security Copilot needs governing too.

    RBAC permissions, least privilege, audit logging and data access controls all apply here just as much as anywhere else. Keep an eye on prompt usage, generated outputs and analyst activity, and make sure Security Copilot is bolted into your existing security processes rather than left running as its own island.

    A sensible order to do all this in

    If you’re starting from scratch, this is roughly the sequence I’d follow:

    1. Secure identities with Entra ID and MFA.
    2. Implement Conditional Access policies.
    3. Classify and label sensitive data.
    4. Review SharePoint and Teams permissions.
    5. Implement DLP policies.
    6. Deploy Defender for Cloud Apps.
    7. Enable monitoring through Defender XDR and Sentinel.
    8. Pilot AI services with a limited group of users.
    9. Expand based on what the pilot and your governance process actually tell you.

    Follow that order, and you dramatically cut the chances of AI exposing risks you didn’t know about.

    My Final thoughts

    Securing AI in a Microsoft tenant comes down to securing identities, data and access. The same fundamentals that were true before Copilot existed.

    Yes, AI brings genuinely new threats like prompt injection and model abuse. But in practice, the biggest risks I see are still poor permissions, overshared content and weak governance. The AI just makes them visible faster.

    If you’ve already invested properly in Entra, Purview, Defender XDR, Sentinel and a Zero Trust approach, you’re in a good position for AI adoption. The hard part was never really “turn on Copilot” or “stand up Azure OpenAI.” It’s making sure the tenant underneath is ready for a world where AI is becoming the main way people interact with corporate information.

    The organisations that get this right are the ones treating AI as part of their existing security architecture, not as a bolt-on. Same rigour, same governance, same monitoring you already apply to identities, endpoints and data. Just extended to cover the newest thing sitting on top of them.

  • Deploying DLP in Microsoft Purview: What Actually Works

    Data protection sounds simple until you sit in front of the Purview admin centre with a blank policy and a business that hasn’t slowed down to wait for you. I’ve deployed DLP across enough tenants now to have opinions about what works and what quietly causes chaos six weeks later. Here they are.

    Don’t start with policies. Start with looking.

    The single most common mistake I see is someone jumping straight into policy creation before they’ve spent any real time in Content Explorer.

    You can’t protect what you haven’t found. Before you write a single rule, go and look at where sensitive data actually lives, who’s touching it, and how it’s currently being shared. Most of that sharing is legitimate. Some of it isn’t. You won’t know which is which until you look.

    Ask yourself the boring but essential questions:

    • Where does personal data actually sit?
    • Who in the business handles financial information day to day?
    • Is anything sensitive leaking out externally right now?
    • Which Teams or SharePoint sites are quietly holding regulated content nobody’s thought about?

    This discovery phase is unglamorous. It’s also the difference between a DLP programme people trust and one they route around.

    Get your labelling sorted first

    DLP on its own is decent. DLP paired with Purview Information Protection is genuinely useful.

    Roll out sensitivity labels, turn on auto-labelling for existing content, and use mandatory labelling with inheritance where it makes sense. A typical label set looks something like Public, General, Confidential, Highly Confidential, and Highly Confidential – Restricted.

    Once labels are in place, your DLP policies get a lot smarter. Instead of relying purely on pattern matching, you can build conditions around the label itself. A policy blocking anything marked “Highly Confidential” from leaving the tenant doesn’t care whether the content matches a regex — it just knows the label says no.

    Custom Sensitive Information Types are worth the investment too, especially for anything business-specific. They catch data that generic patterns miss, and you can feed them into auto-labelling so files get tagged correctly without someone doing it by hand.

    Audit mode isn’t optional — it’s the whole point

    Please don’t flip a policy straight to enforcement. I’ve seen it done, and it’s rarely pretty.

    Purview lets you run policies in simulation or audit mode first, and that time is worth every minute. You’ll see false positives you didn’t expect, get a real sense of alert volume, and gather feedback before anyone’s inbox gets blocked mid-deal.

    A deployment sequence that actually holds up in practice:

    1. Discover and assess.
    2. Deploy in audit mode.
    3. Review the incidents that come in.
    4. Fine-tune the conditions.
    5. Turn on user notifications.
    6. Move to enforcement.

    Skip steps and you’ll spend your first week of enforcement fielding complaints instead of reviewing genuine risk.

    Protect the data that actually matters, first

    Trying to lock down every category of sensitive information on day one is a recipe for an alert queue nobody will ever clear. Pick your highest-risk data and start there:

    • Intellectual property
    • Payment card information
    • National Insurance and Social Security numbers
    • Passport details
    • Banking information
    • Healthcare records
    • Customer personal data

    Getting this right early builds confidence in the programme. Getting it wrong — trying to boil the ocean — burns goodwill you’ll need later.

    Built-in SITs are a good starting point, not a finish line

    Microsoft ships hundreds of pre-built Sensitive Information Types — UK National Insurance numbers, credit card numbers, IBANs, passport numbers, NHS numbers, tax IDs, and plenty more. They’re updated regularly, and they get you moving quickly.

    They also throw up more false positives than you’d like. That’s just the nature of pattern matching at scale. Check the accuracy before you enforce anything based on them, and where you’ve got genuinely business-specific data, build custom SITs, Exact Data Match classifiers, or trainable classifiers instead. The accuracy improvement is worth the setup time.

    Policy Tips do more work than people give them credit for

    DLP isn’t only about blocking. A lot of its value comes from simply telling people what’s going on, in the moment, before they make a mistake.

    Policy Tips do exactly that — a quiet warning when someone’s about to email something sensitive externally, with a nudge towards the secure alternative. Users who understand why something’s restricted tend to adjust their behaviour. That means fewer repeat alerts and less friction down the line.

    Alert fatigue will kill your programme faster than any misconfiguration

    I’ve walked into tenants generating thousands of DLP alerts a month that nobody has looked at in weeks. That’s not a security control — it’s noise.

    Tune severity levels properly, route incidents to whoever can actually act on them, and connect things into Microsoft Defender XDR where it makes sense. Review trends regularly. A DLP policy that nobody’s watching isn’t protecting anything.

    Don’t forget the endpoint

    Sensitive data doesn’t stay neatly inside Microsoft 365. Endpoint DLP extends control out to endpoint devices, covering things like:

    • USB transfers
    • Printing
    • Copying to network shares
    • Clipboard activity
    • Uploads to unapproved cloud services

    If you’re working towards Zero Trust, endpoint protection isn’t an add-on to your DLP deployment — it’s part of it from the start.

    Talk to the business before you write the policy

    Security teams have a habit of designing policies around technical requirements and forgetting the business workflows sitting underneath them.

    Bring in legal, compliance, data owners, and information governance early. Finance might have a completely legitimate reason to send payroll data to a trusted third party — block that without understanding it first, and you’ll be firefighting an exception request within the week. Understanding legitimate use cases up front saves you from a pile of exceptions later, and it gets the business on side rather than working around you.

    Make it risk-aware, not just rule-aware

    Modern DLP shouldn’t treat every user the same. Purview can integrate with Insider Risk Management and Adaptive Protection, which lets enforcement flex based on actual risk signals — tighter controls for high-risk users, closer monitoring during someone’s notice period, extra restrictions when risky behaviour shows up.

    This gives you stronger protection where it’s needed, without piling controls onto everyone regardless of risk.

    Test it like it’s real, because it will be

    Lab testing tells you a policy technically works. It doesn’t tell you how it behaves in the hands of an actual user. Test against realistic scenarios — external sharing, Teams messages, email attachments, USB copying, SharePoint uploads, and increasingly, AI-assisted content generation. Pull in real users from different departments before go-live, not just your own team.

    Measure it, or you’re just guessing

    A DLP programme needs numbers behind it. Track the reduction in sensitive data exposure, the number of policy matches, how often users override a block, external sharing trends, incident response times, and activity from high-risk users. Purview’s analytics and reporting give you a genuine read on whether the programme is working — use them.

    The bigger picture

    DLP works best as part of something larger, not on its own. Tied into the rest of the Purview suite and the wider Microsoft Security stack, it becomes part of a proper Zero Trust data security strategy rather than a standalone control that catches some things and misses others.

    My Final Thoughts

    Microsoft Purview DLP is a strong capability, but the deployment is what makes or breaks it. Start with discovery, get classification right, run everything through audit mode before enforcing, use Policy Tips to educate rather than just block, and keep refining as the business changes.

    The point of DLP was never to stop people working. It’s to let people keep collaborating while the sensitive stuff stays where it should. With hybrid working, AI tools, and regulatory requirements all moving at once, that balance matters more than it used to — and Purview DLP, deployed properly, is still one of the better ways to strike it.

  • Configuring and Tuning Microsoft Purview Insider Risk Management Policies

    Insider threats are often among the hardest security risks to detect. Unlike external attackers, insiders already have access to systems, applications, and data. Whether the result of malicious intent, poor judgement, or simple human error, insider activities can lead to data loss, intellectual property theft, compliance violations, and significant reputational damage.

    Microsoft Purview Insider Risk Management (IRM) helps organisations identify potentially risky user behaviour by analysing signals from across Microsoft 365, endpoint devices, Microsoft Defender, and other connected services. When configured correctly, it provides security and compliance teams with valuable insights into activities that might otherwise go unnoticed.

    The challenge, however, isn’t deploying IRM—it’s tuning it effectively. A poorly configured implementation can overwhelm analysts with alerts, making it difficult to distinguish genuine risks from normal business activity. In this article, we’ll look at how to configure IRM policies and, more importantly, how to tune them to produce meaningful, actionable results.

    Understanding Insider Risk Management

    Microsoft Purview IRM correlates signals from multiple Microsoft services to build a picture of user behaviour and identify activities that may need investigation.

    Common scenarios organisations use IRM to detect include:

    • Employees copying sensitive information before leaving the business.
    • Unauthorised sharing of confidential files.
    • Excessive downloading or copying of corporate data.
    • Uploading business information to personal cloud storage platforms.
    • Printing or exporting high-value documents outside normal working patterns.

    Rather than relying solely on predefined rules, IRM incorporates behavioural analytics and machine learning to help you identify activity that deviates from the norm.

    Why Tuning Matters

    One of the most common mistakes I see during deployments is the assumption that IRM will deliver high-quality results immediately after being enabled.

    In reality, every organisation has different working practices, risk tolerances, and data protection requirements. What may be considered suspicious behaviour in one environment could be completely normal in another.

    For example, a software development team may legitimately access large numbers of files every day, while a finance department may regularly transfer sensitive spreadsheets between systems. Without appropriate tuning, these everyday activities can easily generate false positives.

    The objective should never be to generate the highest number of alerts. The goal is to highlight the activities that genuinely deserve investigation while keeping alert volumes manageable for analysts.

    Creating an Insider Risk Management Policy

    Creating a policy is straightforward. Within the Microsoft Purview portal, navigate to:

    Insider Risk Management → Policies → Create Policy

    Microsoft provides several built-in templates covering common risk scenarios, including:

    • Data theft by departing employees
    • Data leaks
    • Data leaks by risky users
    • Data leaks by priority users
    • Risky AI usage
    • Security policy violations
    • Industry-specific templates for healthcare (in Preview)
    • Risky browser usage (in Preview)

    These built-in templates provide an excellent starting point. They show the prerequisites for each template, including optional, recommended and required connectors and configurations.

    Be Careful with User Scope

    Determining who should be monitored is one of the most important decisions you’ll make during implementation.

    Although it may be tempting to monitor every user from day one, doing so often creates unnecessary noise and makes it harder to assess how well policies are performing.

    A better approach is to begin with a controlled pilot group, such as:

    • IT administrators
    • Finance personnel
    • Research and development teams
    • Users handling highly sensitive data

    This allows security teams to validate policy effectiveness and establish behavioural baselines before expanding coverage across the wider organisation.

    Focus on High-Value Indicators First

    Insider Risk Management offers a wide range of indicators covering Microsoft 365 activity, endpoint activity, browser usage, and Microsoft Defender signals.

    While flexibility is useful, using every available indicator rarely delivers the best results.

    In most deployments, I recommend initially focusing on high-confidence activities such as:

    • External sharing of sensitive information
    • High-volume file downloads
    • Large-scale file access events
    • USB transfers
    • Activity associated with departing employees

    Starting with a smaller set of meaningful indicators makes it easier to understand alert quality and significantly reduces analyst fatigue during the early stages of deployment.

    Improve Detection Quality with Content-Based Signals

    Not all files carry the same level of risk.

    Monitoring every document equally often creates unnecessary alerts and reduces the effectiveness of investigations. Instead, organisations should focus on content that has already been identified as valuable or sensitive.

    This can include content protected by:

    • Sensitivity labels
    • Sensitive Information Types
    • Trainable classifiers
    • Data Loss Prevention policies

    Examples may include customer records, financial information, source code, intellectual property, healthcare data, or legal documentation.

    By prioritising sensitive content, organisations can dramatically increase the relevance of generated alerts while reducing false positives.

    Departing Employee Policies Often Deliver the Greatest Value

    In many organisations, departing employee policies generate some of the most valuable IRM alerts.

    Employees approaching resignation or termination may begin collecting information they believe could be useful in future roles. While the majority of users act legitimately, this period often represents increased organisational risk.

    When configuring these policies, focus on activities such as:

    • Uploading files to cloud storage providers.
    • External sharing.
    • Downloading large volumes of sensitive content.
    • Accessing repositories that the employee does not normally use.

    At the same time, avoid assigning excessive weight to routine activities that form part of an employee’s normal workload.

    Review and Refine Continually

    IRM should be treated as an ongoing programme rather than a one-time deployment exercise.

    Regular reviews are essential. A monthly review should examine:

    • Alert volumes
    • False positive rates
    • Frequently triggered indicators
    • Repeat offenders
    • Investigation outcomes
    • Case closure reasons

    These metrics provide valuable insight into whether policies are generating genuine security value or simply creating additional workload for analysts.

    Final Thoughts

    Microsoft Purview IRM can be an exceptionally powerful capability when implemented thoughtfully. However, its effectiveness depends far more on tuning and operational maturity than on the initial policy deployment itself.

    Organisations that take the time to pilot policies, focus on high-value indicators, leverage sensitivity labels, and regularly review outcomes typically achieve far better results than those that attempt to monitor everything from the outset.

    When combined with Microsoft Defender and Adaptive Protection, IRM becomes much more than an alerting tool. It becomes a proactive security capability that helps organisations identify emerging insider threats, protect sensitive information, and reduce risk before incidents escalate into major security events.