I started building PIM Manager because Microsoft’s PIM lacks critical visibility. No dashboard, no single view, just individual blades.
That’s not a minor inconvenience. It’s a security risk. If you can’t see what’s configured, you can’t secure it properly.

When I started building, it became a learning experience. About PIM itself: how policies actually work, what the Graph API exposes, where the gaps are.
About building a tool like this: progressive loading, delta queries, worker pools.
I learned by doing.

I planned to build the Configure page next. But I realized: I couldn’t build a reliable wizard without first understanding PIM for Groups. If Groups use different APIs and policy structures, I’d end up building a Configure page that only works for Roles. Then I’d have to rebuild it all. So I made a decision: understand Groups first, build Configure second.
Turns out, that was the right call. Groups are fundamentally different with separate Owner and Member policies, different endpoints, and different permissions.

This blog covers what changed in this journey: PIM for Groups support, unmanaged groups discovery, workload toggles, smarter data syncing, flexible PDF exports, and runtime debugging tools.

PIM for Groups: Two policies, not one

Why this mattered

PIM for Groups isn’t just “roles but for groups.” It’s structurally different.

With a Directory Role, you have Eligible or Active assignments. Simple. With a Group, you have Owners and Members. Each has its own policy. Different activation duration. Different MFA requirements. Different approval workflows.

In the portal, that means separate tabs for “Owner settings” and “Member settings.” If PIM Manager treats Groups as flat entities (just showing assignments without the Owner/Member split), it’s not useful for audits.

How it works technically: When you assign a role to a PIM-managed group, that role assignment is always active. The PIM layer sits at the group membership level, not the role assignment. Users activate into the group (as Member or Owner), and once they’re in, they get the roles assigned to that group. This is why you need separate policies for Owners and Members: they might need different activation requirements even though they’re accessing the same downstream roles.

Breaking it down

UI: GroupCard component with separate tabs for Member and Owner settings. Policy sections (activation, assignment, notifications) are mirrored for both. Assignment lists filter by role type.
Data structure: Each group stores two policy objects, one for Members and one for Owners. When you expand a group in the Report page, you see both policies side-by-side.
Graph API: Groups use the same endpoint as Roles (roleManagementPolicyAssignments), with a scopeType='Group' filter. The API returns separate policies for Members and Owners based on the roleDefinitionId.

If you’re using PIM for Groups for scoped privileged access (like “Helpdesk Operator for OU Amsterdam”), you need to see that Owners have a 4-hour max activation and Members have 8 hours. Or that approval is required for Owners but not Members. Without this, you’re missing half your security posture.

Unmanaged Groups: The security gap you didn’t see

When you start using PIM for Groups, there’s a risk most people don’t think about.

Role-assignable groups can exist in your tenant without being PIM-managed. They have isRoleAssignable: true , but no PIM policy attached. That means they have role assignment capability, but aren’t managed by PIM. No time-bound activations. No MFA requirements. No approval workflow. Just direct, permanent group membership.

These groups don’t show up in the PIM blade. But they’re fully functional for privileged access.

The risk: If you assume “all privileged access goes through PIM,” but you have unmanaged groups, that assumption is wrong. You have a blind spot.

Detection and visibility

Simple logic: if a group can assign roles but has no PIM policy, it’s unmanaged.

Unmanaged Groups chart: Shows the split between Managed and Unmanaged groups on the dashboard. Clickable, like all dashboard charts. Filters the report view when you click it.
Workload visibility: On the Dashboard, the “Unmanaged Groups” toggle only appears if you’ve consented to PIM for Groups. On the Report page, it’s an independent toggle; sometimes you want to see everything.
Export: CSV export includes a “Managed” column (Yes/No). Filter in Excel to see only unmanaged groups.

You run a PIM audit. You see 50 groups. You assume they’re all PIM-managed. But some aren’t. That gap used to be invisible. Now it’s front and center.

Workload Toggles: Multi-workload architecture

