The fix for all of this is a PPPC profile, but Intune gives you no UI for building one. You either copy XML from a blog post and pray, or you reach for Jamf. Neither is great.

That’s the gap MacPPPC closes. It’s a free, fully browser-based tool that builds the .mobileconfig for you and deploys it directly to Intune over Microsoft Graph - using your own Entra ID sign-in. No backend, no Jamf, no manual XML. It’s live at macpppc.com.

Table of Contents

• What is MacPPPC?
• A quick refresher on PPPC and TCC
• Requirements
• How it works
  • Step 1: Build the profile
  • Step 2: Deploy to Intune
  • Or just download it
• The Apple rules it enforces for you
• Security and privacy
• Required Entra permissions
• Conclusion

What is MacPPPC?

MacPPPC is a single-page web app that does two things. First, it builds a macOS Privacy Preferences Policy Control profile that pre-approves an app’s access to protected resources so your users never see the prompt. Second, it pushes that profile straight into Intune - either as a classic macOSCustomConfiguration custom profile or as a modern Settings Catalog policy - complete with scope tags, deployment channel, and assignments.

The whole thing runs client-side in React. Profiles are generated in your browser, and the Intune deployment happens directly between your browser and graph.microsoft.com. There is no server in the middle, no telemetry, and nothing to install.

What it gives you:

• A point-and-click builder for all 24 PPPC services Apple exposes to MDM - Accessibility, Full Disk Access (and the granular Desktop/Documents/Downloads/Network/Removable/Admin folder variants), Camera, Microphone, Screen Recording, Input Monitoring, Bluetooth, Contacts, Calendars, Reminders, Photos, Media Library, Speech Recognition, Apple Events automation with receiver-app pairing, and more.
• 87 prebuilt apps, each with its designated code requirement already verified - everything from 1Password, Adobe Illustrator, and Zoom to AnyDesk, Arc, and BeyondTrust. The common ones are a single click; for anything else, drop in an Info.plist or a zipped .app bundle and it reads the designated requirement for you.
• Direct Intune deployment over Graph in either format - a classic custom profile or a Settings Catalog policy - with scope tags, device or user channel, and full assignment control (none, all users, all devices, or groups with include/exclude and per-group assignment filters).
• A live preview of exactly what’s being generated - XML for a custom profile, or JSON when you target the Settings Catalog - before anything leaves your browser.
• No Client Secret. It uses the SPA + PKCE OAuth flow, so only your Entra app’s public Client ID is ever involved.

A quick refresher on PPPC and TCC

If you live mostly in the Windows side of M365, this is the bit worth slowing down for. macOS protects sensitive resources - the camera, the microphone, your files, screen contents - behind a subsystem called TCC (Transparency, Consent, and Control). When an app first touches one of those resources, macOS asks the user to allow or deny it.

That’s fine for one Mac. Across a fleet it’s a support nightmare: users deny by accident, apps break, and there’s no consistency. PPPC is Apple’s MDM answer. A PPPC profile tells the Mac, ahead of time, “this specific app, identified by its code signature, is allowed (or denied) this specific resource.” The prompt never appears, and the decision is yours, not the user’s.

The catch is that the profile has to be exactly right. Each app is pinned to a designated code requirement - a signature string that proves the binary is the genuine, untampered app. Each permission maps to an exact Apple TCC service name like SystemPolicyAllFiles or ScreenCapture. One typo and the profile silently does nothing. Now multiply that by every app you need to cover and every Mac in your fleet - by hand it’s hours of fiddly, error-prone work, repeated per app. MacPPPC fills in the code requirements and service names for you, and lets you configure every app and permission in one bulk pass instead of one painful profile at a time.

Requirements

Here’s the best part: nothing. You just open it in a modern browser and it’s working. To deploy straight to Intune you only need:

• An Entra ID account with rights to create device configuration profiles in Intune (Intune Administrator, or a custom role with the scopes below)
• Admin consent for the delegated Graph scopes the first time it’s used in your tenant

And if you just want the profile to upload by hand, you don’t even need to sign in - build it, download it, done.

How it works

The app is one page in two steps.

‹ ›

Step 1: Build the profile

1. Add your apps. Drag-and-drop a .zip of an .app bundle, drop an Info.plist directly, or pick from the catalog of 87 prebuilt apps. Uploaded apps are matched against the catalog by their CFBundleIdentifier, and if there’s a match the canonical code requirement is filled in automatically.
2. Toggle the permissions you want per app. The authorization dropdown (Allow / Allow standard user / Deny) is constrained automatically by Apple’s rules - more on that below.
3. Pick the deployment format. Choose a classic custom profile (.mobileconfig) or a Settings Catalog policy (recommended). The Settings Catalog is the modern path Microsoft is steering everyone toward - it’s understood natively by Intune, re-importable, and cleaner to manage than a raw custom-config blob.
4. Pick an output mode. Single bundle puts every app into one profile (the default), or Separate profiles generates one per app, packaged as a ZIP and deployed as separate Intune policies.
5. Watch the live preview. The right rail shows the generated payload with syntax highlighting - XML for a custom profile, or JSON if you’re targeting the Settings Catalog - so you can verify it before you deploy.

Here’s a trimmed example of a single-app payload as a classic custom profile (.mobileconfig) - one com.apple.TCC.configuration-profile-policy payload with a Services dictionary keyed by Apple’s exact TCC service names:

<key>Services</key>
<dict>
  <key>ScreenCapture</key>
  <array>
    <dict>
      <key>Identifier</key>
      <string>us.zoom.xos</string>
      <key>IdentifierType</key>
      <string>bundleID</string>
      <key>CodeRequirement</key>
      <string>identifier "us.zoom.xos" and anchor apple generic ...</string>
      <key>Authorization</key>
      <string>AllowStandardUserToSetSystemService</string>
    </dict>
  </array>
</dict>

The exact same intent, expressed as a Settings Catalog policy, is JSON instead - posted to /beta/deviceManagement/configurationPolicies. It’s more verbose because every setting is a typed Graph instance, but it’s what Intune understands natively and what you can re-import later (always-null template fields trimmed here for readability):

{
  "name": "PPPC Configuration",
  "platforms": "macOS",
  "technologies": "mdm,appleRemoteManagement",
  "roleScopeTagIds": ["0"],
  "settingCount": 1,
  "settings": [
    {
      "id": "0",
      "settingInstance": {
        "@odata.type": "#microsoft.graph.deviceManagementConfigurationGroupSettingCollectionInstance",
        "settingDefinitionId": "com.apple.tcc.configuration-profile-policy_services_screencapture",
        "groupSettingCollectionValue": [
          {
            "children": [
              {
                "@odata.type": "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance",
                "settingDefinitionId": "com.apple.tcc.configuration-profile-policy_services_screencapture_item_authorization",
                "choiceSettingValue": {
                  "value": "com.apple.tcc.configuration-profile-policy_services_screencapture_item_authorization_2",
                  "children": []
                }
              },
              {
                "@odata.type": "#microsoft.graph.deviceManagementConfigurationSimpleSettingInstance",
                "settingDefinitionId": "com.apple.tcc.configuration-profile-policy_services_screencapture_item_identifier",
                "simpleSettingValue": {
                  "@odata.type": "#microsoft.graph.deviceManagementConfigurationStringSettingValue",
                  "value": "us.zoom.xos"
                }
              }
            ]
          }
        ]
      }
    }
  ]
}

That choice value ending in _2 is the Settings Catalog way of saying Allow standard user to enable - the exact same authorization the XML expressed as AllowStandardUserToSetSystemService. MacPPPC generates whichever one you pick; you never hand-write either.

Step 2: Deploy to Intune

1. Sign in with Entra ID using the button in the top-right. MSAL handles the redirect and your tokens stay in your browser.
2. Name each policy. In bundle mode that’s one row. In separate mode it’s one row per app, plus an optional bulk-rename pattern using {appName} and {bundleId} placeholders.
3. Pick scope tags (multi-select, defaults to Default) and the deployment channel - device or user - per policy.
4. Configure the assignment per policy: none, all users, all devices, or specific groups with include/exclude. Each include group can carry its own assignment filter, and Copy to all mirrors one policy’s assignment onto every other.
5. Click Deploy. Each policy is created via Graph - a macOSCustomConfiguration under /beta/deviceManagement/deviceConfigurations for a classic profile, or a Settings Catalog policy under /beta/deviceManagement/configurationPolicies - then assigned via the matching .../assign call. Results appear inline with deep links straight to the Intune portal.

Or just download it

Not ready to give a browser tool access to your tenant? Skip the sign-in entirely. The Download button hands you the same output (a .mobileconfig for a custom profile, or a Settings Catalog JSON you can pull in through Intune’s Import policy button), ready to upload by hand. You get the generator without ever connecting Graph.

The Apple rules it enforces for you

A few macOS permissions can’t be force-granted from MDM, no matter what you put in the profile. This trips people up constantly, so MacPPPC bakes the rules into the UI instead of letting you ship a profile that won’t work:

• Camera and Microphone honour only Deny. Apple ignores everything else for these - you cannot force-allow them, so the builder only offers Deny.
• Screen Recording and Input Monitoring honour Deny or Allow standard user to enable. A hard force-Allow isn’t permitted via profile, so that option is removed.
• Everything else gets the full Allow / Allow-standard-user / Deny dropdown.

The generated profiles are intentionally unsigned - Intune doesn’t require signing for custom configuration profiles, so there’s nothing extra to manage.

Security and privacy

Because this tool touches your tenant, it’s worth being explicit about what it does and doesn’t do:

• 100% client-side. The static bundle runs entirely in your browser. No backend, no analytics on your tenant data, no proxy.
• Graph calls go direct from your browser to graph.microsoft.com. Your profile data never passes through any server I run.
• MSAL tokens live in your browser’s localStorage so they survive the Microsoft redirect and persist across reloads. Signing out clears them, and they’re never sent anywhere except Microsoft.
• No Client Secret. Sign-in uses the SPA + PKCE flow against a public Client ID - there’s no secret baked into the build to leak. The app acts purely with your own delegated permissions, scoped to exactly what’s needed: read scope tags and groups, and write device configuration profiles. Nothing beyond what your account can already do is ever exposed.

Required Entra permissions

The app requests these delegated scopes on sign-in. All four require admin consent the first time it’s used in a tenant:

• DeviceManagementConfiguration.ReadWrite.All - create and update device configuration profiles
• DeviceManagementRBAC.Read.All - read the scope tag list
• Group.Read.All - search security groups for assignment
• User.Read - show your name in the top bar

That’s the minimum needed to build and assign profiles, and nothing more.

Conclusion

MacPPPC turns one of the more tedious corners of macOS management into a few clicks: pick your apps, toggle the permissions, and either download a clean .mobileconfig or push it straight into Intune over Graph - with full control over scope tags, channel, and assignments. It enforces Apple’s MDM quirks so you don’t ship a profile that silently fails, and it does it all in the browser with no backend touching your data.

If you manage Macs in Intune and you’ve been avoiding PPPC because the XML is fiddly and Jamf is overkill, give it a try at macpppc.com. It’s free, it’s client-side, and as always - test in a pilot group before you roll it out broadly. Big thanks to Simon Hartmann Eriksen for building the original PPPC Builder and for teaming up on MacPPPC.

Related

• RKSolutions PowerShell Module - Microsoft Graph reporting for Intune, Entra, and M365.

This final post ties them together into a single reference you can use when scoping a customer, building a service tier, or answering the question every MSP eventually gets: “what are we actually missing?”

The five gaps

Each post in this series started with the same premise: Business Premium and E3 are solid baselines. They cover identity, device management, email protection, and basic compliance. But they stop short in five areas that matter the moment a customer moves past “good enough.”

#1 - The Hunting Gap

What’s missing: Business Premium and E3 alert on known threats but give you no way to hunt for the ones that haven’t triggered an alert yet. No Advanced Hunting, no KQL access to raw telemetry, no Custom Detection Rules.

What closes it: Defender for Endpoint Plan 2 - 30 days of queryable telemetry, custom detections that run continuously, and the ability to hunt across your entire customer fleet.

Why it matters: Reactive alerting catches known patterns. Hunting catches the setup step - the lateral movement, the staging, the persistence mechanism that hasn’t fired yet. Read the full post.

Most compromise starts long before the alert.

#2 - The Data Gap

What’s missing: Base Purview covers email and files in SharePoint/OneDrive. It does not cover endpoints, Teams chat, or cloud apps. A departing employee copies sensitive data to a USB drive or personal cloud storage, and base Purview never sees it.

What closes it: Purview Suite ($10/user/month) - endpoint DLP, Teams DLP, Insider Risk Management, eDiscovery Premium, and event-based retention.

Why it matters: Data protection that stops at email and documents misses the places data actually leaves - endpoints, messaging, and cloud apps. Read the full post.

#3 - The Identity Gap

What’s missing: Entra ID P1 covers MFA and Conditional Access. It does not cover risk-based decisions, just-in-time privileged access, automated access reviews, or on-prem Active Directory visibility.

What closes it: Entra ID P2 adds risk-based CA, PIM, and Access Reviews. Defender for Identity adds on-prem AD threat detection. Both are included in the Defender Suite for Business Premium ($10/user/month).

Why it matters: Standing admin privileges are the single most exploited pattern in identity attacks. PIM removes them. Risk-based CA adapts access decisions to real-time threat signals instead of static rules. Defender for Identity (DfI) sits on your on-prem domain controllers and detects identity attacks against AD itself, including Kerberoasting, DCSync, and lateral movement. Without it, you have full visibility into cloud identity and zero visibility into the on-prem AD that still holds most customers’ privileged accounts. Read the full post.

#4 - The Exposure Gap

What’s missing: Base SKUs prevent threats but cannot measure exposure. No post-delivery email investigation, no automated incident response for email, no visibility into shadow IT or shadow AI, no OAuth app governance.

What closes it: MDO P2 adds Threat Explorer, AIR, Campaign Views, and Attack Simulation Training. Defender for Cloud Apps adds shadow IT discovery, OAuth governance, session controls, and shadow AI detection. Both are in the Defender Suite.

Why it matters: Prevention without investigation is half the story. When a phishing campaign lands in 30 mailboxes, you need to scope it in minutes, not hours. When a former MSP leaves behind an OAuth app with Mail.ReadWrite, you need to find it before it is used. Read the full post.

#5 - The Endpoint Gap

What’s missing: Intune Plan 1 enrolls and configures devices. It does not give you least-privilege elevation, third-party app patching, device health analytics, or zero-trust remote support.

What closes it: The Intune Suite ($10/user/month) - EPM, EAM, Advanced Analytics, Remote Help, Cloud PKI, and Intune Plan 2 features. After July 2026, E3 gets Remote Help, Advanced Analytics, and Plan 2 for free. E5 gets everything. Business Premium gets nothing.

Why it matters: Every 15-minute remote session for an elevation request, every hour spent repackaging a Win32 update - that is operational cost the Intune Suite replaces with a predictable line item. Read the full post.

The licensing map

