See what Intune applies to a device.
Before you deploy it.
Pick an OS, the Entra groups a device belongs to and its Autopilot group tag, and see the exact merged CSP baseline it would receive — conflicts, overlaps and legacy Endpoint Security included — and the apps installed on it or removed from it. No hardware, no enrollment, no writes.
Read-only, always
Every Graph permission it asks for is *.Read.All. It reads your tenant and never writes a single change to it.
Your credentials stay put
In the browser there is no secret at all — a public client using PKCE, with the session living in your tab and going when you close it. Self-hosted, your client secret stays in the server's .env. Either way, nothing touches anyone else's infrastructure.
Your scope, or the whole tenant
Signed in, it reads exactly what your Intune role already can. Self-hosted with app-only permissions, it reads the entire tenant unfiltered by scope tags — the complete picture a preflight wants.
Every policy. Every group. One clear picture.
Intune tells you what you assigned. Preflight tells you what a device actually ends up with, and where your assignments collide.
The apps a device gets, and where their assignments collide
The groups that deliver a device's policies deliver its apps too. See what is Required, Available or set to Uninstall, grouped by app type, with the trouble flagged: an app both installed and removed, an Available assignment that Required makes redundant, the same product packaged twice, and a line-of-business .msi that should be a Win32 app.
Which groups carry which policies, tenant-wide
One screen for every policy-to-group assignment across your tenant, per platform. Sort by direct assignments to find your hotspots, and expand any group to see exactly what a device in it effectively receives after Intune's exclude-wins rules.
- → Direct vs inherited (All Devices / All Users) at a glance
- → Simulate assignment filters and watch every group re-resolve
- → Export the whole map to Excel or CSV
Spot the overcrowding before it's a conflict
Check a group and see, at a glance, whether its policies are its own or borrowed from half the tenant. Cool means unique to the group; hot means shared widely. Then send those groups straight into the simulator to see the merged result on a device.
Genuine value disagreements vs redundant duplicate config, surfaced separately (Windows).
Deployment profiles and device-preparation shown as an enrollment stage, dual-targeting and all.
Intents-based BitLocker, Defender AV, Firewall and ASR read and merged with modern policies.
Every setting in one filterable grid, with the real CSP path and a Microsoft Learn link per setting.
Policies and apps for Windows, macOS, iOS/iPadOS and Android, each scoped and resolved separately.
A small arrow beside a policy, app or group opens that exact object in the admin center, so a finding is one click from its fix.
Pull an unassigned policy into the simulation and see what it would change before you assign it.
PowerShell and shell scripts sit in the baseline with their run options, and open in a viewer to read in full.
Excel, CSV or JSON from the simulator, with each app's detection rule. Excel or CSV from the Manifest.
Two ways in. Neither takes long.
Connect your tenant
Sign in with your own admin account and read your tenant straight from Microsoft Graph. Nothing is installed, there is no server, and no client secret exists — a single-page app is a public client. One app registration, about three minutes. Or skip it and explore the bundled sample tenant first.
How to connect →Or self-host it
App-only credentials in your own .env — the only way to see a tenant unfiltered, since a signed-in admin is bounded by their own Intune RBAC. Also the answer when Conditional Access won't pass a browser app.
Preflight the change
before the turbulence.
See the full merged baseline, catch the conflicts, and know what lands on a device — all before you deploy.