Version 1.0 was single-workload: Directory Roles only. When PIM for Groups landed, state management became complex. Each page had its own logic. Filters broke between pages. Consent handling was inconsistent. That approach wouldn’t scale.

The solution: UnifiedPimContext

Central state management for all workloads. Directory Roles, PIM for Groups, Unmanaged Groups, and future developments all managed in one place.

Each workload has:

• Consent state (did the user grant permissions?)

• Loading state (is data currently being fetched?)

• Data (the actual roles or groups)

• Visibility (is the user showing or hiding this workload?)

Incremental Consent: You open the app, and it asks for Directory Roles permissions. You toggle on PIM for Groups, and you get a consent pop-up for the Groups scope. No need to re-consent for everything upfront.

Workload Visibility controls:

• Dashboard: Toggles affect all components (charts, cards, lists)

• Report page: Independent toggles (you might want to see only Groups)

• Settings Modal: Central configuration point

If you have 200 Directory Roles and 50 PIM for Groups, you don’t always want both visible. Toggle the workload, and your charts and exports contain only what you need.

And if you don't have Groups permissions yet? The UI still works. No errors. No broken features.

Smart Sync: But not quite

Here’s where I want to talk about something that almost works.

Here’s the thing: I didn’t know delta queries existed until I started building PIM for Groups support. I was fetching everything on every refresh, thousands of API calls, and rate limits everywhere. Then I found the delta endpoint in the Microsoft Graph docs and realized: this is exactly what I needed.

Microsoft Graph supports delta queries. You make an initial request, get back a full dataset plus a deltaLink. Next time, you use that deltaLink and only get what changed since the last request. It’s very efficient.

Example: Initial request to /users/delta returns:

{
  “@odata.nextLink”: “https://graph.microsoft.com/v1.0/users/delta?$skiptoken=...”,
  “value”: [ /* all users */ ]
}

When you've retrieved all pages, the final response contains:

{
  “@odata.deltaLink”: “https://graph.microsoft.com/v1.0/users/delta?$deltatoken=abc123...”,
  “value”: [ /* last batch of users */ ]
}

Next refresh? Use that @odata.deltaLink. Graph returns only what changed (new, updated, deleted). If nothing changed, you get an empty array and a new deltaLink.

I implemented this for role and group assignments. If you refresh and nothing changed, the app makes ~10 API calls instead of 500. Big performance improvement.

But here’s the catch: Delta queries don’t work for role or group configuration (the policies). There’s no delta endpoint for RoleManagementPolicy. Every time you refresh, you have to re-fetch all policies, one by one.

Still, delta queries help with the bulk of the data: roles, groups, and assignments. The app uses them where it can.
For policies, I built a worker pool to fetch them in parallel without hitting rate limits. Not as elegant as delta queries, but it works.

Why mention this? Because understanding the limitations is part of the story. Delta queries exist. They’re powerful. But they’re not a universal solution.
You have to know where they apply and where they don’t.

PDF Export: Config-driven and flexible

Why this mattered

The first version had PDF export, but it was hardcoded. Fixed sections, no filtering. And you asked for visual stat cards alongside the data.
Now it’s there. Config-driven sections, workload filtering, stat cards with colored accents.
When you export, choose which sections to include. Want assignments but not policies? Select assignments. Want only PIM for Groups data? Toggle off Directory Roles first, then export.

Debug without rebuilding: Runtime logger

I needed better debugging. When something breaks or doesn’t load, I need to see the consent state, API calls, and workload initialization without rebuilding the app.

Runtime logger has two levels: INFO (default) and DEBUG.
Switch modes in Settings → Developer tab, which includes instructions on viewing console logs and using DEBUG mode.

💡 Note: DEBUG slows page loads (intentional, it’s for troubleshooting).

Where we are now

PIM Manager is still a reporting and visibility tool. That’s what it does well. You get insight into your PIM configuration (Directory Roles and PIM for Groups) without clicking through the portal for hours.

What’s working:

• Directory Roles and PIM for Groups reporting (Owner/Member policies)

• Security gap detection (unmanaged groups)

• Workload isolation (toggle visibility)

• Efficient data sync (delta queries where supported)

• Flexible exports (choose sections, filter workloads)

• Runtime debugging (enable logging without rebuilding)

Limitations:

• Read-only (for now). The tool shows you what’s configured, but doesn’t change policies. The Configure wizard will add that capability.

• Cloud-hosted only. You can’t self-host yet. Everything runs in your browser, talking directly to Microsoft Graph (no data leaves your session), but the app

  is hosted on Cloudflare Pages. I’m exploring self-hosting options. Let me know

  your preferences.

• Session cache. Data refreshes when you tell it to, not automatically. It’s not live monitoring. When you close the app, cache and localStorage are cleared for security.

• Manual consent. You need to enable each workload yourself. No admin pre-consent for all users.

The Configure wizard is coming. It'll let you bulk-apply policies, clone settings, and review diffs before making changes. But that's focused, careful work, which takes some time. One feature at a time.

Open Source & Documentation

By popular request, I’ve made the repository public, including the full architectural documentation.
Want to deep-dive into the data flow, security model, or see exactly which Graph API endpoints are used? It’s all documented there.

⚙️PIM Manager repository

Thanks for taking the time to read this! Got feedback or suggestions? Let me know.

Microsoft does not offer a single-pane-of-glass dashboard or reporting function for Entra ID role management. That’s not an opinion, it’s the reality we work with.

As a Solutions Architect or Security Engineer, you need to know the current state of privileged access before you can design anything. Whether you’re inventorying a client environment, planning an implementation, running an audit, or streamlining PIM configurations, you first need visibility. And right now, getting that visibility is not simple.

When I discussed this with colleagues, the problem became clear: getting proper insight into PIM configuration would be a pain. Doing it visually? Even harder. Doing it periodically for non-technical stakeholders who need to understand the security posture? Near impossible with native tooling.

That’s why I started building PIM Manager.

The gap that Microsoft left behind

The truth is: if you want to understand your Entra ID role configuration at scale, your options are clickops or scripting. Neither is pleasant.

Clickops means clicking through the portal, role by role, blade by blade, copying settings into a spreadsheet. Scripting means writing and maintaining PowerShell or Graph API calls, parsing JSON, and building your own reports. Both approaches are manual, time-consuming, and prone to errors.

The questions seem simple:

• Which roles allow permanent assignments that bypass PIM?

• Is MFA enforced on all privileged roles?

• Which roles have approval workflows, and who are the approvers?

• Are there any “shadow admins” hiding in direct role assignments?

Getting answers should not require a day’s worth of work. This is the gap that PIM Manager fills.

What PIM Manager actually does

PIM Manager is about insight and getting in control of your governance. It’s a tool for dashboarding, reporting, and gaining an overview - bringing together everything the portal spreads across a dozen different blades.

The Dashboard gives you immediate visual insight into your environment’s health. You see cards showing total roles, active sessions, permanent assignments, and PIM coverage. Charts break down the distribution of privileged versus non-privileged roles and assignment types across your tenant. There’s an overview of configured approvers, because knowing who can approve Global Admin activations should not require digging through individual role policies. Configuration errors are shown, so you catch problems before auditors do.

The Report lets you go deeper. You see every role in your tenant, both built-in and custom, with the assignment breakdown front and center. How many are eligible? How many are active? How many permanent? Expand any role, and you see its full configuration: maximum activation duration, MFA requirements, justification settings, approval workflows, approvers, and scope information. You can filter by almost anything: privileged roles only, roles with permanent assignments, or roles assigned to a specific user. And when you need an offline copy for documentation, compliance evidence, or just to filter and highlight in your own spreadsheet, export it with one click.

You’re never locked into the tool as your only source of truth.

The architecture: keeping it simple (and safe)

When I started building PIM Manager, I had to make a fundamental decision: where does the data processing happen?