Three upgrade paths cover all five gaps. The right one depends on the customer’s base SKU.

Business Premium customers

$25/user/month closes all five gaps on Business Premium. That is the ceiling. Not every customer needs all of it - start with the gaps that match their risk profile and compliance requirements.

E3 customers

E5 customers

E5 includes E5 Security (Hunting, Identity, Exposure gaps closed). After July 2026, the full Intune Suite folds in automatically.

Prices are Microsoft list per user per month, as of May 2026. CSP, NCE, and Enterprise Agreement pricing differs; check with your licensing partner for the real customer number.

The pattern across all five posts

Every post followed the same structure because the licensing problem is the same every time.

The base SKU covers the obvious use case. Alerts fire. Policies deploy. Compliance checks run.

The gap is in what happens next. Hunting after the alert. Investigating after the phish. Reviewing after the access grant. Patching after the enrollment.

The upgrade is not a feature purchase. It is an operational trade. You are replacing unpredictable manual work with a predictable per-user cost and a repeatable process.

That last point is the one that matters most for MSPs. Every gap in this series is also a service opportunity:

• Hunting: managed detection, KQL library, custom detection rule tuning
• Data: DLP policy authoring, Insider Risk triage, eDiscovery delivery
• Identity: PIM onboarding, access review cadence, hybrid identity hardening
• Exposure: phishing investigation, OAuth app governance, Shadow IT and AI review
• Endpoints: app lifecycle management, EPM policy tuning, third-party patching

Where to start

Do not try to close all five gaps at once. Pick the one that matches the customer’s most urgent risk or compliance requirement:

• Post-incident: start with #1 (Hunting) or #4 (Exposure) - the customer just had an incident and wants investigation capability
• Compliance audit: start with #2 (Data) - the auditor is asking about DLP, retention, and eDiscovery
• Admin sprawl: start with #3 (Identity) or #5 (Endpoints) - standing admin privileges are the problem
• Operational overhead: start with #5 (Endpoints) - too much time on manual packaging and elevation requests

Deploy in one tenant first. Validate the baseline. Then scale out.

Business Premium and E3 are not bad licenses. They are starting points. The moment a customer needs investigation, governance, automation, or operational scale, the real licensing conversation begins.

The series

Last verified: May 2026

Meanwhile, GlobalProtect pushes another update. On Intune Plan 1, keeping it current means: download the new installer, repackage it as a Win32 app, configure detection rules, upload to each tenant, deploy, and monitor - or build a custom wrapper around winget and hope it holds. Either way, that is engineering time you are spending on work a catalog should handle for you. And GlobalProtect is just one app out of dozens.

Both are endpoint management problems that Intune Plan 1 does not solve. They are also cost problems. Every 15-minute remote session for an elevation request, every hour spent repackaging a Win32 update, every incident that starts with a user who had local admin they should not have had - that is money. The Intune Suite at $10/user/month is not just a feature upgrade. It is a trade: a predictable line item that replaces unpredictable operational cost.

This post is part of The MSP License Ladder, a series on what Business Premium and E3 don’t give you, and how to build on top of them. Every post covers one gap: what’s missing from the base SKU, what it costs to close, and what you can actually build with it. Previous: #4, The Exposure Gap.

A few terms up front:

• EPM (Endpoint Privilege Management): just-in-time admin elevation without standing local admin rights. Users request, you approve (or auto-approve by rule).
• EAM (Enterprise App Management): curated app catalog with 450+ third-party apps, auto-update, and supersedence handling. Microsoft hosts the binaries.
• Intune Suite: the bundle that includes EPM, EAM, Advanced Analytics, Remote Help, Cloud PKI, and Intune Plan 2 features. $10/user/month on top of Intune Plan 1.

Table of Contents

• What you actually get today
• The July 2026 split
• The concrete gaps
  • Endpoint Privilege Management
  • Enterprise App Management
  • Advanced Analytics
  • Remote Help
  • Intune Plan 2
  • Cloud PKI
• The upgrade paths
• What you unlock
• When not to bother
• Security Copilot in Intune
• How to pitch it
• Conclusion

What you actually get today

Business Premium, Microsoft 365 E3, and Microsoft 365 E5 all include Intune Plan 1:

Enroll devices across Windows, macOS, iOS, and Android. Push configuration profiles, compliance policies, and Windows Update rings. Deploy Win32 apps, LOB apps, and Microsoft Store apps. Use device compliance as a Conditional Access grant control. Provision new machines with Windows Autopilot. Get basic device and app performance data through endpoint analytics.

All three SKUs share the same endpoint management baseline right now. None of them include the Intune Suite or any of its components.

The July 2026 split

This is what makes this post different from every other post in the series. In July 2026, Microsoft is folding Intune Suite components into E3 and E5 - but not into Business Premium. For the first time in the series, a gap closes automatically for some customers and stays open for others.

Source: Microsoft 365 adds advanced Microsoft Intune solutions at scale. Rollout begins CY26 Q3. Eligible tenants are auto-provisioned with 30-day admin center notice.

The takeaway: E5 customers get everything. E3 customers get Remote Help, Advanced Analytics, and Plan 2 features - but not EPM, EAM, or Cloud PKI. Business Premium customers get nothing. The Endpoint Gap stays fully open for BP.

The concrete gaps

Intune Plan 1 enrolls devices, pushes configuration, and deploys apps. Microsoft Store apps handle their own updates, but every Win32 and LOB app you deploy is yours to keep current - unless the app has its own auto-update mechanism, you are repackaging and redeploying manually. That is only the beginning of where the baseline stops. These are the gaps that show up after enrollment.

Endpoint Privilege Management

A user needs admin rights to install a custom application for a legacy file share. On Intune Plan 1, your options are: give them local admin (permanent, unscoped, no audit trail) or remote in yourself (15 minutes per request, does not scale). And since EPM only allows elevation for local executables, you also need to copy the installer from the share to the local drive first.

EPM replaces both with just-in-time elevation. You define elevation rules: auto-approve known executables by file hash or certificate, require approval for unknowns, block everything else. The user right-clicks and selects “Run with elevated access.” If the rule matches, it elevates that single process. If not, it routes to you for approval. Every elevation is logged with full metadata - executable name, user, device, rule matched, timestamp.

This ties directly back to #1, The Hunting Gap. Local admin sprawl is exactly what Advanced Hunting flags in DeviceLogonEvents. EPM prevents it at the source instead of hunting for it after the fact.

Enterprise App Management

Take something as common as GlobalProtect. On Intune Plan 1, you have two options: package every update as a new Win32 app (download the installer, wrap it, configure detection rules, upload, deploy, repeat next month), or build a custom Win32 app that shells out to winget and hope the detection logic holds. Both work. Neither scale. And that is just one app - multiply it by every third-party tool your customers rely on that does not auto-update through its own mechanism.

EAM provides the Enterprise App Catalog - a curated collection of 450+ third-party apps hosted by Microsoft. GlobalProtect is in the catalog. So are Zoom, 7-Zip, Notepad++, and hundreds of others. You pick the app, and Intune provides the binary, the detection rules, the install commands, and the supersedence logic. When a new version lands in the catalog (target: 80-90% within 24 hours of vendor release), Intune flags it in the Enterprise App Catalog apps with updates view. You review it, create the supersedence relationship, and the update rolls out. It is not fully automatic - you still approve the update - but the heavy lifting (packaging, detection rules, hosting) is done for you. No more repackaging. No more winget workarounds.

The difference: you stop being a software distribution pipeline and start being a policy layer on top of one.

Advanced Analytics

A user reports their laptop is slow. You check compliance - it says “compliant.” That tells you the device meets your minimum bar. It does not tell you why it is slow.

Advanced Analytics extends base endpoint analytics with reports that answer the question compliance cannot: resource performance (CPU and RAM issues by device, model, and manufacturer), battery health (cycle count, designed vs actual capacity, degradation trends), anomalies (regressions in user experience after configuration changes), and device timeline (low-latency event history for troubleshooting). The properties catalog collects detailed hardware inventory per device, but spotting a trend across hundreds of devices from individual device views is impractical - that is where fleet-wide device query comes in.

The standout feature is device query for multiple devices. Once you deploy a properties catalog policy to your Windows devices, Intune collects hardware inventory data that you can query using KQL - across your entire fleet, not just one device at a time. The properties catalog covers CPU, disk, memory, TPM, BIOS, battery, network adapters, encryption status, OS version, and more. You can run queries like “show me all devices with an unencrypted volume,” “list devices with less than 50% battery health,” or “count devices by OS version” - and get results across hundreds of devices in seconds. Device query also works on iOS, Android, and macOS without a properties catalog policy.

Think of it as Advanced Hunting for device inventory instead of security telemetry.

Remote Help

Quick Assist works fine for basic Windows remote support. But it does not tie into your identity stack, it has no role-based access control, no compliance warnings before connecting, and no audit trail in the Intune admin center. And it only works on Windows.

Remote Help is remote assistance built into Intune. Both helper and sharer authenticate with Entra ID - every session is identity-verified within your tenant. RBAC controls what the helper can do: view-only or full control. On Windows, helpers can also enter UAC credentials on the sharer’s device for elevated access. Sessions are logged in the Intune admin center with full audit history. Before connecting, the helper sees the device’s compliance state.

Where Remote Help pulls ahead of Quick Assist and third-party tools:

• Cross-platform: Windows, macOS (native app or web-based screen sharing), and Android (including unattended access for dedicated devices)
• Unenrolled device support: optionally allow help on devices not yet enrolled in Intune - useful for onboarding scenarios
• Remote launch (Windows): start a session from the Intune admin center by sending a notification to the sharer’s device - without the sharer initiating it
• Conditional Access integration: require MFA, compliant devices, or specific locations before allowing a help session
• Web app fallback: if the sharer cannot install the native app, they can share their screen via a browser (view-only for the helper)

Intune Plan 2

Three capabilities bundled together:

• Microsoft Tunnel for MAM: mobile VPN gateway that works without device enrollment. The standout for BYOD - users connect to corporate resources from personal iOS/Android devices through an app-level tunnel, without enrolling the device in Intune.
• Specialty device management: enrollment and policy support for AR/VR headsets, large smart-screen devices, and conference room equipment.
• Firmware-over-the-air: remote firmware updates for supported Zebra devices.

Cloud PKI

Certificate-based authentication without on-prem ADCS or NDES infrastructure. Matters most for cloud-native customers who need Wi-Fi or VPN certificate profiles but do not have (and do not want) a server room to run a PKI. If the customer has an existing on-prem PKI that works, Cloud PKI solves a problem they do not have.

The upgrade paths

Three paths to close the Endpoint Gap.

Prices are Microsoft list per user per month, as of May 2026. Confirm standalone add-on pricing at purchase time.

The bundle math: EPM + EAM standalone is roughly $6-8/user/month for two components. The Intune Suite at $10/user/month adds Advanced Analytics, Remote Help, Cloud PKI, and Plan 2 features on top. Unless the customer only needs one specific component, the Suite is the better path.

What you unlock

The practical difference: the custom app install from the opening becomes a 10-second EPM approval instead of a 15-minute remote session. Third-party app updates become catalog-driven rollouts instead of manual packaging sprints across 5 tenants.

When not to bother

Not every customer needs the Intune Suite. Two scenarios where the upgrade will not earn its keep:

E3/E5 customers approaching July 2026. If the customer is 2-3 months away from the fold-in and the need is not urgent, waiting is free. E3 gets Remote Help, Advanced Analytics, and Plan 2 features. E5 gets everything. The exception is E3 customers who need EPM or EAM specifically - those do not fold into E3, only into E5.

Very small BP customer with no app sprawl and no elevation patterns. If the customer has 10 managed devices, all corporate, running a handful of LOB apps, and the owner is already local admin everywhere, the Suite adds capability they will not use enough to justify $10/user/month. EPM matters most for organizations where users regularly need elevation - a 5-person office where everyone has local admin already does not have that pattern.

Security Copilot in Intune

One more thing worth knowing. Security Copilot - which powers the Copilot experience inside the Intune admin center - is included with Microsoft 365 E5 at no additional cost. E5 customers get 400 Security Compute Units (SCUs) per month per 1,000 users, auto-provisioned. Business Premium and E3 customers would need a standalone Security Copilot purchase.

Copilot in Intune lets you run natural language device queries (“show me all devices that failed the latest Windows update”), troubleshoot policy conflicts, and generate KQL from plain English. It is not part of the Intune Suite - it sits on a different licensing model entirely (consumption-based SCUs vs per-user). It deserves its own coverage, but for this post the key point is: E5 gets it, BP and E3 do not.

How to pitch it

Post-incident (EPM). “The compromised device last month started with a user who had standing local admin. EPM removes that and lets you approve specific elevations on demand. Every request is logged.”

Patch urgency (EAM). “You repackage GlobalProtect every month across every tenant. EAM auto-patches 450+ third-party apps from a Microsoft-hosted catalog. You set the policy once.”

Insurance and compliance (Advanced Analytics + Remote Help). “Your cyber insurance questionnaire asks about device health monitoring and secure remote access. Advanced Analytics gives you fleet health scoring. Remote Help gives you auditable, identity-verified support sessions.”

July 2026 timing (for BP customers). “Your E3 and E5 competitors are about to get Remote Help, Advanced Analytics, and Plan 2 features for free. Business Premium does not. The Intune Suite at $10/user/month is how you close that gap.”

Price it as a managed endpoint service, not a licence passthrough. The $10/user/month Intune Suite is the floor.

Conclusion

Intune Plan 1 gets devices enrolled and configured. The Intune Suite adds what comes after: EPM removes standing local admin and replaces it with audited, just-in-time elevation. EAM takes third-party app packaging off your plate. Advanced Analytics gives you fleet-wide device health data you can actually query. Remote Help ties remote support to your identity stack across Windows, macOS, and Android.

The $10/user/month cost is real, but so is the time you are currently spending on manual elevation requests, Win32 repackaging, and blind troubleshooting. For many customers, the Suite pays for itself in reduced operational overhead before the security benefits even enter the conversation.

After July 2026, the math changes. E5 customers get the full Suite folded in. E3 customers get Remote Help, Advanced Analytics, and Plan 2 features. Business Premium customers get nothing - the Endpoint Gap stays open, and closing it remains a separate purchase.

Start with one customer tenant. Deploy an EPM elevation settings policy, connect the Enterprise App Catalog, and review the first week of data. Then scale out.

Part of The MSP License Ladder series. Previous: #4, The Exposure Gap.

Last verified: May 2026

Related

• The MSP License Ladder #1: The Hunting Gap – what Defender for Endpoint Plan 2 unlocks for proactive threat hunting across your customer fleet.
• The MSP License Ladder #2: The Data Gap – what Purview Suite unlocks over base Business Premium and E3 for DLP, Insider Risk, and eDiscovery.
• The MSP License Ladder #3: The Identity Gap – what Entra ID P2 and Defender for Identity unlock for risk-based CA, just-in-time privilege, and on-prem AD visibility.
• The MSP License Ladder #4: The Exposure Gap – what MDO P2 and Defender for Cloud Apps unlock for post-delivery investigation and Shadow IT/AI visibility.

