How we work

How MDO treats your tenant

What MDO can do in your tenant, what it actually does, and what it keeps. The short version first, then the detail.

What MDO reads: Your Intune apps, policies, devices, scripts, roles and audit events, Entra's audit log, Conditional Access policies, group names and the tenant's name, through the Microsoft Graph permissions listed below.
What MDO writes, and when: Apps, policies and per-app groups in your tenant, only when someone on your team asks, and only if their role allows it. The one exception is automatic revert of a protected policy, which is off until you turn it on for that policy.
What MDO keeps: Policy snapshots for 90 days by default, one compliance score a day for 400 days, and the change history and Activity for 13 months. Your backups stay in your own storage account.
Where MDO runs: In the United States.
How to cut it off: Withdraw admin consent under Enterprise applications › Modern Device Ops in Microsoft Entra, and MDO can no longer read or change the tenant.

The permissions MDO asks for

Connecting a tenant is admin consent to MDO's app in Microsoft Entra. These are the application permissions that consent grants.

Your administrator can review or withdraw them under Enterprise applications › Modern Device Ops. Withdrawing consent cuts MDO off from the tenant.

DeviceManagementApps.ReadWrite.All: Read your apps; deploy, edit and delete the ones you ask MDO to.
DeviceManagementConfiguration.ReadWrite.All: Read policies; create baseline policies, restore policies and roll back a setting when you ask.
DeviceManagementConfiguration.Read.All: Read policies and their assignments.
DeviceManagementManagedDevices.Read.All: Read managed devices and their compliance state.
DeviceManagementScripts.Read.All: Read remediation and platform scripts.
DeviceManagementServiceConfig.Read.All: Read enrollment and Autopilot settings.
Directory.Read.All, Group.Read.All: Show group names in assignments and resolve who is in scope.
Organization.Read.All: Read the tenant's name and domains.
DeviceManagementRBAC.Read.All: Read Intune roles and scope tags, for the change history.
Policy.Read.All: Read Conditional Access policies, to show what changed in them.
AuditLog.Read.All: Copy Intune's and Entra's audit logs into MDO, to show who changed what.
Group.Create: Create the per-app groups, if you turn them on. Asked for separately.

What MDO writes, and when

MDO reads on its own and writes only when asked. The nightly collection, backups, clean-up and compliance scans read from Intune. Backups write to your storage account, never to Intune. Apart from automatic revert (below), every change to Intune starts with a person clicking in MDO, and the server checks that person's role before it acts.

The one exception is automatic revert for a protected policy. It is off by default, an Owner or Admin turns it on for one policy at a time, and MDO then puts that policy back after a change, at most three times a day, only where it can do so without asking, and sends an alert saying what it did.

Baseline policies are created with no assignments, so nothing reaches a device until you assign them. With per-app groups on, deploying an app also creates its three Entra security groups.

Backups, History and undo

Policies are backed up every night to your storage account, and any of them can be restored from any backup you still keep.

Before MDO changes an app's install commands, detection rule or package, or deletes it, it backs that app up to your storage account first. If the backup fails, MDO changes nothing and says why.

Every app change is in the app's History, with who made it and the old and new values. An assignment change can be restored from there, and a package can be rolled back to one of the last three. A policy change can be undone with Revert on the change in Audit › Changes, after a preview of exactly what MDO will write.

Restoring a policy, including a deleted one, relies on the nightly backup, not on a fresh one taken at that moment.

Activity records who did what in MDO for each tenant, and when, including scheduled changes MDO made itself and visits by VirtualCaffeine support. Changes made in the Intune portal and in Entra are in Audit, with who made them. Both are kept for 13 months.

What "Verified" means

A catalog app is Verified when the latest lab run of its Winget package passed every step. That run happens on a clean Windows 11 VM that isn't enrolled in Intune. MDO builds the same package a deploy would and checks detection before install. It installs as SYSTEM with Intune's command line, checks detection again, uninstalls, checks once more, then rolls the VM back.

Verified means the package installs, is detected and uninstalls cleanly on a clean machine. It says nothing about how the app behaves with your other software.

What "On devices" means

On the Compliance page, On devices counts the in-scope devices that Intune's own reports say a policy meeting the control was delivered to. It also counts the devices with a conflict, an error, or no report yet. It is not a reading of the value on the device: MDO has no agent. The figures refresh with the nightly collection, or when an admin clicks Scan now.

What MDO keeps, and where

In your storage account: the backup files, for as many days as you set (90 by default). MDO keeps an index of each run (policy names, IDs and file paths) so it can find a policy for you, not the files.
In MDO's database: what it collects from Intune, kept apart per tenant by Postgres row-level security. Policy snapshots are kept for 90 days, and one compliance score a day for 400 days. Intune's and Entra's audit events, the change history and MDO's Activity log (which includes app History) are kept for 13 months. VirtualCaffeine's own audit of its staff's work, including support access to your tenant, is kept for 24 months.
Credentials: for your storage account, the app's client ID and its secret, encrypted with AES-256-GCM. MDO holds no storage account keys or SAS tokens. Deleting that secret in Azure ends MDO's access to your storage.
Hosting: MDO runs in the United States.

Who can do what

Four roles, checked by the server on every request, so the limits hold outside the web app too.

The full role table

Owner: Everything, including bulk deletes and restores and the organisation's settings.
Admin: Users, tenants, storage, backups, restores, baselines, compliance exceptions and attestation.
Deployer: Deploys, edits, rolls back and deletes the apps MDO manages, syncs with Intune and acknowledges changes. Can't restore policies, start backups, configure storage or manage users.
Viewer: Sees everything in the tenant and changes nothing.

Free during the private beta. Tell us about your tenant and Aaron will get back to you.