I chose the browser. PIM Manager is a pure single-page application. There is no backend server that I control. There is no database storing your tenant’s privileged access data. Everything runs in your browser, using your authentication token, talking directly to Microsoft Graph.

This isn’t just a technical choice; it’s a security posture. I don’t see your data. I can’t see your data. The application follows the permissions your account holds in Entra ID. If you can’t read a role assignment in the portal, you can’t read it in PIM Manager either.

For performance, data is cached locally in your browser session. When you sign out, that cache is cleared. Nothing persists.

Tip: For a complete picture of all roles, assignments, and configurations, use an account with at least the Global Reader role. Or put that role behind Eligible PIM first - then you’ll need to activate before you can even see all the data ;-)

The hard parts: what I learned building against Graph API

Building against Microsoft Graph is powerful, but PIM-related APIs come with challenges.

The permission model requires care. I aimed for least privilege. The app uses granular permissions like RoleEligibilitySchedule.Read.Directory and RoleManagementPolicy.Read.Directory rather than broad permissions like Directory.Read.All. The goal was to keep day-to-day auditing safe and low-risk. You should be able to see your configuration without needing write access.

The bigger challenge was the data loading pattern. Fetching all role definitions is cheap, just one API call. Fetching all assignments is also manageable, since you can get them all in one request. But fetching the role configuration for each role? That requires a separate API call per role. A fresh Entra ID tenant already has around 130 built-in roles. That’s 130 additional requests before you’ve even added custom roles. Or Microsoft decides to add another role tomorrow ;-)

Send all those requests at once, and Microsoft will throttle you instantly. HTTP 429 errors stack up, and your users see a broken loading screen.

I solved this by building smart. First, the app loads the cheap data: role definitions and assignments. This needs only a handful of API calls. It gives you an immediate, usable overview within seconds. You can already see who has access to what.

Then, in the background, workers fetch the per-role configurations in parallel but controlled queues. Each worker respects rate limits. The UI shows a progressive loading bar (”Fetching configuration 15/130...”) so you always know the app is working, not stuck. By the time you’ve scanned your first few roles, the configurations are already loading behind you.

The insights you shouldn’t ignore

Once you have proper visibility, you start seeing things you shouldn’t want to ignore.

Permanent assignments are a good example. These are direct role assignments that bypass PIM entirely. No activation required. No MFA on activation. No time limit. No approval workflow. The user simply has the role all the time.

Sometimes that’s intentional. Break-glass accounts, for example, need permanent Global Admin access. But in many tenants, permanent assignments are legacy configurations, shadow admins, or problems that nobody cleaned up. Without visibility, you don’t know they exist.

PIM Manager makes these obvious. When you see a “Permanent” badge next to a privileged role during an audit, you can’t unsee it. The conversation shifts from “we think our PIM is configured correctly” to “here are the five roles we need to fix.”

The bigger picture

PIM Manager started as a way to save my own sanity. It grew into a tool that solves a real problem in getting control over PIM, and I mean all Privileged Identity Management, not just the Microsoft product.

Whether you’re designing a role model, running an audit, onboarding to a new tenant, or just trying to understand who has admin access, PIM Manager provides the insight the native portal is missing.

Hours of clicking become seconds of reviewing. Guessing becomes data.

What’s next

This is version one. Here’s where I’m heading next:

Configure page - A way to modify role configurations in bulk, but safely and controlled. Adjust activation settings, approval requirements, or create assignments across multiple roles without clicking through each one manually.
PIM for Groups - Extending the same visibility and control to group-based privileged access, not just directory roles.

Try it yourself: pimmanager.com
Time to stop struggling and start managing.

Thanks for taking the time to read this blog!
Do you have any feedback or adjustments I should make? Please let me know.

Intro

The Microsoft Secure Future Initiative (SFI)…, “The what?“. Yup, that’s how it often goes in a conversation with customers and also with fellow tech-minded people. This post is not for those who know all about this topic, but perhaps it’s worth sharing when experiencing this next time you have this situation as well.