Meanwhile, a different customer onboards after leaving their previous MSP. The old MSP’s ticketing tool still holds an active OAuth consent with Mail.ReadWrite and Directory.Read.All scope. Entra shows the consent exists, but not whether the app is still reading mail, whether the scope was ever appropriate, or whether the former MSP even still controls the app registration. And that is just the apps that went through Entra. The browser-based AI tools, file converters, and screen recording services that never touch SSO are completely invisible.

Both are exposure problems. Prevention works, but you cannot measure the exposure that slips past it. That is the gap this post is about.

This post is part of The MSP License Ladder, a series on what Business Premium and E3 don’t give you, and how to build on top of them. Every post covers one gap: what’s missing from the base SKU, what it costs to close, and what you can actually build with it. Previous: #3, The Identity Gap.

A few terms up front:

• EOP (Exchange Online Protection): baseline email security in every M365 subscription. Anti-spam, anti-malware, spoofing protection.
• MDO (Microsoft Defender for Office 365): Plan 1 adds prevention (Safe Links, Safe Attachments). Plan 2 adds investigation and response (Threat Explorer, AIR, Attack Simulation Training).
• DfCA (Defender for Cloud Apps, previously known as MCAS): Microsoft’s Cloud Access Security Broker. Shadow IT discovery, OAuth app governance, session policies, SaaS DLP.
• AIR (Automated Investigation and Response): playbook-driven investigation that correlates signals across email, endpoints, and identity.

Table of Contents

• What you actually get today
• The concrete gaps: email and collaboration
• The concrete gaps: cloud apps and OAuth
• The upgrade paths
• What you unlock
• When not to bother
• How to pitch it
• Conclusion

What you actually get today

Business Premium ships with EOP plus MDO Plan 1:

• Safe Links: URL detonation at click time across email, Office documents, and Teams
• Safe Attachments: sandbox detonation for email attachments and files in SharePoint, OneDrive, and Teams
• Anti-phishing: user and domain impersonation protection, mailbox intelligence
• Zero-hour auto purge (ZAP): retroactive removal of malicious messages already delivered
• Real-time detections: a lightweight investigation view (not the full Threat Explorer)

Microsoft 365 E3 today ships with EOP only. No Safe Links, no Safe Attachments, no anti-phishing impersonation protection.

E3 from July 2026 gains MDO Plan 1 automatically as part of the Microsoft 365 packaging update. Rollout begins June 2026 and completes by August 1, 2026. After that date, E3 and Business Premium share the same email security baseline.

For SaaS and OAuth on both SKUs: base Entra ID shows consented apps in the Enterprise Applications blade. No risk scoring, no discovery of apps outside SSO, no session controls, no AI tool detection.

The concrete gaps: email and collaboration

MDO Plan 1 prevents threats. It does not help you investigate what got through. These are the scenarios where that gap shows up.

Post-delivery visibility

A phishing email was delivered to 30 mailboxes. You need to find everyone who received it, not just those who clicked. Threat Explorer gives you 30 days of searchable email data filtered by sender, subject, URL, attachment hash, or delivery action. On Plan 1, Real-time detections is a subset that cannot search historical delivered mail at the same depth.

Automated Investigation and Response

A user reports a phish. You need to correlate the sender’s patterns, the URL’s reputation, the attachment’s detonation results, and what the recipient did after clicking. On Plan 1, that is manual. AIR automates it: runs a playbook, correlates signals, and produces a remediation recommendation you review and approve.

Campaign Views

Three employees report suspicious emails. Are they related? Campaign Views groups related phishing attempts by sender infrastructure, payload, and social engineering pattern into a single view. On Plan 1, you check each report individually.

Attack Simulation Training

The customer’s cyber insurance renewal asks about phishing simulations and click rates. Attack Simulation Training runs realistic simulations, tracks who clicks, and auto-assigns training. The results are the artefact the insurer wants. Plan 1 has no mechanism for this.

The concrete gaps: cloud apps and OAuth

Base Entra ID shows OAuth consents in the Enterprise Applications blade. That is where cloud app visibility ends.

Shadow IT discovery

Users sign up for SaaS tools with their work email. Some go through SSO; many do not. Defender for Cloud Apps discovers the rest by analyzing network traffic against a catalog of over 31,000 cloud apps, each scored on 90+ risk factors.

OAuth app risk scoring

An employee consented to an app with Mail.ReadWrite scope. Is the publisher verified? Is the scope excessive? DfCA’s app governance adds risk scoring: publisher verification, scope risk classification, credential hygiene, and behavioral anomaly detection, including app-to-app permissions.

Session policies

A contractor accesses Salesforce from a personal device. You want to allow read access but block downloads. Conditional Access can block or allow the sign-in but cannot control the session. DfCA session policies add in-session controls: block downloads, watermark files, prevent copy/paste, all proxied through DfCA without requiring device management.

Shadow AI detection

Business Premium already includes cloud app discovery through Defender for Business. That discovery already covers the Generative AI category - you can see which AI tools are being accessed and how much traffic flows to them. What Business Premium does not give you is the ability to act on it. DfCA adds per-user attribution (who is using which AI tool, not just that someone did), data volume breakdowns, and policy controls to sanction, unsanction, or block specific AI apps. That is the difference between a dashboard that says “ChatGPT was accessed” and a policy that says “block uploads to unsanctioned AI tools for everyone except the data science team.”

The upgrade paths

Three paths to close the email and SaaS gap.

Prices are Microsoft list per user per month, as of May 2026. CSP, NCE, and Enterprise Agreement pricing differs.

The bundle wins again. MDO P2 + DfCA standalone costs ~$8.50/user/month for email and SaaS only. For $10/user/month the Defender Suite adds MDE P2, DfI, and Entra ID P2. Unless the customer needs only one component, the bundle is the better path.

July 2026 note for E3 customers

After July 2026, E3 includes MDO P1. The email gap narrows to the P2 delta (Threat Explorer, AIR, Attack Simulation Training). The MDO P2 upgrade path stays the same.

What you unlock

The practical difference: the phishing campaign from the opening takes 5 minutes to scope in Threat Explorer instead of hours. AIR recommends soft-deleting messages from all 30 mailboxes. The former MSP’s ticketing tool with Mail.ReadWrite and Directory.Read.All gets flagged automatically. Shadow AI tools surface with per-user data volume in the cloud discovery dashboard.

When not to bother

Not every customer needs MDO P2 and DfCA. Two scenarios where the upgrade will not earn its keep:

Too few mailboxes for Attack Simulation Training (AST). AST needs enough recipients for a meaningful click rate. A 5-person office does not have the volume for realistic phishing simulations, and the results are not statistically useful. Threat Explorer, AIR, and Campaign Views still add investigation value at any size, but if AST is the main justification for the upgrade, the economics do not work below roughly 25-30 users.

Tight app allow-list, no BYOD, no SaaS sprawl. If the customer runs a handful of IT-managed apps behind SSO, every device is corporate-managed, and users cannot install their own tools, DfCA’s Shadow IT discovery will mostly confirm what you already know. The Shadow AI angle can still matter if the customer is concerned about browser-based AI tool usage, but the broader OAuth governance and session policy workloads will stay quiet. In that scenario, MDO P2 on its own may be the better scoped purchase.

How to pitch it

Post-incident. “The phishing campaign last month hit 30 mailboxes and took a full day to scope. With Threat Explorer, that is a 5-minute search. AIR automates the investigation and recommends the remediation.”

Insurance renewal. “Your cyber insurance questionnaire asks about phishing simulations. Attack Simulation Training gives you real simulations with click rates and auto-assigned training. That is the artefact the underwriter wants.”

Shadow AI. “Your staff is using AI tools you cannot see from the admin center. DfCA shows which tools, who uses them, and how much data flows. That is the visibility you need before writing an AI usage policy.”

OAuth risk. “You have 40 consented apps in Entra. How many have Mail.ReadWrite from an unverified publisher? DfCA flags the ones you should revoke before they become an incident.”

Price it as a managed security service, not a licence passthrough. The $10/user/month Defender Suite for BP is the floor.

Conclusion

Prevention is half the story. MDO P2 adds the investigation layer for email: Threat Explorer, AIR, Campaign Views, and Attack Simulation Training. Defender for Cloud Apps adds the visibility layer for everything outside email: Shadow IT, OAuth governance, session controls, and Shadow AI detection. Both sides close with the same purchase: Defender Suite for Business Premium ($10/user/month) or E5 Security ($12/user/month).

After July 2026, E3 gains MDO P1 in the base subscription. The email exposure gap narrows to the P2 delta. The cloud app gap remains unchanged.

Start with one customer tenant. Run a Threat Explorer search for a known indicator, connect DfCA’s cloud discovery, and review the findings. Then scale out.

Part of The MSP License Ladder series. Previous: #3, The Identity Gap.

Last verified: May 2026

Related

• The MSP License Ladder #1: The Hunting Gap – what Defender for Endpoint Plan 2 unlocks for proactive threat hunting across your customer fleet.
• The MSP License Ladder #2: The Data Gap – what Purview Suite unlocks over base Business Premium and E3 for DLP, Insider Risk, and eDiscovery.
• The MSP License Ladder #3: The Identity Gap – what Entra ID P2 and Defender for Identity unlock for risk-based CA, just-in-time privilege, and on-prem AD visibility.
• The MSP License Ladder #5: The Endpoint Gap – what the Intune Suite unlocks for least-privilege elevation, third-party app patching, and device health analytics.

The same customer has four Domain Controllers running on-prem. You check the Defender portal and there is nothing. No identity alerts, no lateral movement paths, no credential theft detections. Not because everything is fine, but because nothing is watching.

Two blind spots, one cloud and one on-prem. That is the identity gap, and the licensing path to closing both sides is usually the same bundle.

This post is part of The MSP License Ladder, a series on what Business Premium and E3 don’t give you, and how to build on top of them. Every post covers one gap: what’s missing from the base SKU, what it costs to close, and what you can actually build with it. Previous: #2, The Data Gap.

A few terms up front:

• PIM (Privileged Identity Management): just-in-time role activation with approval workflows and audit trails. Admins request elevation, use it, and it expires automatically.
• Identity Protection: Microsoft’s risk engine that scores every sign-in and user for anomalies (unfamiliar location, impossible travel, leaked credentials) and feeds those scores into Conditional Access.
• DfI (Defender for Identity): an identity threat detection solution that installs lightweight sensors on Domain Controllers to detect on-prem attacks like lateral movement, Kerberoasting, and DCSync.
• CA (Conditional Access): policy engine that controls access based on conditions like location, device compliance, group membership, and (with P2) risk level.

Table of Contents

• What you actually get today
• The concrete gaps: cloud identity
• The concrete gaps: on-prem identity
• The upgrade paths
• What you unlock
• When not to bother
• How to pitch it
• Conclusion

What you actually get today

Business Premium and Microsoft 365 E3 both include Entra ID P1. That gives you more than most customers realise:

• Conditional Access with conditions for location, device compliance, client app, and group membership
• MFA with all verification methods (Authenticator, phone, SMS, FIDO2, certificate-based)
• Self-service password reset with on-prem writeback
• Application Proxy for publishing on-prem web apps without a VPN
• Custom roles and Administrative Units for scoped delegation
• Hybrid identity via Entra Connect or Cloud Sync

For most customer conversations, P1 sounds like it covers identity. The gaps only show up when you need identity to react to risk (risk-based Conditional Access), govern privilege (PIM, Access Reviews), or see on-prem AD (Defender for Identity). All three sit behind upgrades.

And that last point is worth repeating: neither base SKU includes any on-prem identity visibility. Entra ID sees cloud sign-ins. If the customer has Domain Controllers, the entire on-prem identity layer is invisible to the Defender portal without Defender for Identity. Defender for Business, which ships with Business Premium, is an endpoint security solution (NGAV, basic EDR, ASR). It does not cover identity on Domain Controllers. That requires a separate product.

The concrete gaps: cloud identity

Four scenarios that come up on real customer calls and leave you reaching for something you do not have.

Risk-based Conditional Access

A user signs in from their regular laptop at 3am from a country they have never visited. On P1, you can write a CA policy that blocks that country entirely, but you cannot distinguish “same user, anomalous pattern” from “stolen credential on a compliant device.” Risk-based Conditional Access uses Identity Protection’s sign-in risk and user risk scores to make that distinction. The flexibility goes beyond just MFA:

• A medium-risk sign-in can trigger step-up MFA
• A high-risk user can be forced to reset their password
• A high-risk sign-in from an admin account can block access entirely
• You can combine risk with other conditions: block high-risk sign-ins to sensitive apps, require compliant devices for medium-risk, and let low-risk through with MFA

That last point matters. For admin accounts, you can write a CA policy that says “if the sign-in risk is high, block access, no exceptions.” That is a hard stop on compromised admin credentials. On Entra ID P1, those risk conditions do not exist in the CA policy editor.

Privileged Identity Management

Every admin account with permanent Global Admin, Exchange Admin, or Intune Admin has standing privilege 24/7. If an account is compromised, the attacker gets the role immediately and fully. PIM replaces standing privilege with just-in-time activation: an admin requests the role, optionally gets approval, activates it for a bounded window (say 4 hours), and then the role expires. Every activation is logged with justification, approver, and duration. On Entra ID P1, PIM does not exist. Every admin keeps their role permanently.

PIM for Groups extends the same just-in-time model to security group and Microsoft 365 group membership. An engineer can be eligible for a group that grants access to a sensitive SharePoint site or an Azure Key Vault, and activate membership only when needed.

Access Reviews

Over time, group memberships drift. The contractor who joined the “Finance - Sensitive Data” group for a three-month project is still a member two years later. Access Reviews create periodic review workflows where group owners or managers confirm that each member still needs access. Members who are not confirmed are automatically removed. This works for group memberships, role assignments, app access, and guest accounts. On Entra ID P1, there is no mechanism for this. Membership cleanup is manual and ad-hoc.

Entitlement Management

A new team member needs access to four groups, two apps, and a SharePoint site. Today that is four separate requests through different channels. Entitlement Management bundles those into an access package: one request, one approval workflow, one expiration policy. Users can request access packages through the My Access portal, and the entire lifecycle (request, approval, assignment, expiration) is managed in one place. Basic Entitlement Management (access packages, multi-stage approvals, self-service requests) is included in Entra ID P2. Advanced features like auto-assignment policies, custom extensions via Logic Apps, and Lifecycle Workflows require the separate Entra ID Governance add-on. On Entra ID P1, none of this exists.

The concrete gaps: on-prem identity

If your customer has Domain Controllers, the on-prem identity layer is invisible to the Defender portal without Defender for Identity. Entra ID sees cloud sign-ins; it does not ingest DC events. Defender for Business (included in Business Premium) does not fill this gap either. Defender for Business is focused on endpoint protection: next-generation antivirus, attack surface reduction, and basic EDR. It does not deploy sensors on Domain Controllers and does not monitor Active Directory traffic. Here is what you are missing without DfI:

