RobsonRitch Cyber Security

Category: Microsoft Security

  • 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.