In this blog, we’ll dive into what it is and why it is a fundamental change in reasoning and habits.

Microsoft’s Secure Future Initiative

Let’s get back to the beginning. Microsoft started this Initiative in November 2023.
It was not a real surprise after Microsoft embraced Zero-trust back in 2018, but this change in mindset was interesting. It was a reaction to the increasing scale and impact of cyberattacks, focusing on the whole firm and on improving cybersecurity in all of Microsoft’s products.

Microsoft built the SFI on 3 principles:

1. Secure by Design

   Security comes first when designing any product or service.

2. Secure by Default

   Security protections are enabled and enforced by default, require no extra effort, and aren’t optional.

3. Secure Operations

   Security controls and monitoring will be continuously improved to meet current and future cyber threats.

SFI goes beyond just technology. It also includes a commitment to transparency—openly sharing progress and incidents—and working closely with customers, partners, and regulators to raise the security bar for everyone.

There’s one more aspect that deserves attention: Continuous improvement. The lesson here is clear. You never just configure and walk away. Security settings, posture, and compliance need regular reviews and updates. In the cloud, these improvement cycles are much shorter than on-premises. And let’s be honest, on-premises needs these cycles too.

And Microsoft is taking this approach themselves, even if some changes mean reworking existing processes. If you’re looking for someone who covers these updates for Entra, Merill Fernando is a great source of inspiration.

The initiative got me thinking. In the past, security was often something you handled at the end of a project or as an afterthought. With Zero Trust and now SFI, the mindset shifts to building security right into the architecture and design phase and making it part of daily operations. Even small changes to a single setting can have security implications you need to consider.

Another question that comes up: how do you manage all of this? You have to keep up with continuous improvements on one hand, and configuration changes for workability or best practice advice on the other. That’s why I’m convinced you need at least a backup or versioning solution for your tenant configuration items. I saw a post on LinkedIn advising this, partly as a protection against threats like ransomware. I’d add that you also need this for continuous improvement. For example, you can recover from misconfiguration or keep track of new settings rolled out by Microsoft.

Change in mindset

Adopting the Secure Future Initiative is really about a change in mindset. It’s not just another policy or technical setting to tick off, but a shift in how you look at your entire environment. In some ways, it’s like learning a new skill or building better habits: you have to practice, repeat, and adapt before it becomes second nature. But I am heavily convinced this change in mindset is necessary for both MSP companies as well as companies with IT departments.

Security can no longer be a checklist at the end of a project or a siloed IT responsibility. You need a holistic approach that connects technology, people, and processes. Without this, gaps will appear—sometimes in places you least expect—and attackers are quick to exploit them.
Never forget: collaboration between teams, in-Cloud as well as between on-prem and Cloud is crucial. We, as tech-minded people, need to build solutions that are modular and scalable so we can adapt quickly to changing situations.

This story isn’t just for the enterprise. If you’re a C-level executive, ask yourself: are we still relying on old habits, or are we equipping our teams to anticipate what’s coming next? And for SMBs, the risks are just as real. Smaller organizations are often targeted exactly because attackers know defenses can be inconsistent. SFI isn’t about the size of your company; it’s about raising your baseline and staying resilient.

A final key point: don’t underestimate the human factor. Security adoption only works if end users understand the “why” behind the changes. Invest in user adoption and engagement, create clarity, and make security part of the company culture, not just an IT rulebook. When people understand the purpose, you’ll find much more engagement and support.

Closing

The Secure Future Initiative isn’t just a vision; it’s a practical guide for daily work. Start by making security part of every project and every conversation, from IT to management to end users. Review your settings and configurations regularly, invest in user adoption, and make sure there’s clear ownership of security across the organization. And remember: don’t present security as just a list of things people can’t do, but as an enabler for working safely and efficiently together.