Reconnaissance detection

Before attackers move laterally, they map the environment. DfI detects account enumeration via LDAP, DNS zone transfer attempts, SAMR-based user and group discovery, and security principal reconnaissance that often precedes a Kerberoasting attack. It also triggers on any activity targeting honeytoken accounts you have configured as decoys.

Credential theft attacks

Kerberoasting (requesting service tickets for offline cracking), AS-REP roasting (targeting accounts without pre-authentication), and DCSync (requesting AD replication data to extract password hashes). DfI also detects brute force attacks over Kerberos and NTLM, DPAPI master key requests (used to decrypt saved credentials), DFSCoerce attacks, and shadow credential abuse. These are the attacks that turn a foothold into full domain compromise.

Lateral movement and domain dominance

Pass-the-hash, pass-the-ticket, and overpass-the-hash are the classic lateral movement techniques. DfI detects all three, plus NTLM relay attacks, PrintNightmare exploitation, SMB packet manipulation, and Exchange Server remote code execution attempts. For domain dominance, DfI covers Golden Ticket usage (five different detection methods, including encryption downgrade, time anomaly, and RBCD-based), DCShadow (rogue domain controller promotion and replication), Skeleton Key malware, and SID-History injection.

Active Directory infrastructure attacks

DfI monitors beyond user activity. It detects suspicious modifications to AdminSdHolder (the security descriptor that protects privileged accounts), AD Certificate Services abuse (ESC8 attacks, certificate database deletions, audit filter tampering), AD FS trust relationship modifications, and Resource-Based Constrained Delegation abuse. It also flags Group Policy tampering that disables Windows Defender, a common precursor to ransomware deployment.

Legacy protocol usage

NTLM authentication, LDAP cleartext binds, and SMBv1 are still active in 2026 more often than anyone likes to admit. DfI surfaces this usage through its identity security posture assessments in Microsoft Secure Score, so you can plan the remediation instead of discovering it during an incident.

On base Entra ID P1, none of this is visible. The Defender portal shows endpoint and email telemetry, but the on-prem side of the identity gap is a complete blind spot.

The upgrade paths

Three paths to close both gaps, depending on the customer’s base SKU and size.

Prices are Microsoft list per user per month, as of May 2026. CSP, NCE, and Enterprise Agreement pricing differs; check with your licensing partner for the real customer number. Combined with Purview Suite for Business Premium (also $10), the bundle drops to $15/user/month for both Defender and Purview.

The bundle story is strong here. Buying Entra ID P2 ($9) and DfI ($5.50) standalone costs $14.50/user/month and only covers identity. For $10/user/month the Defender Suite for BP gives you both plus MDE P2, MDO P2, and DfCA. Unless the customer specifically cannot take the other Defender components (rare), the bundle is the better path.

The grey-area licensing caveat

Entra ID P2 features follow a per-user-covered licensing model, not per-tenant-enabled. This matters:

• Identity Protection risk engine activates tenant-wide once a single P2 license is present. Risk-based CA policies evaluate all sign-ins, not just licensed users. Compliance-wise, Microsoft requires a P2 license for every user whose sign-ins are evaluated by risk policies.
• PIM activates tenant-wide. Compliance-wise, every user with eligible or time-bound role assignments, every approver, and every reviewer needs P2. If the license expires, eligible assignments are removed and PIM becomes unavailable.
• Access Reviews follow the same pattern: every user being reviewed and every reviewer needs the license.

This is the same grey area covered in Post #2 for Purview. The features work with fewer licenses than compliance requires. Do not let a customer assume one P2 license turns it on for the tenant.

Entra ID Governance: a separate SKU

If the customer’s governance needs go beyond basic PIM and Access Reviews, there is a separate Entra ID Governance add-on (~$7/user/month on top of P1 or P2). It adds:

• Lifecycle Workflows: automated onboarding and offboarding (pre-hire provisioning, day-one group assignment, leaver account cleanup). This is the “joiner-mover-leaver” automation that P2 does not cover.
• Advanced Access Reviews: includes ML-assisted recommendations that analyze user-to-group affiliation patterns and flag members who are outliers compared to their peers, so reviewers can focus on the memberships that are most likely stale instead of reviewing every entry manually. Also adds scoping to inactive users and Access Reviews for PIM for Groups.
• Advanced Entitlement Management: auto-assignment policies (assign access packages based on department or cost center without a request), custom extensions via Logic Apps, Verified ID integration, and separation of duties enforcement.

Microsoft has explicitly stated: no new Identity Governance and Administration features will be added to the P2 SKU. Current P2 features (PIM, basic Access Reviews, basic Entitlement Management) stay, but everything new goes into the Governance add-on. If a customer is building a full identity governance program, budget for it.

For more detail, see the Entra ID Governance licensing fundamentals.

What you unlock

With Entra ID P2 and Defender for Identity in place, outcomes across both domains:

The practical difference: the admin accounts from the opening of this post activate Global Admin through PIM for 2 hours with approval and justification, then the role expires. Access Reviews run quarterly to confirm who still needs admin eligibility. The DCs now have DfI sensors, and a pass-the-hash attempt triggers an alert in the Defender portal within minutes, correlated with the endpoint telemetry from MDE. You see both the cloud and on-prem sides of identity in one place.

When not to bother

No Domain Controllers? Skip Defender for Identity. If the customer is pure-cloud, Defender for Identity does nothing. No DCs, no sensors, no detections. The identity gap for cloud-only tenants is entirely Entra ID P2. If DfI comes along as part of the Defender Suite bundle, fine, but never sell it standalone to a cloud-only customer.

DfI standalone is almost never the right buy. At $5.50/user/month it covers one gap. The Defender Suite for BP at $10/user/month covers five. Pitch the bundle.

How to pitch it

Focus on addressing the customer’s specific risks rather than listing features.

Post-audit finding. “Your current setup has fifteen accounts with permanent Global Admin and no review process. PIM replaces standing privilege with just-in-time activation: the admin requests the role, it’s approved, and it expires in four hours. Access Reviews run quarterly to confirm who still needs eligibility. Every activation and review decision is logged. That closes the audit finding and gives you an ongoing governance trail.”

Regulatory driver. “NIS2 Article 21 requires access control measures including privilege management. DORA Article 9 requires identity and access management. ISO 27001 A.9 covers privileged access. Risk-based CA and PIM satisfy all three. The audit artefact is the PIM activation log and the Identity Protection risk report.”

On-prem identity. “You have four DCs. Right now, a Kerberoasting attempt or a DCSync attack generates zero signal in the Defender portal. Defender for Identity puts lightweight sensors on those DCs and feeds alerts into the same incident view as your endpoint and email telemetry. It detects over 40 attack types, from reconnaissance all the way to domain dominance. It’s the cheapest visibility upgrade on the entire ladder.”

Price it as a managed identity service, not a licence passthrough. The $10/user/month Defender Suite for BP is the floor. The value is the PIM configuration, the CA policies tuned to risk, the DfI deployment across customer DCs, and the triage capacity behind the alerts.

Conclusion

Entra ID P1 covers the fundamentals: Conditional Access, MFA, hybrid identity. It is a solid baseline. But three gaps remain:

• It cannot react to risk. Sign-in anomalies, leaked credentials, and impossible travel generate no signal in P1. Risk-based Conditional Access in P2 closes this gap, with the flexibility to step up MFA, force password resets, or block access entirely depending on the risk level and the user’s role.
• It cannot govern privilege. Every admin keeps their role permanently. PIM in P2 replaces standing privilege with just-in-time activation. Access Reviews add periodic confirmation that memberships and role assignments are still justified.
• It cannot see on-prem AD. Domain Controllers are invisible to the Defender portal without Defender for Identity. DfI adds 40+ detection types covering the full attack chain from reconnaissance through domain dominance.

Both the cloud and on-prem identity gaps usually get closed with the same purchase. The Defender Suite for Business Premium ($10/user/month) and the E5 Security add-on ($12/user/month) both include Entra ID P2 and Defender for Identity alongside the other Defender components.

Start with one customer tenant. Deploy PIM for the admin accounts, enable a risk-based CA policy in report-only mode, install DfI sensors on the DCs, and run an Access Review on the most sensitive groups. Review the output for a week. Then scale out.

Next up: #4, The Exposure Gap, on what MDO Plan 2 and Defender for Cloud Apps unlock for post-delivery email investigation, OAuth governance, and shadow IT discovery.

Part of The MSP License Ladder series. Previous: #2, The Data Gap. Next: #4, The Exposure Gap.

Last verified: May 2026

Related

• The MSP License Ladder #1: The Hunting Gap – what Defender for Endpoint Plan 2 unlocks for proactive threat hunting across your customer fleet.
• The MSP License Ladder #2: The Data Gap – what Purview Suite unlocks over base Business Premium and E3 for DLP, Insider Risk, and eDiscovery.
• The MSP License Ladder #4: The Exposure Gap – what MDO P2 and Defender for Cloud Apps unlock for post-delivery email investigation and shadow IT discovery.
• The MSP License Ladder #5: The Endpoint Gap – what the Intune Suite unlocks for least-privilege elevation, third-party app patching, and device health analytics.
• How to Secure Your Enterprise Application via PIM – detailed walkthrough of PIM configuration for enterprise apps.

On Business Premium and Microsoft 365 E3, you had no signal for any of that. No alert when the download volume spiked. No block when the USB was mounted. No flag when the email left the tenant. That is the gap this post is about: base Purview covers more than people expect, but the moment data leaves email and files, you are blind.

This post is part of The MSP License Ladder, a series on what Business Premium and E3 don’t give you, and how to build on top of them. Every post covers one gap: what’s missing from the base SKU, what it costs to close, and what you can actually build with it. Previous: #1, The Hunting Gap.

A few terms up front:

• DLP (Data Loss Prevention): policies that detect and protect sensitive content based on patterns, sensitive information types, or trainable classifiers.
• SIT (Sensitive Information Type): a pattern definition (regex, keyword list, or function) that Purview uses to identify sensitive data. Examples: credit card numbers, national IDs, IBAN numbers.
• IRM (Insider Risk Management): behavioural analytics that detect risky user activity patterns like unusual download spikes, data exfiltration sequences, or policy violations.

Table of Contents

• What you actually get today
• The concrete gaps
  • DLP scope
  • Insider Risk Management
  • eDiscovery Premium
  • Communication Compliance
  • Records Management
• The upgrade paths
• What you unlock
• How to deploy this across your customer base
  • Step 1: Build the baseline in your own tenant
  • Step 2: Deploy across tenants
  • Step 3: Map the output to frameworks
• When not to bother
• How to pitch it
• Conclusion

What you actually get today

Before jumping to what is missing, be honest about what the base gives you. Both SKUs include more Purview than most customers assume.

Business Premium ships with Purview Information Protection and Purview DLP. You can create sensitivity labels (manual application), build DLP policies that scan Exchange, SharePoint, and OneDrive, and set basic retention policies. That is real data governance. If a user attaches a spreadsheet with 50 credit card numbers to an email, base DLP can catch it.

Microsoft 365 E3 has a similar shape. Manual sensitivity labels, DLP for email and files, basic retention and data lifecycle management. Slightly broader admin tooling but the same ceiling on scope.

The gap is not “you have nothing.” The gap is scope, automation, and workflow tooling. Here is what that looks like side by side:

*Teams DLP is a grey area on both Business Premium and E3. The Purview portal lets you enable “Teams chat and channel messages” as a DLP location, and the policy will enforce. But Microsoft’s licensing docs state that DLP for Teams chat requires E5 or equivalent. Microsoft’s Purview Licensing Guidance is explicit about why:

“Some services check for a license before granting access or allow you to restrict access to licensed users via your admin portal. Others may not enforce this yet but could in the future. You must appropriately license the use of a service regardless of technical enforcement.”

This is the same per-user-covered pattern as Entra ID P2: the feature activates tenant-wide, but compliance requires every scoped user to be licensed. If you rely on it without the E5 licence, an audit could flag it. Files shared in Teams are a different story: those live in SharePoint/OneDrive and are covered by base DLP regardless.

**Copilot DLP: if users on Business Premium or E3 have a Microsoft 365 Copilot license, they get DLP for the M365 Copilot location (prompt safeguarding). The full Copilot-aware DLP (restricting Copilot from processing sensitive files and emails) requires the Purview Suite add-on.

Base DLP covers email and files. Teams chat DLP works in practice on Business Premium and E3 but is not officially licensed there. Endpoints, third-party cloud apps, and browsers are firmly out of scope. Auto-labelling does not exist. Insider Risk Management, eDiscovery Premium, Communication Compliance, and Records Management are all locked behind the next tier.

For the full breakdown of what each SKU includes, see the Microsoft Purview service description.

The concrete gaps

Five scenarios that come up on real customer calls and leave you reaching for something you do not have.

DLP scope

Your DLP policies scan email and files in Exchange, SharePoint, and OneDrive. An employee pastes a client’s bank details into a Teams chat. Another copies a PII spreadsheet to a USB stick. A third uploads customer data to a personal Dropbox via the browser. Base Purview does not see any of it. Teams chat DLP, endpoint DLP, and cloud app DLP are all out of scope on Business Premium and E3.

Auto-labelling is the other half of this gap. On base SKUs, sensitivity labels are manual only. If users forget to label (and they will), the data sits unclassified and unprotected. Auto-labelling based on content inspection closes that loop.

A note on USB controls via Intune. You do not need Purview Suite to block USB writes entirely. Intune offers three options on its own:

These are not DLP features. They do not inspect content. They are blanket or device-level blocks that only apply to Intune-managed devices. Unmanaged devices, BYOD, and anything not enrolled are unaffected. Endpoint DLP in Purview Suite is the content-aware layer: it knows what is in the file and decides based on sensitivity, not just the destination.

Insider Risk Management

A departing employee downloads 50% more files than usual in their last two weeks. A contractor accesses a SharePoint site they have never touched before and exports its contents. On base Purview, these patterns generate no signal. Insider Risk Management uses behavioural analytics to detect sequences like download spikes, access anomalies, and data exfiltration patterns. It can feed into Adaptive Protection, which automatically tightens DLP policies for risky users.

Worth noting: if a leaver is smart, they steal data before handing in their notice, not after. IRM handles this because you can configure the policy timeframe to look back at up to 90 days of past behaviour, surfacing risky activity sequences that happened well before HR was notified. None of this exists below Purview Suite.

eDiscovery Premium

A legal hold needs to include Teams chat, not just mailboxes and SharePoint. A regulatory investigation requires custodian management, advanced review sets, and conversation threading. On base eDiscovery (Standard), you can place holds on mailboxes and sites, but Teams chat coverage, custodian workflows, review sets with analytics, and predictive coding are all Premium features. When the legal team calls, you either have them or you don’t.

Communication Compliance

Regulated sectors (financial services under DORA, healthcare, legal) have obligations to review communications for insider trading language, conflicts of interest, harassment, or regulatory violations. On base Purview there is no mechanism to scan Teams messages, email, or Viva Engage at scale for these patterns. Communication Compliance provides policy-based scanning with built-in classifiers for threat, harassment, discrimination, and regulatory language. Without it, the compliance team is relying on manual spot checks.