No matter your size, taking these concrete steps will help you keep pace with new threats and stay ahead. Use SFI as a framework, but don’t hesitate to combine it with other standards like CIS, NIST, or your industry-specific requirements. That way, every team can take real action to build a safer, more resilient digital environment, without losing flexibility or productivity.

Sources

Microsoft Secure Future Initiative

SFI and Zero Trust

Backup your configurations

MC1097272

Intro

These days, local administrators are becoming less essential thanks to Endpoint Privilege Management (EPM). But practically, we do see that it’s far from gone yet.
This blog has been sitting in draft for a while now, but hey—it's never too late to update and publish, right?
I wondered how everyone keeps control of their environments with the tools available in Microsoft Entra and Microsoft Intune.

In this blog, I'll share my thoughts on how you can bring all the necessary controls together into a cohesive, working solution.

💡 As always, naming convention is key to a structured way of working and keeping stuff manageable!

Our setup

Groups

The groups used in this setup are sometimes linked to multiple controls. To keep track of which groups are used in various configurations, I have used Intune Assistant.
I firmly believe in automating as much as possible, so wherever possible, I use dynamic groups (see GitHub for the dynamic membership rule).

Device groups

• Win-Dev-Standarduser
  Note: I am aware that the Operator Contains is no longer considered best practice anymore.

• Win-Dev-Administrator

These groups are dynamically assigned.
This way, a device with no Autopilot tag is, by default, classified as a StandardUser device—supporting a “secure by default” approach.

User groups

• Win-Usr-StandardUser

• Win-Usr-LocalAdministrator-All
  Note: This group is used for Entra users who need to be local admins on all devices.

• Win-Usr-LocalAdministator
  Note: This group is attached to the role Microsoft Entra Joined Device Local Administrator.

These groups are statically assigned.

Entra

Within Entra ID, we already have a set of controls to narrow down the risk for Entra Joined devices and extend controls we can use later on in Intune.

In the screenshot below, you’ll see we first prevent Global administrators from being Local administrators on all devices by default, which narrows down ‘lateral movement’, I’d say.
Secondly, we scope the registering user to be added to the local administrators group during setup. For this, we use the Win-Usr-LocalAdministator group, as its members are authorized to be local admins—but only on their own devices.

⚠️Note: This setting is only needed when you are joining existing devices to Entra/Intune and for APv2, otherwise you can change this to None.

And of course, we enable LAPS to be set up in Intune later on!

Autopilot

In the setup, I aim to separate device and user configurations. That applies to the Autopilot setup as well. We do configure two profiles, one for the standard user and one for administrators. And of course, we assign the right groups to the right profile Win-Dev-StandardUser and Win-Dev-Administrator.
This creates our first layer of control over who may become a local administrator when the device is being set up.

Intune

Have you ever heard of Local user group membership? It’s a good way to manage who ends up in the Administrators group on each device.

We will configure the policy Win - Local admins - D - Replace to ensure that, on every device in the Win-Dev-Standarduser group, only the users from Win-Usr-LocalAdministrator-All are added to the Administrators group on the device, and otherwise it’s a placeholder.

⚠️ Tip: It can be confusing, but there’s a difference between Add (Replace) and Add (Add) actions. Be careful when configuring this. Personally, I prefer Replace over Remove, as it gives us more control instead of focusing on removing specific users.