Records Management

Base retention policies are time-based: keep everything for X years, then delete. Real records management needs a file plan, event-based retention (start the clock when a contract ends, not when the file was created), and disposition review before deletion. On base Purview you get the timer. You do not get the workflow.

The upgrade paths

Two paths to close the data gap, depending on the customer’s base SKU and budget.

Prices are Microsoft list per user per month, as of April 2026. CSP, NCE, and Enterprise Agreement pricing differs. Check with your licensing partner for the real customer number.

The Purview Suite add-on is available for both Business Premium and E3 customers. It launched September 2025 and adds the full Purview feature set: DLP extended to endpoints, Teams, apps, and cloud; Insider Risk Management; eDiscovery Premium; Records Management; Communication Compliance; Audit Premium; Compliance Manager; Information Barriers; Privileged Access Management; Customer Lockbox; Customer Key; and policy-based controls for Copilot and AI experiences. For the full contents, see the Microsoft Purview Suite for Business Premium page.

Combined with Defender Suite for Business Premium (also $10), the bundle drops to $15/user/month for both, versus $20 if bought separately. If the customer needs both security and compliance (and most do), this is the value pick.

One caveat. Purview features are per-user-covered, not per-tenant-enabled. The features activate once licensed somewhere in the tenant, but compliance-wise every user whose activity is covered by DLP, IRM, eDiscovery, or Communication Compliance needs the license. An IRM policy scoped to “all users” means all users need the license. Do not let a customer assume one license turns it on for the tenant. This is the same grey-area pattern as Entra ID P2 and it comes up in audits.

What you unlock

Outcomes, not features. With the Purview Suite add-on in place:

The practical difference: a single policy that says “block credit card numbers from leaving the tenant” now actually means everywhere. The leaving-with-data scenario from the opening of this post generates an IRM alert before the damage is done. When the legal team calls for a hold that includes Teams chat, you have the workflow. When the auditor asks for disposition proof, you have event-based retention with reviewed disposal.

How to deploy this across your customer base

The scenario: you manage 15 customer tenants. You need a consistent DLP baseline across all of them, and you need proof that each tenant satisfies the relevant framework controls. The approach: build once in your own tenant, then replicate.

Step 1: Build the baseline in your own tenant

Start in your MSP tenant or a dedicated baseline tenant. This is your template environment. Configure the DLP policies you want every customer to have:

For each policy, configure the locations (Exchange, SharePoint, OneDrive, and Teams/Endpoints if the customer has Purview Suite), the detection thresholds, and the actions (block or notify). Test the policies in simulation mode first. Purview’s simulation mode shows you what would trigger without enforcing, so you can tune the thresholds before going live.

A few design decisions worth making upfront:

• PII and payment card data get hard blocks. These are the highest-risk categories. A false positive is cheaper than a breach.
• Health and financial data start as notify-only. These have more partial-match noise. Set a minCount threshold of 2 or higher and tighten after you have real data on false positive rates.
• Tag every policy with the framework controls it satisfies. Use the policy description field or a separate tracking sheet. When the auditor asks “how do you satisfy NIS2 Article 21(2)(d)?”, the answer should be a row in a table, not a slide deck.

Step 2: Deploy across tenants

Once the baseline is working in your template tenant, the next step is rolling it out to every customer. You can do this manually per tenant, script it with PowerShell (Post #1 showed the multi-tenant GDAP pattern), or use a multi-tenancy tool.

A tool I use for this is Inforcer. It is a multi-tenancy platform for MSPs that connects to customer tenants through enterprise app registrations (manual onboarding or GDAP). You deploy your baseline policy set across tenants from one place, and when you later change a policy, Inforcer flags which tenants are out of alignment so you can push the update. It takes the manual per-tenant work out of the equation.

Step 3: Map the output to frameworks

Whether you deploy via Inforcer or PowerShell, the end result should be the same: a coverage matrix that shows which policies satisfy which controls in which tenants.

That is the audit artefact. Export it as a CSV, attach it to the customer’s compliance record, and move on. When the next audit cycle comes, re-export and diff.

When not to bother

Purview Suite rewards customers who already care about data governance. Two cases where the upgrade sits idle:

No data classification scheme. If the customer has no idea what data they have, where it lives, or who should access it, deploying DLP policies generates noise, not protection. Start with a data classification exercise. Map the sensitive data types that actually exist in their tenant, decide what “sensitive” means for their business, and then deploy policies to enforce it. Purview Suite is the automation layer once the program exists, not the starting point.

No one to triage. IRM signals, Communication Compliance alerts, and eDiscovery workflows all require human review. If the customer has no compliance function, no legal team, and no appetite to build one, you are licensing tooling that will generate alerts nobody reads. That is worse than not having it, because unreviewed alerts create liability. If they are not ready to staff the process, they are not ready for the tooling.

How to pitch it

Lead with a regulatory obligation, a post-incident trigger, or an audit finding. Do not lead with “data is important.”

Three openers that work:

• Regulatory driver. “NIS2 Article 21 requires measures for data handling and access control. Your current DLP covers email and files. It does not cover endpoints, Teams, or cloud apps. Purview Suite closes that scope gap and gives you a framework-mapped artefact to show the auditor.”

• Post-incident trigger. “The data leak last quarter was a USB copy that base DLP could not see. Endpoint DLP would have blocked it. IRM would have flagged the download spike before the USB was even mounted.”

• Audit finding. “Your last audit flagged that retention policies are time-based only, with no disposition review. Records Management in Purview Suite adds file plans, event-based retention, and reviewed disposal. That closes the finding.”

Price it as part of a managed governance service, not a licence passthrough. The $10/user/month is the floor. The value is the baseline you deploy across every customer, the framework-mapped coverage matrix, and the triage capacity behind the alerts.

Conclusion

Business Premium and E3 give you more Purview than most people realise. You can label, you can DLP email and files, you can retain. But the moment data moves to an endpoint, a browser, or a cloud app, base Purview stops watching. The employee from the opening of this post walks out with the data, and you find out from the customer’s competitor.

The Purview Suite add-on ($10/user/month) closes that gap. Build a baseline policy set in your own tenant, validate it in simulation mode, deploy it across your customers, and keep it aligned. When the auditor asks what controls you satisfy, hand them the framework matrix instead of a conversation.

Start with one customer tenant. Get the SIT detections right for their data. Then scale out.

Next up: #3, The Identity Gap, on what Entra ID P2 and Defender for Identity unlock across your cloud and on-prem identity surface, and why they are almost always bought together.

Part of The MSP License Ladder series. Previous: #1, The Hunting Gap. Next: #3, The Identity Gap.

Last verified: April 2026

Related

• The MSP License Ladder #1: The Hunting Gap – what Defender for Endpoint Plan 2 unlocks for proactive threat hunting across your customer fleet.
• The MSP License Ladder #3: The Identity Gap – what Entra ID P2 and Defender for Identity unlock for risk-based CA, just-in-time privilege, and on-prem AD visibility.
• The MSP License Ladder #4: The Exposure Gap – what MDO P2 and Defender for Cloud Apps unlock for post-delivery email investigation and shadow IT discovery.
• The MSP License Ladder #5: The Endpoint Gap – what the Intune Suite unlocks for least-privilege elevation, third-party app patching, and device health analytics.

On Microsoft 365 Business Premium and Microsoft 365 E3, you cannot answer those questions across the fleet. That is the shift this post is about: reactive security (an alert fires, you respond) versus proactive security (you hunt for the setup steps before the detonation). Microsoft Defender for Endpoint Plan 2 is the rung that flips that switch.

A few terms up front:

• IoC (Indicator of Compromise): a file hash, IP, domain, or process pattern tied to known malicious activity. When a vendor or CERT publishes a breach, they usually publish IoCs so you can sweep your own estate.
• KQL (Kusto Query Language): the query language the Defender portal and Advanced Hunting use.
• EDR (Endpoint Detection and Response): tooling that records endpoint activity and lets you query it afterwards, not just block the bad stuff.
• NGAV (Next-Generation Antivirus): behaviour-based AV. The “block it” layer.

Table of Contents

• Reactive by default
• The proactive gap
  • Post-incident reconstruction
  • Retrospective IoC sweep
  • The custom detection you want to keep running
• The upgrade paths
• What Defender for Endpoint Plan 2 gives you
• Demo: multi-tenant local admin hunt
  • The KQL
  • The PowerShell script
  • The Azure DevOps pipeline
• When not to bother
• How to pitch it
• Conclusion

Reactive by default

Business Premium ships with Defender for Business. NGAV, Attack Surface Reduction rules, basic EDR with alerts and automated investigation, device isolation, web content filtering, 30-day retention. Solid at the block-and-alert layer.

Microsoft 365 E3 ships with Defender for Endpoint Plan 1. NGAV and Attack Surface Reduction only. No hunting surface at all. Without an add-on, Microsoft 365 E3 is a weaker endpoint posture than Business Premium.

Both are reactive. An alert fires, you respond. Neither lets you ask your fleet a question the product did not think to ask on your behalf.

The proactive gap

Three scenarios that come up on real customer calls and leave you reaching for something you do not have.

Post-incident reconstruction

Defender caught the malware. Now you want to rebuild the story. Was a local admin added before detonation? Did a process elevate? On Defender for Business you can stare at the per-device timeline, but you cannot run a single KQL query that joins admin additions with logons with process events across every device.

Retrospective IoC sweep

A partner drops an IoC list. You want to know if any device in any customer tenant has ever seen those hashes, domains, or IPs. On Defender for Business you can search alerts. You cannot run a cross-fleet KQL query, and that is what an IoC sweep actually is.

The custom detection you want to keep running

You notice a subtle pattern unique to one of your customers’ stacks. You want a rule that alerts the moment it reappears, anywhere. Defender for Business has no Custom Detection Rules. You are stuck with Microsoft’s built-in detections plus Attack Surface Reduction.

Every one of those is a proactive question. Base SKUs answer the reactive ones and leave the proactive ones on the floor.

The upgrade paths

Prices are Microsoft list per user per month, as of April 2026. CSP, NCE, and Enterprise Agreement pricing differs; check with your licensing partner for the real customer number. Defender Suite for Business Premium is the value pick at roughly 65% cheaper than buying its components individually. Combined with Purview Suite for Business Premium (also $10), the bundle drops to $15/user/month for both.

One caveat. Defender for Business and Defender for Endpoint Plan 2 cannot coexist in the same tenant. If both licence types are present, the tenant defaults to Defender for Business. To actually get Defender for Endpoint Plan 2, every user needs a Defender for Endpoint Plan 2 licence and you must open a Microsoft Support ticket to switch the experience. Plan this as a tenant-wide flip, not a phased migration. See the Defender for Business FAQ for the official word.

What Defender for Endpoint Plan 2 gives you

What it gives you:

• Advanced Hunting: 30 days of raw, KQL-queryable telemetry across every device. Tables you will use most: DeviceEvents, DeviceLogonEvents, DeviceProcessEvents, DeviceFileEvents, DeviceNetworkEvents, DeviceRegistryEvents.
• 180-day device timeline for deep-dive investigations on a specific device.
• Custom Detection Rules: your own KQL turned into automated detections and response actions. Runs in near real time for supported detections. This is where proactive lives.
• Live Response: an interactive shell into a device during an investigation. Grab files, run scripts, collect memory samples.
• Graph Threat Hunting API (runHuntingQuery) with the ThreatHunting.Read.All permission. This is what makes multi-tenant automation possible.
• Full Threat and Vulnerability Management and Microsoft Threat Experts (opt-in).

Demo: multi-tenant local admin hunt

The scenario: after an incident at one customer, run the same hunting query across every customer tenant you manage. Post-incident reconstruction for the affected tenant, proactive sweep for the rest.

Shout-out to Damien Van Robaeys here. His post on hunting devices with local admin accounts via Defender for Endpoint already nailed the KQL side of this, so I am not reinventing the wheel on the query itself. What I am adding is the process around it: how to take a single-tenant, portal-driven hunt and wrap it so it runs across every customer tenant you manage, from a single script. Go read his original for the deep dive on the query logic, then come back here for the multi-tenant plumbing.

Requirements:

• A multi-tenant app registration in your MSP tenant with application permission ThreatHunting.Read.All.
• A certificate (self-signed or from your PKI) uploaded to the app registration.
• Admin consent granted in each customer tenant via the admin consent URL:

  https://login.microsoftonline.com/{customer-tenant-id}/adminconsent?client_id={your-app-id}
  

• An Azure DevOps project with two variable groups:
  • defender-hunt - auth only: CLIENT_ID, CERT_THUMBPRINT, CERT_PASSWORD (marked secret). A Secure File holds the .pfx.
  • customer-tenants - the fleet: one variable per tenant, using the convention TENANT_<ShortName> with the tenant’s directory ID as the value. For example TENANT_A = <TENANT_ID>, TENANT_B = <TENANT_ID>. Add a tenant by adding a row; remove one by deleting it. Splitting this group from the auth group means every future workflow - licensing sweeps, policy audits, backup checks - reuses the same tenant list without duplicating it.
• PowerShell 7 on the pipeline agent and the Microsoft.Graph.Authentication module.

Keeping the tenant list in a shared variable group means no customer data in the repo, and the script has no file dependencies. Everything it needs comes from $env.

The KQL

Local admin additions in the last 7 days, joined with interactive logons by the same account on the same device. One pass answers “was a new admin added, and has it been used”:

let timeWindow = 7d;
let adminAdds =
    DeviceEvents
    | where Timestamp > ago(timeWindow)
    | where ActionType == "UserAccountAddedToLocalGroup"
    | where AdditionalFields has "Administrators"
    | extend AddedAccount = tostring(parse_json(AdditionalFields).AccountName)
    | project AddTime = Timestamp, DeviceId, DeviceName, AddedAccount,
              AddedBy = InitiatingProcessAccountName,
              AddedByProcess = InitiatingProcessFileName;
let interactiveLogons =
    DeviceLogonEvents
    | where Timestamp > ago(timeWindow)
    | where LogonType in ("Interactive", "RemoteInteractive")
    | summarize LogonCount = count(), LastLogon = max(Timestamp)
        by DeviceId, AccountName;
adminAdds
| join kind = leftouter interactiveLogons
    on $left.DeviceId == $right.DeviceId
   and $left.AddedAccount == $right.AccountName
| project AddTime, DeviceName, AddedAccount, AddedBy, AddedByProcess, LogonCount, LastLogon
| order by AddTime desc

The PowerShell script

Commit this as scripts/Invoke-LocalAdminHunt.ps1 in the Azure DevOps repo. It reads everything from $env, loops the tenants, runs the hunting query, and prints results. No parameters, no file dependencies, no secrets on disk.

# scripts/Invoke-LocalAdminHunt.ps1
# Inputs (all from pipeline env vars, set via variable groups):
#   CLIENT_ID       - App registration client ID
#   CERT_THUMBPRINT - Thumbprint of the cert already imported into CurrentUser\My
#   TENANT_*        - One env var per customer tenant, from the customer-tenants
#                     variable group. Key is TENANT_<ShortName>, value is the
#                     tenant directory ID. Example: TENANT_Contoso = <guid>.

Install-Module Microsoft.Graph.Authentication -Scope CurrentUser -Force
Import-Module Microsoft.Graph.Authentication

$ClientId   = $env:CLIENT_ID
$Thumbprint = $env:CERT_THUMBPRINT

$tenants = Get-ChildItem Env: |
    Where-Object { $_.Name -like 'TENANT_*' } |
    ForEach-Object {
        [PSCustomObject]@{
            Name = $_.Name -replace '^TENANT_',''
            Id   = $_.Value.Trim()
        }
    }

$query = @'
let timeWindow = 7d;
let adminAdds =
    DeviceEvents
    | where Timestamp > ago(timeWindow)
    | where ActionType == "UserAccountAddedToLocalGroup"
    | where AdditionalFields has "Administrators"
    | extend AddedAccount = tostring(parse_json(AdditionalFields).AccountName)
    | project AddTime = Timestamp, DeviceId, DeviceName, AddedAccount,
              AddedBy = InitiatingProcessAccountName,
              AddedByProcess = InitiatingProcessFileName;
let interactiveLogons =
    DeviceLogonEvents
    | where Timestamp > ago(timeWindow)
    | where LogonType in ("Interactive", "RemoteInteractive")
    | summarize LogonCount = count(), LastLogon = max(Timestamp)
        by DeviceId, AccountName;
adminAdds
| join kind = leftouter interactiveLogons
    on $left.DeviceId == $right.DeviceId
   and $left.AddedAccount == $right.AccountName
| project AddTime, DeviceName, AddedAccount, AddedBy, AddedByProcess, LogonCount, LastLogon
| order by AddTime desc
'@

$results = New-Object System.Collections.Generic.List[object]

foreach ($tenant in $tenants) {
    try {
        Connect-MgGraph -ClientId $ClientId `
                        -CertificateThumbprint $Thumbprint `
                        -TenantId $tenant.Id `
                        -NoWelcome

        $body = @{ Query = $query } | ConvertTo-Json -Depth 3

        $response = Invoke-MgGraphRequest -Method POST `
            -Uri 'https://graph.microsoft.com/v1.0/security/runHuntingQuery' `
            -Body $body -ContentType 'application/json'

        foreach ($row in $response.results) {
            $results.Add([PSCustomObject]@{
                Tenant       = $tenant.Name
                TenantId     = $tenant.Id
                AddTime      = $row.AddTime
                DeviceName   = $row.DeviceName
                AddedAccount = $row.AddedAccount
                AddedBy      = $row.AddedBy
                Process      = $row.AddedByProcess
                LogonCount   = $row.LogonCount
                LastLogon    = $row.LastLogon
            })
        }
    }
    catch {
        Write-Warning "Tenant $($tenant.Name) [$($tenant.Id)]: $_"
    }
    finally {
        Disconnect-MgGraph | Out-Null
    }
}

Write-Host "$($results.Count) matches across $($tenants.Count) tenants"
$results | Format-Table -AutoSize

# From here, it is up to the admin how to follow this up. Pick whatever fits
# your stack: post $results to a Teams or Slack webhook, fire off a
# Send-MailMessage / Graph sendMail digest, open a ticket in your PSA
# (HaloPSA, Autotask, ConnectWise) via its REST API, push to Log Analytics,
# or hand off to a Logic App. The script gets the data out of Defender;
# how it lands in your triage workflow is your call.

The Azure DevOps pipeline

With the script in the repo, the pipeline stays small. It downloads the certificate, imports it into the agent’s store, and calls Invoke-LocalAdminHunt.ps1 with the variable groups attached so the script sees everything it needs on $env.

# azure-pipelines.yml
trigger: none

schedules:
  - cron: "0 6 * * *"
    displayName: Daily multi-tenant local admin hunt
    branches:
      include: [ main ]
    always: true

pool:
  vmImage: windows-latest

variables:
  - group: defender-hunt
  - group: customer-tenants

steps:
  - task: DownloadSecureFile@1
    name: huntCert
    displayName: Download certificate
    inputs:
      secureFile: 'defender-hunt.pfx'

  - task: PowerShell@2
    displayName: Import certificate into CurrentUser\My
    inputs:
      targetType: inline
      pwsh: true
      script: |
        $pwd = ConvertTo-SecureString '$(CERT_PASSWORD)' -AsPlainText -Force
        Import-PfxCertificate -FilePath "$(huntCert.secureFilePath)" `
                              -CertStoreLocation Cert:\CurrentUser\My `
                              -Password $pwd | Out-Null

  - task: PowerShell@2
    displayName: Run multi-tenant hunt
    inputs:
      filePath: scripts/Invoke-LocalAdminHunt.ps1
      pwsh: true

Run the pipeline ad-hoc after an incident. Let the schedule cover the daily proactive sweep. For near real time against a specific tenant, lift the KQL into a Custom Detection Rule in that tenant’s Defender portal. Swap the KQL in the .ps1 for any detection pattern you care about. The pipeline stays the same; the script is the thing you iterate on.

When not to bother

Defender for Endpoint Plan 2 earns its money when someone actually hunts with it. Skip the upgrade when:

• Nobody will triage the output. A daily report no one reads is a paper trail of signal you ignored. Regulators and insurers ask about that.
• The customer already pays for a third-party EDR or MDR. Stacking Defender for Endpoint Plan 2 on top duplicates coverage without displacing the other tool. That said, this can also be a selling point to save money: “You can drop your current EDR and save $X by switching to Defender for Endpoint Plan 2, which gives you the same EDR features plus proactive hunting and better integration with the Microsoft stack.”

How to pitch it

Lead with the customer’s specific risks, not the feature list. Two reliable openers, phrased the way you would actually say them:

• Remember the questions we could not answer after the last incident? Was a new admin added beforehand, did anything elevate to SYSTEM, has that account been used anywhere else? Defender for Endpoint Plan 2 is the licence that lets us answer those - across every device, in a single query.

• Your cyber insurance renewal will ask about EDR, custom detections, and mean time to triage. With Defender Suite for Business Premium you can tick EDR, Custom Detection Rules, and Live Response on a single line, which is easier than arguing about equivalents with the underwriter.

Price it as a managed hunting service, not a licence passthrough. The $10/user/month is the floor. The value is the KQL library you build over time and the triage capacity behind it.

Conclusion

Defender for Endpoint Plan 2 flips MSPs from reactive to proactive. Defender for Business and Plan 1 handle block, alert, respond. Plan 2 hunts the setup step, codifies patterns as Custom Detection Rules, and catches the next attempt before the Monday morning call. Advanced Hunting gives you 30 days of telemetry - tell your customer that ceiling up front.

Test the multi-tenant script in a lab first. Consent one customer tenant, confirm the query works or tweak a bit to your needs, then scale out.

Resources:

• Add Microsoft Defender Suite for Business Premium to your subscription
• Defender for Business FAQ on mixed subscriptions
• Advanced Hunting overview
• runHuntingQuery Graph API reference
• Damien Van Robaeys’s hunting devices with local admin accounts

Next up: #2, The Data Gap, on what Purview Suite and E5 Compliance unlock over base Business Premium and Microsoft 365 E3.

Related

• The MSP License Ladder #2: The Data Gap - what Purview Suite unlocks over base Business Premium and E3 for DLP, Insider Risk, and eDiscovery.
• The MSP License Ladder #3: The Identity Gap - what Entra ID P2 and Defender for Identity unlock for risk-based CA, just-in-time privilege, and on-prem AD visibility.
• The MSP License Ladder #4: The Exposure Gap - what MDO P2 and Defender for Cloud Apps unlock for post-delivery email investigation and shadow IT discovery.
• The MSP License Ladder #5: The Endpoint Gap – what the Intune Suite unlocks for least-privilege elevation, third-party app patching, and device health analytics.
• InforcerCommunity PowerShell Module – multi-tenant M365 automation for MSPs using the Inforcer platform.

Table of Contents

• What is InforcerCommunity?
• What’s New in v0.4.0
• Requirements
• Installation
  • Option 1: From PowerShell Gallery (recommended)
  • Option 2: From source (GitHub)
• Quick Start
• Assessments
  • Single-Tenant Assessment
  • Multi-Tenant Assessment Matrix
  • Assessment Export Options
• Tenant Documentation
• Environment Comparison
• Key Cmdlets and Use Cases
• Output Formats and Filtering
• How to Contribute
• How to Report Bugs
• How to Request a Feature
• Conclusion

What is InforcerCommunity?

InforcerCommunity is a PowerShell script module that talks to the Inforcer REST API.

What it gives you:

• Connect once, query everything: Authenticate with your Inforcer API key and region, then run cmdlets to list tenants, baselines, policies, alignment details, users, and audit events.
• Consistent behavior: All Get-* cmdlets support -Format, -OutputType (PowerShellObject or JsonObject), and -TenantId for filtering. TenantId accepts a numeric ID, Microsoft Tenant ID (GUID), or tenant name.
• No secrets in scripts: The API key is stored as a SecureString in the session; you can pass it once via Connect-Inforcer and then run as many commands as you need.
• Tab completion and help: Every cmdlet has comment-based help; Get-Help Connect-Inforcer -Full and tab completion on parameters (e.g. -EventType on Get-InforcerAuditEvent) work out of the box.
• Pipeline support: Pipe tenants into other cmdlets - e.g. Get-InforcerTenant | Get-InforcerUser or Get-InforcerTenant | Get-InforcerTenantPolicies works out of the box.

Where to find it:

• Source code and issues: https://github.com/royklo/InforcerCommunity
• PowerShell Gallery: https://www.powershellgallery.com/packages/InforcerCommunity

Community project notice: InforcerCommunity was created by me for the community. It is not owned, endorsed, or maintained by Inforcer. It is an independent, community-driven project to make the Inforcer API easier to use from PowerShell. You use it at your own responsibility.

What’s New in v0.4.0

The headline feature in v0.4.0 is compliance assessments - run assessments like Copilot Readiness, CIS Benchmarks, or Essential Eight against one tenant or all of them at once, and get interactive HTML reports or structured data for automation.

v0.4.0 highlights:

• New cmdlet: Get-InforcerAssessment - lists all available assessments (Copilot Readiness, CIS Microsoft 365 Foundations Benchmark, CIS Microsoft Intune for Windows 11 Benchmark, Essential Eight Maturity Level 1, and custom assessments).
• New cmdlet: Invoke-InforcerAssessment - runs an assessment against a tenant and returns detailed per-check results with pass/fail status, violations, warnings, and per-object scores. Accepts assessment names ("Copilot Readiness") and tenant names ("Contoso") directly - no need to look up IDs.
• Multi-tenant mode: Add -MultiTenant to run the assessment against all your tenants in one command, or pass multiple tenant names (e.g. -TenantId "Contoso","Fabrikam","Woodgrove"). See a compliance summary for every tenant and generate a matrix comparison report.
• Interactive HTML reports: -OutputPath report.html generates a self-contained HTML report with collapsible checks, per-object expandable cards showing violations and passes, markdown-rendered remediation steps, search, and filters. Multi-tenant mode generates a full-viewport matrix with sticky columns, horizontal scroll for 100+ tenants, a tenant show/hide dropdown, and a slide-out detail panel.
• CSV and JSON export: -OutputPath report.csv for flat data (UTF-8 no-BOM, ready for Excel), -OutputType JsonObject for structured JSON - both single-tenant and multi-tenant.
• Async with progress: Long-running assessments show progress updates every 10 seconds with human-readable elapsed time (e.g. “3m 16s”). Multi-tenant runs show per-tenant progress and a total elapsed time at the end.

v0.3.x highlights (included):

• Cross-tenant comparison with Compare-InforcerEnvironments - four-tab interactive HTML report with comparison, manual review, duplicates, and deprecated settings.
• Cross-category reconciliation - settings delivered via different Intune template types (Endpoint Security vs Settings Catalog) are now correctly matched by DefinitionId.
• Baseline-scoped comparison - compare only policies in a specific baseline instead of the entire tenant.
• Export-InforcerTenantDocumentation - HTML, Markdown, and Excel output formats with Settings Catalog resolution, Graph integration, baseline and tag filtering.
• Get-InforcerGroup and Get-InforcerRole - Entra ID groups (with search, filter, pagination, and member detail) and directory role definitions.
• Settings Catalog resolution - automatically downloaded and cached from IntuneSettingsCatalogData.
• Connection cmdlets - Connect-Inforcer supports -FetchGraphData for Microsoft Graph and -PassThru for cross-account workflows.

Requirements

• PowerShell 7.0 or later (Windows, macOS, or Linux).
• An Inforcer API key from your Inforcer tenant (Configure > REST API > New API Key).

Installation

Option 1: From PowerShell Gallery (recommended)

Install-Module -Name InforcerCommunity -Scope CurrentUser

Option 2: From source (GitHub)

git clone https://github.com/royklo/InforcerCommunity.git
cd InforcerCommunity
Import-Module ./module/InforcerCommunity.psd1 -Force

Important: When loading from source, always run Import-Module from the repository root and use the path ./module/InforcerCommunity.psd1. If you see errors about a missing file or wrong path, make sure you are in the InforcerCommunity repo root.

Quick Start

After installing the module:

# Connect with your API key (region: uk, eu, us, or anz)
Connect-Inforcer -ApiKey "your-api-key" -Region uk

# List all tenants you have access to
Get-InforcerTenant

# Get alignment details in table format
Get-InforcerAlignmentDetails

# Get users for a tenant (by name, numeric ID, or GUID)
Get-InforcerUser -TenantId "Contoso"

# Get policies for a specific tenant
Get-InforcerTenantPolicies -TenantId 482

# Disconnect when done
Disconnect-Inforcer

You can use Get-Help <CmdletName> -Full for parameters and examples (e.g. Get-Help Get-InforcerUser -Full).

Assessments

Inforcer provides compliance assessments that evaluate your tenant against industry frameworks and readiness checks - things like Copilot Readiness, CIS Microsoft 365 Foundations Benchmark, CIS Microsoft Intune for Windows 11 Benchmark, and Essential Eight Maturity Level 1. With InforcerCommunity, you can run these assessments from the command line and get structured results you can automate with.

Single-Tenant Assessment

Run an assessment against one tenant and see every check with its pass/fail status:

# List available assessments
Get-InforcerAssessment

# Run Copilot Readiness against a tenant (by name)
Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness"

The output shows a compliance summary followed by each check as a pipeline object:

  Copilot Readiness - 76.2% compliant (16/21 checks passed)

Status           : Pass
name             : Enable Conditional Access policies to block legacy authentication
category         : Entra
subCategory      : Conditional Access
importance       : High
ObjectsEvaluated : 13
FindingsMessage  : 1 out of 13 object(s) are fully-compliant with this check
Scores           : {@{objectId=de66f385...; score=100; objectName=Core - Block - Legacy Authentication; ...}, ...}

Each check includes a Scores property with per-object detail - which Conditional Access policy passed, which failed, and why. You can drill into this:

$results = Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness"

# See only failed checks
$results | Where-Object Status -eq 'Fail'

# Table view
$results | Format-Table Status, name, category, importance

# Drill into violations for a specific check
$results[1].Scores | Where-Object { $_.violations.Count -gt 0 } | Select-Object objectName, score, violations

Generate an interactive HTML report with one parameter:

Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness" -OutputPath ./copilot-report.html

The HTML report includes a navy cover banner, compliance score ring, collapsible check cards grouped by category (Entra, Exchange, M365, Purview, SharePoint), per-object expandable cards showing violations and passes, and markdown-rendered description and remediation steps. Everything is self-contained - no external dependencies, works offline.

Multi-Tenant Assessment Matrix

The real power comes when you run an assessment across all your tenants at once:

# Run against all tenants
Invoke-InforcerAssessment -AssessmentId "Copilot Readiness" -MultiTenant -OutputPath ./matrix.html

# Or pick specific tenants by name
Invoke-InforcerAssessment -TenantId "Contoso","Fabrikam","Woodgrove" -AssessmentId "Copilot Readiness" -OutputPath ./matrix.html

The cmdlet runs each tenant sequentially with progress updates:

Multi-tenant assessment: 'Copilot Readiness' across 10 tenant(s)

[1/10] Running 'Copilot Readiness' against Contoso...
  Still running... 10s elapsed
  Completed in 14s.
[2/10] Running 'Copilot Readiness' against Fabrikam...
  Still running... 3m 10s elapsed
  Completed in 3m 16s.
...

All assessments complete. 10 tenant(s) processed in 16m 18s.
  Contoso - 76.2% (16/21)
  Fabrikam - 42.9% (9/21)
  Woodgrove - 38.1% (8/21)
  ...

The matrix HTML report is a full-viewport interactive dashboard: a sticky left column with check names that stays visible while you scroll horizontally across tenant columns, each showing a pass/fail indicator. A tenant filter dropdown lets you show or hide specific tenants (useful when you have 100+ tenants and want to focus on a subset). Click “Details” on any check to open a slide-out panel with the description, impact, and rationale. Category rows group checks by Entra, Exchange, M365, Purview, and SharePoint. Search and status filters (All, Has Failures, All Passed) work across the entire matrix.

Assessment Export Options

All export formats work for both single-tenant and multi-tenant:

# HTML report (single or matrix)
Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness" -OutputPath ./report.html

# CSV for Excel or automation (multi-tenant includes Tenant column)
Invoke-InforcerAssessment -AssessmentId "Copilot Readiness" -MultiTenant -OutputPath ./matrix.csv

# JSON for webhooks, APIs, or further processing
Invoke-InforcerAssessment -AssessmentId "Copilot Readiness" -MultiTenant -OutputType JsonObject

# Pipeline for PowerShell automation (each check has TenantName in multi-tenant mode)
Invoke-InforcerAssessment -AssessmentId "Copilot Readiness" -MultiTenant |
    Where-Object Status -eq 'Fail' |
    Group-Object TenantName |
    Select-Object Name, Count

Tenant Documentation

The new Export-InforcerTenantDocumentation cmdlet generates comprehensive documentation for an entire tenant in one command:

# Generate HTML documentation (opens in browser automatically)
Export-InforcerTenantDocumentation -TenantId "Contoso" -Format Html

# Generate HTML and Excel, with Graph enrichment for group/filter names
Connect-Inforcer -ApiKey "your-api-key" -Region uk -FetchGraphData
Export-InforcerTenantDocumentation -TenantId "Contoso" -Format Html,Excel -OutputPath C:\Reports

# Export only policies from a specific baseline
Export-InforcerTenantDocumentation -TenantId 139 -Baseline "Inforcer Blueprint Baseline - Tier 1" -Format Html

# Filter by tag
Export-InforcerTenantDocumentation -TenantId "Contoso" -Tag "Production" -Format Markdown

HTML output is a self-contained file with no external dependencies - you can email it, archive it, or open it offline. It includes:

• Collapsible Product > Category > Policy navigation in a sidebar
• Real-time search with text highlighting
• Dark/light mode toggle (persisted in localStorage)
• Tag filter pills with AND/OR logic
• Hide empty fields and show metadata toggles
• Collapsible long values and a back-to-top button

Excel output creates a workbook with one sheet per product area. Each row is a policy with columns for category, name, description, platform, settings, and assignments - ready for filtering and analysis.

Markdown output generates a GFM-compatible document with a table of contents and per-policy tables - useful for including in wikis or version-controlled documentation.

Environment Comparison

The new Compare-InforcerEnvironments cmdlet compares two tenants’ Intune configurations and generates an interactive HTML report:

# Compare two tenants in the same Inforcer account
Compare-InforcerEnvironments -SourceTenantId "Contoso" -DestinationTenantId "Fabrikam"

# Compare across different Inforcer accounts with Graph enrichment
$src = Connect-Inforcer -ApiKey $key1 -Region uk -PassThru
$dst = Connect-Inforcer -ApiKey $key2 -Region eu -PassThru
Compare-InforcerEnvironments -SourceTenantId 482 -DestinationTenantId 139 `
    -SourceSession $src -DestinationSession $dst -FetchGraphData

The HTML report includes four tabs:

• Comparison - flat table of all Settings Catalog settings with sortable columns, status filter pills (Matched/Conflicting/Source Only/Dest Only), category dropdown, and advanced column filters with AND/OR logic
• Manual Review - non-Settings-Catalog policies (compliance, enrollment, scripts) in a 50/50 source/destination layout grouped by platform. Matching policy names are aligned side-by-side. Scripts and compliance rules are shown as collapsible code blocks with syntax highlighting
• Duplicates - settings configured in two or more policies with different values, with automated conflict analysis
• Deprecated - settings flagged as deprecated by Microsoft, grouped by source and destination

The report also features an animated configuration match score (with confetti at 100%), dark/light mode toggle, column resize handles, and a responsive layout. Like the Export report, the HTML is fully self-contained with no external dependencies.

Key Cmdlets and Use Cases

Typical workflows:

• Tenant and policy overview: Connect-Inforcer -> Get-InforcerTenant -> Get-InforcerTenantPolicies -TenantId "Contoso" to inspect a specific tenant’s policies.
• Alignment and drift: Get-InforcerAlignmentDetails for score summaries; Get-InforcerAlignmentDetails -BaselineId "Tier 0" for per-policy detail.
• User overview: Get-InforcerUser -TenantId "Contoso" for a user list; Get-InforcerUser -TenantId 139 -UserId "8e61ce11-..." for full detail including groups, roles, devices, and risk.
• Audit and compliance: Get-InforcerAuditEvent with optional -EventType (tab completion for event types), -DateFrom, -DateTo, and paging parameters.
• Tenant documentation: Export-InforcerTenantDocumentation -TenantId "Contoso" -Format Html,Excel to generate a complete configuration snapshot.
• Environment comparison: Compare-InforcerEnvironments -SourceTenantId "Contoso" -DestinationTenantId "Fabrikam" to see every difference between two tenants.
• Group and role lookup: Get-InforcerGroup -TenantId 139 -Search "Finance" for groups, Get-InforcerRole -TenantId 139 | Where-Object IsPrivileged -eq $true for privileged roles.
• Compliance assessment: Invoke-InforcerAssessment -TenantId "Contoso" -AssessmentId "Copilot Readiness" to check a single tenant, or add -MultiTenant -OutputPath matrix.html for a cross-tenant matrix report.
• Pipeline: Get-InforcerTenant -TenantId 139 | Get-InforcerUser to list users for a piped tenant.

For full parameter details and example output, see the Cmdlet Reference in the repository.

Output Formats and Filtering

• -Format: Most Get-* cmdlets support Table or Raw (e.g. for alignment details).
• -OutputType: PowerShellObject (default) or JsonObject (JSON with depth 100) for piping into other tools or export.
• -TenantId: Accepts a numeric Client Tenant ID, a Microsoft Tenant ID (GUID), or a tenant name (case-insensitive match). Use it on Get-InforcerTenant, Get-InforcerTenantPolicies, Get-InforcerAlignmentDetails, Get-InforcerUser, and others.

# Example: export all tenants as JSON for use elsewhere
Get-InforcerTenant -OutputType JsonObject | Out-File tenants.json -Encoding utf8

# Example: search users by name
Get-InforcerUser -TenantId "Contoso" -Search "Adele"

# Example: get full user detail as JSON
Get-InforcerUser -TenantId 139 -UserId "8e61ce11-a45b-42a6-8ca4-1d881781566d" -OutputType JsonObject

How to Contribute

Contributions are welcome. The project uses a standard fork-and-pull-request workflow:

• Fork the repository on GitHub: https://github.com/royklo/InforcerCommunity.
• Clone your fork and create a branch (e.g. feature/your-feature-name or fix/bug-description).
• Make your changes under module/ (see CONTRIBUTING.md for code style and the consistency contract - parameter order, -Format/-OutputType, property names, etc.).
• Run tests from the repo root: Invoke-Pester ./Tests/Consistency.Tests.ps1.
• Commit and push to your fork, then open a pull request against the main repository. Fill in the PR template (summary, how to test, related issue if any).

New cmdlets must be added to module/Public/, registered in FunctionsToExport in the manifest, and documented in docs/CMDLET-REFERENCE.md. The consistency tests must be updated if you add or change exported cmdlets or key parameters.

How to Report Bugs

If something doesn’t work as expected:

• Go to New issue.
• Choose Bug report.
• Fill in:

Description: What went wrong?

• Steps to reproduce: Exact commands or steps.
• Expected behavior: What you expected.
• Actual behavior: What happened instead (including any error messages).
• Environment: PowerShell version, OS, and module version (e.g. Get-Module InforcerCommunity | Select-Object Version).
• Additional context: Logs, screenshots, or other details.

This helps maintainers and the community reproduce and fix issues quickly.

How to Request a Feature

Have an idea for a new cmdlet, parameter, or behaviour?

• Go to New issue.
• Choose Feature request.
• Describe:

The feature you’d like (e.g. a new endpoint, a new parameter, or a different output shape).

• The use case (why it would help you or others).
• If you have one, a proposed solution (e.g. cmdlet name, parameters, example usage).

Not every request can be implemented immediately, but all are read and considered; they also help others discover and discuss ideas.

Conclusion

InforcerCommunity turns the Inforcer API into a set of PowerShell cmdlets you can use interactively or in scripts: connect once, then list tenants, baselines, policies, alignment details, users, groups, roles, and audit events with consistent parameters and output. Run compliance assessments like Copilot Readiness and CIS Benchmarks against one tenant or all of them at once, with interactive HTML matrix reports that let you compare compliance across your entire estate. Generate complete tenant documentation in HTML, Markdown, or Excel. Compare two tenants’ Intune configurations side-by-side with an interactive report that shows every difference, duplicate, and deprecated setting. Use tenant names instead of IDs, pipe results between cmdlets, and export to CSV or JSON for integration with other tools and automation pipelines. It’s a community project, not owned or maintained by Inforcer; feedback, bug reports, and feature requests from users like you shape what comes next. Install it from the PowerShell Gallery, try the quick start, and if you hit a bug or have an idea, open an issue or send a pull request.

Related

• The MSP License Ladder #1: The Hunting Gap - why MSPs need Defender for Endpoint Plan 2, with a multi-tenant hunting script.
• RKSolutions PowerShell Module - another PowerShell module for M365 reporting across Intune, Entra ID, and license management.

Table of Contents

• What is the RKSolutions PowerShell module?
• What’s new in v1.1.0
• Requirements
• Installation
  • Option 1: From PowerShell Gallery (recommended)
  • Option 2: From source (GitHub)
• Key Cmdlets and Use Cases
• Quick Start
• Output Formats and Filtering
• How to Contribute
• How to Request a Feature
• Conclusion

What is the RKSolutions PowerShell module?

RKSolutions is a PowerShell script module that talks to the Microsoft Graph API to produce report-style output (HTML by default, with optional CSV or Excel). The reports were first released as separate scripts on the PowerShell Gallery; the module brings them together in one install with shared auth and consistent parameters.

What it gives you:

• Connect once, run every report: Authenticate with Microsoft Graph (interactive, Client Secret, Certificate, Managed Identity, or Access Token).
• Six report cmdlets, one module: Intune enrollment flows, Intune anomalies, Entra admin roles, M365 license assignment, and Custom Security Attributes - all from a single Install-Module.
• Consistent behavior: All report cmdlets use the same connection from Connect-RKGraph; they support parameters such as -ExportPath, -SendEmail, -Recipient, and -From where applicable, and share the same permission model so one connection covers all reports.
• Unified report design: Every report uses a shared HTML template with consistent branding, Geist/Geist Mono typography, light/dark theme toggle, and interactive DataTables with search, export (Excel/CSV/PDF), and column visibility controls.
• **PowerShell 7.0+: Runs on Windows, macOS, and Linux.
• No secrets in scripts: Credentials are handled by the Microsoft Graph session; you connect once with Connect-RKGraph and then run as many report commands as you need.
• Tab completion and help: Every cmdlet has comment-based help; Get-Help Connect-RKGraph -Full and tab completion on parameters work out of the box.

Where to find it:

• Source code and issues: GitHub repository · Open new issue · Pull requests
• PowerShell Gallery: RKSolutions

What’s new in v1.1.0

New report: Custom Security Attributes. Get-CustomSecurityAttributesReport auto-discovers all attribute sets in your tenant and generates an interactive report showing which users, devices, and enterprise applications have which attributes assigned. The report includes an overview tab with a coverage matrix, plus a dedicated tab per attribute set with searchable tables. If you’ve set up Custom Security Attributes following our Forgotten Features Part 3 guide, this cmdlet gives you instant visibility into how they’re being used.

# Discover and report all attribute sets
Get-CustomSecurityAttributesReport

# Report on a specific attribute set
Get-CustomSecurityAttributesReport -AttributeSet "ComplianceData"

Unified report design. All reports now share the same HTML template with consistent branding, Geist/Geist Mono typography, pill-style tab navigation, light/dark theme toggle, and interactive DataTables with search, export, and column visibility. The standalone scripts each had their own HTML - the module unifies them into one polished design.

Security hardening. All report generators now HTML-encode Graph API data before rendering, preventing stored XSS through display names or attribute values. Filter dropdowns use safe DOM API methods, and the email sender parameter is validated before use.

Performance. Hot loops that previously used PowerShell’s quadratic $array += pattern now use List[PSObject].Add() for linear performance in large tenants.

Requirements

• Powershell 7.0 or higher
• Module: Microsoft.Graph.Authentication (required by RKSolutions; install via Install-Module Microsoft.Graph.Authentication).
• Permissions:Connect-RKGraph uses a default set of Microsoft Graph scopes so one connection works for all report cmdlets. Grant these to your app or consent interactively as needed. Full list and per-cmdlet breakdown: docs/PERMISSIONS.md.
  • User.Read
  • User.Read.All
  • Group.Read.All
  • GroupMember.Read.All
  • Device.Read.All
  • DeviceManagementConfiguration.Read.All
  • DeviceManagementApps.Read.All
  • DeviceManagementManagedDevices.Read.All
  • DeviceManagementServiceConfig.Read.All
  • Directory.Read.All
  • Organization.Read.All
  • AuditLog.Read.All
  • RoleManagement.Read.Directory
  • RoleAssignmentSchedule.Read.Directory
  • PrivilegedEligibilitySchedule.Read.AzureADGroup
  • Mail.Send
  • CloudLicensing.Read
  • CloudPC.Read.All
  • CustomSecAttributeAssignment.Read.All
  • CustomSecAttributeDefinition.Read.All

Installation

Option 1: From PowerShell Gallery (recommended)

Install-Module -Name RKSolutions -Scope CurrentUser

Option 2: From source (GitHub)

git clone https://github.com/royklo/RKSolutions-Module.git
cd RKSolutions-Module
Import-Module ./module/RKSolutions.psd1 -Force

Important: When loading from source, always run Import-Module from the repository root and use the path ./module/RKSolutions.psd1.

Key Cmdlets and Use Cases

Typical workflows:

• Tenant and assignment overview: Connect-RKGraph → Get-IntuneEnrollmentFlowsReport -AssignmentOverviewOnly to see all Intune assignments in one HTML report.
• Device troubleshooting: Get-IntuneEnrollmentFlowsReport -Device 'DeviceName' (or Intune device ID / Entra device object ID) for a step-by-step flow
• Compliance and auditing: Get-EntraAdminRolesReport and Get-M365LicenseAssignmentReport for admin roles and license assignment; use -ExportPath to save to a specific location, or -SendEmail to mail the report.
• Custom Security Attributes: Get-CustomSecurityAttributesReport to report on attribute assignments across users, devices, and enterprise apps with coverage metrics.

For full parameter details and example output, see the Cmdlet Reference in the repository: docs/CMDLET-REFERENCE.md. For which Graph permissions each cmdlet uses: docs/PERMISSIONS.md.

Quick Start

After installing the module, connect once with Connect-RKGraph, then run any report cmdlet. When you’re done, run Disconnect-RKGraph.

1. Connect (interactive)

A browser opens for sign-in. After consent, the session is stored and all report cmdlets use it.

Connect-RKGraph

2. Run a report

Pick any of the report cmdlets. Each produces an HTML file in the current folder by default.

# Intune assignment overview (all profiles, compliance policies, app assignments; no device needed)
Get-IntuneEnrollmentFlowsReport -AssignmentOverviewOnly

# M365 license assignment
Get-M365LicenseAssignmentReport

# Entra admin roles
Get-EntraAdminRolesReport

# Intune anomalies
Get-IntuneAnomaliesReport

# Custom Security Attributes (all sets auto-discovered)
Get-CustomSecurityAttributesReport

3. Intune flow for a specific device

Use -Device with the device name, Intune device ID, or Entra device object ID. Optionally export CSV or a Mermaid diagram.

Get-IntuneEnrollmentFlowsReport -Device 'DESKTOP-ABC123'

# With CSV export to a folder
Get-IntuneEnrollmentFlowsReport -Device 'DESKTOP-ABC123' -ExportToCsv -ExportFolder 'C:\Reports'

# Export the same flow as a Mermaid .mmd file
Get-IntuneEnrollmentFlowsReport -Device 'DESKTOP-ABC123' -MermaidOverview

4. Save report to a specific path

Use -ExportPath to control where the HTML (or other output) is written.

Get-M365LicenseAssignmentReport -ExportPath 'C:\Reports\M365-Licenses.html'
Get-EntraAdminRolesReport -ExportPath 'D:\Output\EntraRoles.html'

5. Email a report

Several report cmdlets support -SendEmail, -Recipient, and -From (requires Mail.Send and a valid From address).

Get-EntraAdminRolesReport -SendEmail -Recipient 'admin@contoso.com' -From 'reports@contoso.com'
Get-M365LicenseAssignmentReport -SendEmail -Recipient 'admin@contoso.com' -From 'reports@contoso.com'

6. Disconnect

Disconnect-RKGraph

For automation (scheduled tasks, CI), use Connect-RKGraph with -TenantId, -ClientId, and -ClientSecret, or with -CertificateThumbprint or -Identity. See the cmdlet reference for full parameter details.

You can use Get-Help <CmdletName> -Full for parameters and examples (e.g. Get-Help Get-IntuneEnrollmentFlowsReport -Full).

Output Formats and Filtering

• Default output: All report cmdlets produce HTML by default, written to the current folder (or to the path you set with -ExportPath or report-specific path parameters).
• CSV/Excel: Get-IntuneEnrollmentFlowsReport supports -ExportToCsv and -ExportFolder. Get-M365LicenseAssignmentReportsupports export to Excel, CSV, or PDF.
• Export path: Use -ExportPath (or the cmdlet’s path parameter) to save the report to a specific file or folder.
• Email: Several report cmdlets support -SendEmail, -Recipient, and -From (requires Mail.Send and a valid From address).

Example: run the license report and save to a custom path:

Get-M365LicenseAssignmentReport -ExportPath 'C:\Reports\M365-Licenses-2025.html'

Example: run the Entra admin roles report and email it:

Get-EntraAdminRolesReport -SendEmail -Recipient 'admin@contoso.com' -From 'reports@contoso.com'

How to Contribute

Contributions are welcome. The project uses a standard fork-and-pull-request workflow:

• Fork the repository on GitHub: github.com/royklo/RKSolutions-Module.
• Clone your fork and create a branch (e.g. feature/your-feature-name or fix/bug-description).
• Make your changes under module/ (see CONTRIBUTING.md for development setup, code style, and the consistency contract).
• Run tests from the repo root: Invoke-Pester ./Tests/Consistency.Tests.ps1 (see Tests/).
• Commit and push to your fork, then open a pull request against the main repository. Fill in the PR template (summary, how to test, related issue if any).

New cmdlets must be added to module/Public/, registered in FunctionsToExport in the manifest, and documented in docs/CMDLET-REFERENCE.md. If a cmdlet calls Microsoft Graph, update its required scopes, Connect-RKGraph default scopes if needed, and docs/PERMISSIONS.md. The consistency tests must be updated if you add or change exported cmdlets or key parameters.

How to Request a Feature

Have an idea for a new cmdlet, parameter, or behaviour?

• Go to New issue: Open new issue or use the Feature request template.
• Choose Feature request (if not already selected by the template).
• Describe:

The feature you’d like (e.g. a new report, a new parameter, or a different output format).

• The use case (why it would help you or others).
• If you have one, a proposed solution (e.g. cmdlet name, parameters, example usage).

Not every request can be implemented immediately, but all are read and considered; they also help others discover and discuss ideas.

Conclusion

RKSolutions turns Microsoft Graph into a set of PowerShell report cmdlets you can use interactively or in scripts: connect once with Connect-RKGraph, then run Intune enrollment flows, Intune anomalies, Entra admin roles, M365 license assignment, and Custom Security Attributes reports with consistent connection handling and output. It’s a community project, not owned or maintained by Microsoft; feedback, bug reports, and feature requests from users like you shape what comes next. Install it from the PowerShell Gallery, try the quick start above, and if you hit a bug or have an idea, open an issue or send a pull request.

Related

• Entra ID Admin Roles Report - standalone script for auditing all Entra ID admin role assignments.
• M365 License Assignment Report - standalone script for reporting on license assignments and usage.
• Intune Anomalies Report - standalone script for detecting compliance, deployment, and device anomalies.
• Custom Security Attributes (Forgotten Features Part 3) - guide to setting up and using Custom Security Attributes.
• InforcerCommunity PowerShell Module - a complementary module for MSPs using the Inforcer platform.

It’s the fifth post in this series on forgotten Microsoft 365 features - capabilities that already ship in the products but rarely get switched on. This one turns the device types you already manage in Intune (shared, kiosk, BYOD, or by department) into Defender for Endpoint tags, and it’s well worth a second look.

Table of Contents

• What are Microsoft Defender for Endpoint Device Tags?
• What do you need to get started?
• How do you set it up?
  • Step 1: Plan your tags
  • Step 2: Create a custom OMA-URI profile in Intune
  • Step 3 (optional): Apply via Powershell instead of OMA-URI
  • Step 4: Use tags in Defender for Endpoint
• Examples
  • Scenario 1: Device type - shared, kiosk, and BYOD
  • Scenario 2: Department-based tagging (Engineering, HR, Finance)
• What do the results look like?
• Conclusion

What are Microsoft Defender for Endpoint Device Tags?

Device tags in Defender for Endpoint are labels you assign to machines, making it easy to group, filter, and remediate them - segmenting your environment by something like device type or department.

In Defender, device groups define which rules apply and who has administrative control. Each device belongs to one group, which controls auto-remediation levels and RBAC permissions. Tags act as the attribute that places devices into the right group.

Because the tag is defined in Intune and reported by the device, Intune stays the single source of truth - which also means a few rules are worth knowing before you deploy:

• Each Intune policy applies one tag (the “Group” value).

• Tags have a 200-character limit; avoid parentheses and commas if you filter by tag in Defender.
• Tags deployed from Intune are reported by the device, so changes must happen in Intune or the script - editing tags directly in Defender will be overwritten on the next device report.
• There may be some delay before tags appear in the Defender portal.

More details: Create and manage device tags - Microsoft Defender for Endpoint.

What do you need to get started?

• Licensing: Microsoft Defender for Endpoint Plan 1 or Plan 2 or Defender for Business
• Management: Devices must be managed by Microsoft Intune

How do you set it up?

We’re going to use a OMA-URI solution for this. But it’s also possible via Powershell script (see step 3). This profile tells the Windows Defender Advanced Threat Protection client which tag to report to Defender. Setting this up is straightforward once you know where to look.

Step 1: Plan your tags

Decide on tag values that match how you already segment devices in Intune, like device type (Shared, Kiosk, BYOD, Corporate) or department (Engineering, HR, Finance, IT). These tags will drive device group membership in Defender, influencing RBAC and auto-remediation. Keeping names aligned ensures consistent reporting and policy application.

Step 2: Create a custom OMA-URI profile in Intune

• Sign in to the Microsoft Intune.
• Navigate to Devices > Windows > Configuration profiles.
• Click + Create > New policy.
• Select Platform: Windows 10 and later. For Profile type, choose Templates > Custom (or Custom under Settings catalog if applicable).
• Enter a name like Win - Defender - MDE Tags for Kiosk Devices.
• Under Configuration settings, add an OMA-URI row with:

OMA-URI: ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/DeviceTagging/Group

• Data type: String
• Value: Your tag name (e.g.* KioskDevice*)
• Save, then assign the profile to the relevant assignment (one profile per tag).

The ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/DeviceTagging/Group node is documented in the WindowsAdvancedThreatProtection CSP reference.

Step 3 (optional): Apply via Powershell instead of OMA-URI

Example PowerShell script (run as system, e.g. via Intune PowerShell scripts):

$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging"
$name = "Group"
$tag = "KioskDevice" # Change per deployment: Shared, Kiosk, BYOD, Engineering, etc.

if (!(Test-Path $registryPath)) {
 New-Item -Path $registryPath -Force | Out-Null
}
Set-ItemProperty -Path $registryPath -Name $name -Value $tag -PropertyType String -Force

Deploy via Devices > Script and Remediations > Remediations or Platform Scripts in Intune, one script per tag value, assigned to the same device groups you would use for the OMA-URI profile. To remove the tag, set the Group value to an empty string; do not delete the key. The device tag is included in the daily device information report; a restart can trigger a new report sooner.

Step 4: Use tags in Defender for Endpoint

In the Defender portal, use Assets > Devices Device inventory and the Tags filter to see only devices with a given tag (e.g. all Shared or all Engineering). In Settings > Endpoints > Device groups, create or edit a device group and set membership to include devices where Tag equals your Intune-deployed tag; that group then drives RBAC and auto-remediation level. You can also filter and group by tag when triaging alerts or building dynamic lists for response actions.

Examples

The following scenarios show how device-type and department tags from Intune translate into clearer segmentation and safer automation in Defender for Endpoint.

Scenario 1: Device type - shared, kiosk, and BYOD

Challenge: You have shared workstations in common areas, kiosks in production and reception, and a growing number of BYOD Windows devices. You want shared and kiosk devices in a device group with limited or no auto-remediation so automated actions don’t disrupt multi-user or locked-down sessions, while corporate and BYOD devices get full remediation. SOC needs to filter by type when investigating incidents.

Solution: Create one Intune custom profile per device type-tag values Shared, Kiosk, and BYOD. Assign each profile to the device groups you already use for those segments (e.g. dynamic or static groups by naming, OU, or enrollment type). In MDE, create device groups whose membership rule is Tag equals Shared, Kiosk and BYOD, and set auto-remediation to None or Limited for Shared and Kiosk, and Full for optionally BYOD. Use the Tags filter in Device inventory for quick views by type.

Scenario 2: Department-based tagging (Engineering, HR, Finance)

Challenge: You need to report and scope security by department: how many Engineering vs HR vs Finance devices, which alerts affect which business unit, and optionally different RBAC so department-specific analysts see only their department’s devices.

Solution: Tag devices by department using Intune profiles with values such as Engineering, HR, Finance, IT. Assign each profile to the corresponding device group (e.g. “Engineering - Windows devices” populated by dynamic rule). In MDE, create device groups by tag (e.g. “Engineering devices,” “Finance devices”) and use them for filtering, reporting, and RBAC. Department leads or tier-1 SOC can filter Device inventory by tag and see only their scope.

What do the results look like?

After the device syncs and devices report to Defender for Endpoint, the tag appears in the Defender portal. In Device inventory you can filter by the tag to see only the devices that received it (in this case it was “BlogPostDemo” as tag). Device groups that use the tag in their membership rule will show the correct devices and apply the chosen RBAC and auto-remediation settings. Below is an example of the tag visible on a device in MDE after deployment from Intune.

Conclusion

Forgotten Features Series is about capabilities that are already there - and pushing MDE device tags from Intune is a prime example. One custom OMA-URI profile per tag, assigned to the device groups you already use for shared, kiosk, BYOD, or department, and sync does the rest. Device type and department defined in Intune flow into Defender for Endpoint for reporting, device groups, RBAC, and auto-remediation - without manual tagging in the Security Center or one-off scripts. The value is that you don’t have to bolt on automation or accept that “we can’t tag at scale”; you define the tag in Intune and it flows into MDE.

Because the tag is device-driven when deployed from Intune, changes belong in Intune; editing the tag only in the Defender portal won’t persist. For automatic tagging based on device attributes (name, domain, OS), you can complement this with dynamic rules for device tagging in Microsoft Defender XDR asset rule management.

Related

• ASR Rules: Verifying with the ASR Rule Inspector - after tagging devices for Defender, verify that Attack Surface Reduction rules are actually enforced on those endpoints.