Secondly, we configure the Win - Local admins - D - Add and assign the group Win-Dev-Administrator to it. In the add action, we target the group Win-Usr-LocalAdministrator-All again.
This allows users who need admin access on all devices to be added—without removing the end user.
I know this profile doesn’t fully prevent future misuse (as it doesn't check if others are added), but ideally, these end users will be using EPM.

As of March 2025, the LAPS controls are extended in the settings catalog to randomize the account name, for example. We’ll use these latest settings to make the setup even more secure. I’ll upload the configuration profile to GitHub, but feel free to tailor the LAPS settings to your needs and assign them to all devices.
There’s no need for custom configurations, because with our group setup, the user won’t be removed or overwritten.

⚠️ Note: Do not enable the Passwordless experience setting in the config profiles, otherwise Windows is trying to extend the LAPS user with your domain name.

Closing note

We created a comprehensive solution to keep the best of both worlds, and reducing the risk that the Administrators group gets a wild-west scenario.
By preventing Global administrators from being added, we lower the risk in case one of those accounts is compromised.
If you want to limit this to Autopilot-registered devices only, consider setting the Entra Join option to None.

With the Local User Group Membership setting, we’ve established fine-grained control over group memberships on the device. And as you may have noticed, this profile also allows you to manage other local groups, not just Administrators, providing even more governance options.

The configuration I could export with IntuneManagement, I stored in my GitHub.

Considerations

It’s recommended to disable of the default Administrator through the Config profile settings—especially since the LAPS user is a newly created account. Note that this setting does not remove the default Administrator from the Administrators group automatically.

The Add (Add) action is not the most secure option, as EPM is in this case. But without EPM, this can be a considerable option for your environment.

Also, keep in mind that configuration profiles do not refresh or reapply by default. I strongly recommend enabling Config Refresh within your config profiles (if you haven’t already). My good friend Nicklas made an excellent blog about it!

Is this the most secure solution? No, definitely not.
Is it manageable, does it add control, and bring real value to your environment?
Absolutely.

Thanks for taking the time to read this blog!
Do you have any feedback or adjustments I should make? Please let me know.

Resources

Local administrators on Entra Joined devices

Policy CSP - LocalUsersAndGroups

Windows Autopilot profiles

Manage Windows LAPS in Intune

Intro

With the announcement that we are able to connect via the Windows App to our Windows 365 Cloud PC's from the major platforms (Windows, iOS/iPadOS, MacOS, and Android), it's time to give our users access in a controlled and secure manner!

In this blog, I will try to create a configuration that gives the user this access from unmanaged devices in a secure way.
First, we will focus on the mobile devices. After that, we will set up web access to Windows 365 from Windows and Mac devices.

💡As always, naming convention is key to a structured way of working and keeping stuff manageable!

Our setup

The setup we are going to create is about allowing access to the cloud pc (this can be Windows 365, Microsoft virtual desktop, or other cloud pc's).
I split the solution into two: mobile devices and desktop devices.
For the mobile part, we are configuring Conditional access to require App protection and App configuration.
For the desktop part, we are only allowing web access since App protection is not available for desktop devices on the Windows App (yet?).

The configuration for this setup is stored in my GitHub.

Filters

We need to have filters in Intune to target only unmanaged devices for our App protection policies and our App configuration policies.
You need two filters, one for Android and one for iOS/iPadOS.

Configuration

• Go to Intune > Tenant administration > filters

• Create a new filter and make sure you select Managed apps

• Give the filter a name and select the platform.

• Under Rules, select

• • Property: deviceManagementType

  • Operator: Equals

  • Value: Unmanaged

• Create another filter for the other platform.

App protection policies

In the App Protection blade, we need to have app protection policies in place to protect our organization's data.
We need two policies for our Android and iOS/iPadOS devices targeting all apps on unmanaged devices.

Configuration

• Go to Intune > Apps > App protection policies

• Create a new App protection policy and select the platform

• Give the policy a name

• Select the apps you want to target, in my case All apps.

• Configure your data protection controls, and make sure you block data between the company apps and personal apps. (See GitHub for my example.)

• Configure your Access requirements

• Configure your Conditional launch

• Target the policy to All users and apply your earlier-created filter to target unmanaged devices.

• Repeat these steps for the other platform.

  ---

App configuration policies

In App Configuration, we need to have policies in place to prevent actions like drive redirection since we are connected from our personal devices.

❗The Remote desktop app is only available on Android.

Configuration

• Go to Intune > Apps > App configuration policies

• Create a new App configuration policy and select Managed apps

• Give the policy a name and target the policy to Windows app (and for Android, also the Remote desktop app)

• Go to Settings > General configuration settings and configure the following settings:

Name : Value
audiocapturemode : 0
camerastoredirect : 1
drivestoredirect : 0
redirectclipboard : 0

• Target the policy to All users and apply your earlier-created filter to the right platform os.

• Repeat these steps for the other platform.

Conditional access

Of course we need Conditional access to secure and enforce configurations.
We are going to configure the mobile part to enforce App protection and MFA every week.
For the desktops, we configure access via web and enforce MFA every time and block the usage of desktop apps to our Cloud PC's.

Check the Learn page on which App ID's to include when targeting the resources.

Configuration

Go to Entra > Protection > Conditional access > Policies
Create a new policy for the following policies.

Unmanaged - GRANT - Mobile - CPC - Require MFA and App protection

• Target All users

• Target the Apps mentioned earlier on

• Target Any network

• Under Conditions, configure:

• • Device platforms are Android and iOS.

  • Client apps Mobile apps and desktop clients

  • Filter for devices device.trustType -eq "Workplace"

• Under Grant, configure:

• • Require authentication strength select Phishing resistant MFA

  • Check Require App protection policy

  • Check Require all the selected controls at the bottom

• Under Session select Sign-in frequency 7 days

Unmanaged - BLOCK - Desktop - CPC - Non-web access

• Target All users

• Target the Apps mentioned earlier on

• Target Any network

• Under Conditions, configure:

• • Device platforms are Windows and MacOS.

  • Client apps Mobile apps and desktop clients

  • Filter for devices device.trustType -eq "Workplace"

• Under Grant select Block access

Unmanaged - GRANT - Desktop - CPC - Require MFA for web access

• Target All users

• Target the Apps mentioned earlier on

• Target Any network

• Under Conditions, configure:

• • Device platforms are Windows and MacOS.

  • Client apps Browser

  • Filter for devices device.trustType -eq "Workplace"

• Under Grant select Require authentication strength: Phishing resistant MFA (or any other if your not ready to do Phishing resistant MFA)

• Under Session select Sign-in frequency: Every time

💡As I want to enforce the safest MFA method to grant access, I selected Phishing-resistant MFA but of course you can adjust this to your needs.

Considerations

In my opinion, the first question that you have to ask yourself at all times is: do you want to allow your employees to have access to corporate resources from unmanaged devices?
If every employee has a laptop or corporate phone, why should you want to create a potential security risk for something that no one is going to use?

Closing note

Thanks for taking the time to read this (first) blog!
Do you have any feedback or adjustments I should make? Please let me know.

Resources

The export of these configurations is done with the great tool of Mikael Karlsson.

GitHubMicke-K

Microsoft LearnErikre

Microsoft Learndknappettmsft

Microsoft LearnErikjeMS

Hi there!

I'm a passionate Consultant from the Netherlands, driven by curiosity and a constant hunger for improvement. I thrive on exploring cutting-edge Microsoft cloud technologies and crafting practical, secure, and scalable solutions — with the end user always in mind.

My core focus lies in Identity, Endpoint Management, and Security, especially within Microsoft Intune, Entra ID, and the Microsoft Defender Suite. I’m also experienced with Exchange, Microsoft Teams and Azure, and I’m always seeking new ways to simplify management and strengthen security across the board.

With each exciting discovery and solution I uncover, my excitement grows, fueling my eagerness to share these innovations, solutions, and thoughts based on what I encounter in my everyday work and my own wonderings. I approach challenges with structure, pragmatism, and a strong belief in automation and clarity.
In my daily work, I'm focused on designing and implementing solutions, but I do know the Dutch way of thinking may differ from other countries.

Instead of concentrating on certain technical subjects, I am addressing manageability and solutions as a whole from the standpoint of CI/CD. For in depth technical topics, I will redirect you to LearnIntune from my buddy Nicklas!

Curious to exchange ideas, give feedback, or collaborate? Don’t hesitate to reach out — I'm always learning, and always open to new perspectives.