This page is for whoever has to approve Eido in your Microsoft Entra tenant. It names the Microsoft Graph permissions that Eido’s requests need, says in plain words what each one lets Eido read and which parts of Eido depend on it, and sets out the two things Eido can write and the conditions under which it does.
The short version#
- Eido asks Microsoft for access in two separate ways: a small sign-in permission for each person who uses Eido, and a tenant connection that an administrator grants once so that Eido can read Intune.
- The tenant connection comes in two access levels, read-only and read-write. You choose. A third route uses an app registration that you create and control.
- Syncing only reads. It runs about once an hour and changes nothing in your tenant, at either access level.
- Eido writes to Intune in two cases only, both started by an administrator pressing a button, both needing read-write access and a fresh Microsoft sign-in: restoring a policy from a backup, and deploying a policy template.
- Eido does not read mail, files, Teams, sign-in logs, BitLocker recovery keys or local administrator passwords, and has no action that wipes, retires, restarts or deletes a device.
The exact requests and fields behind every row are in three reference pages. They are for customers, so they need an Eido sign-in.
- Microsoft Graph requests: tenant sync
- Microsoft Graph requests: policies
- Sign-in requests and other services
Signing in#
Everybody who uses Eido signs in with Microsoft. This uses delegated permissions, which act only for the person signing in and only for their own profile.
| Permission | Type | What it is used for |
|---|---|---|
openid | Delegated | Signs the person in. |
User.Read | Delegated | Reads the signed-in person’s own sign-in name and display name, to match them to their Eido user. Nobody else’s profile can be read with it. |
offline_access | Delegated | Lets Eido renew the person’s session without sending them back to Microsoft’s sign-in page each time. |
When Eido asks somebody to confirm it is them before a sensitive action, it asks for openid and User.Read again and nothing more.
If your administrators have linked Eido roles to Entra groups, Eido also reads the identifiers of the signed-in person’s security groups from the sign-in itself. It does not query the directory for them, and no extra permission is involved.
These permissions give no access to Intune or to anybody else’s data. They are the same whichever access level your tenant uses.
The tenant connection#
To read Intune, Eido signs in to your tenant as an application, with application permissions that an administrator grants by admin consent. There is no signed-in user, which is why syncing carries on when nobody is using Eido.
The three ways to connect#
| Access level | Whose application | What it can do |
|---|---|---|
| Read-Only Access | Eido’s read-only application | Read-only access to Intune devices, policies and users. Eido never attempts a write through it. |
| Read-Write Access | Eido’s read-write application, a separate application from the read-only one | The same reading, plus write access to Intune policies and configuration. Access to users stays read-only. |
| Custom / Manual App Registration | An app registration you create in your own tenant | Whatever you grant it. Eido treats it as read-only and never attempts a write with it. |
Read-only and read-write are different applications with different consent. Granting one does not grant the other. How to choose is covered in Connecting Intune.
During the consent step itself, Eido asks only to sign the approving administrator in (openid and profile). It uses that sign-in for one thing: to learn which tenant has just granted consent.
What Eido reads#
Eido makes the same read requests at every access level. These are application permissions. Each row names the least privileged permission Microsoft documents for the requests in it, and any alternative Microsoft documents as also sufficient.
| Permission | What it lets Eido read | What depends on it |
|---|---|---|
User.Read.All | A fixed list of profile properties for every user. See User properties. It also lets Eido see the sign-in name of the people in a group. | The Users screen, the primary user named beside each device, and filtering and grouping by department, location and similar. |
Device.Read.All | Each directory device’s ID, extension attributes, enrolment profile name and enrolment type. It also lets Eido see which devices are in a group. | Device properties that Intune’s reports do not carry, which you can show, filter and group by in device reports. |
GroupMember.Read.All | The name, description and mail address of each group, and the members of the specific groups you have named in device scoping or used in a report filter. Microsoft also documents Group.Read.All and Directory.Read.All as sufficient. | Choosing groups by name, device scoping, filtering reports by group, and linking roles to Entra groups. |
DeviceManagementConfiguration.Read.All | The Intune reports Eido has asked for, once Intune has prepared them (see Intune reports). Windows update rings. Driver update profiles and their drivers. The definition and assignments of compliance policies, device configuration profiles, settings catalog policies and Windows update profiles. The setting-by-setting result of one policy on one device. Microsoft also documents DeviceManagementApps.Read.All or DeviceManagementManagedDevices.Read.All for collecting a report, and DeviceManagementEndpointSecurity.Read.All for settings catalog policies. | Almost everything Eido shows about devices, Patch compliance, the Windows driver reports, policy backups, and seeing why a policy is failing in device details. |
DeviceManagementApps.Read.All | The name, type, version and publisher of each app in Intune and how apps supersede or depend on each other. Apple VPP licence counts and VPP tokens. The Intune audit log. The definition and assignments of app configuration, app protection and Windows Information Protection policies. Microsoft also documents DeviceManagementServiceConfig.Read.All for VPP tokens. | Managed apps, Certificates, the Intune audit log reports, naming the administrator behind a policy change, and policy backups. |
DeviceManagementScripts.Read.All | The definition of each PowerShell script, macOS shell script and remediation. The result that Eido’s own App Metering remediation reports from each device. | Policy backups, Remediations and scripts (Eido reads results for the remediations and scripts it holds), and confirming devices are set up for App Metering. |
DeviceManagementServiceConfig.Read.All | The expiry date and status of the Apple push certificate and the Apple enrolment tokens. | Certificates. |
Policy.Read.All | The definition of each Conditional Access policy. | Policy backups, so that a change to a policy is recorded. Eido never writes to these policies, at any access level. |
Three things narrow this list in practice.
- Policy definitions are read during a sync only while Backup Policies is on for the tenant. One policy is also read when an administrator presses Sync on it, restores it or deploys a template to it.
- Discovered apps are read only while Sync Discovered Apps is on, and the App Metering check runs only while App Metering is on. All three switches are in tenant settings.
- A missing permission narrows Eido, it does not break it, with four exceptions. If Eido cannot read users, groups, directory devices or the Intune device report, the sync stops, because everything else depends on them. For other areas, Eido skips what it is not allowed to read and carries on. That part of Eido is then empty.
How often each area is read is in What Eido syncs.
Intune reports#
Most of what Eido shows about devices comes from Intune’s own reports: devices, hardware inventory, compliance, configuration and app install results, discovered apps, Autopilot, Defender, malware, remediations, scripts and more. Intune produces a report only when asked, so Eido sends a request that asks Intune to prepare each one, then collects the file.
- Asking for a report is the only request in a sync that is not a plain read. It creates a temporary export job in Intune’s reporting service and changes no configuration.
- For collecting a prepared report, Microsoft documents
DeviceManagementConfiguration.Read.All, as in the table above. - For asking Intune to prepare a report, Microsoft’s reference lists
DeviceManagementConfiguration.ReadWrite.All,DeviceManagementApps.ReadWrite.AllorDeviceManagementManagedDevices.ReadWrite.All(any one of them), and it does not publish which permission each individual report needs. This is the one place where Microsoft’s reference alone cannot tell you what Eido’s read-only application holds. Check the entry on the consent screen, or on the application’s Permissions page.
User properties#
Eido reads these properties of each user and no others.
| Group | Properties |
|---|---|
| Identity | ID, user principal name, display name, given name, surname, mail, mail nickname, other mail addresses, user type, whether the account is enabled, whether it is a resource account, whether it is shown in the address list |
| Organisation | job title, department, company name, office location, employee ID, employee type, employee hire date, division and cost centre |
| Location and contact | street address, city, state, postal code, country, usage location, preferred data location, preferred language, mobile phone, business phone |
| Account | created date, creation type, last password change date, password policies, assigned licences (Eido keeps only how many) |
| Guest status | external user state and when it last changed |
| On-premises | whether the account is synced from on-premises, last on-premises sync, domain name, SAM account name, user principal name, distinguished name, security identifier, extension attributes 1 to 15 |
Eido does not read sign-in activity (last sign-in times), authentication methods, manager relationships or photos. Group membership is read only for the specific groups described in the table above.
What Eido can write#
Writes are possible only with Read-Write Access. The read-write application does the same reading as the read-only one, and needs these two permissions in addition.
| Additional permission | What it lets Eido write |
|---|---|
DeviceManagementConfiguration.ReadWrite.All | Create and update compliance policies (including their actions for non-compliance), device configuration profiles, settings catalog policies and Windows driver, feature and quality update profiles, and replace a policy’s assignments. Microsoft also documents DeviceManagementEndpointSecurity.ReadWrite.All for settings catalog policies. |
DeviceManagementScripts.ReadWrite.All | Create and update PowerShell scripts, macOS shell scripts and remediations, and replace their assignments. |
Exactly two actions use them.
| Action | Who can start it | What is written |
|---|---|---|
| Restore a policy from a backup | An administrator, after confirming their identity with a fresh Microsoft sign-in | The policy is updated to match the backup. If the administrator chooses, its assignments are replaced with the ones in the backup. |
| Deploy a policy template | An administrator, after confirming their identity with a fresh Microsoft sign-in | A new policy is created from the template, or an existing policy is updated to match it. Eido never creates assignments when it deploys. |
Nothing else in Eido uses a write permission. No scheduled or background process writes to your tenant.
Eido does not write app configuration, app protection, Windows Information Protection or Conditional Access policies, even with read-write access. It issues no delete request to Microsoft Graph for any resource. It never writes to users, groups or directory devices.
Every restore and deployment is recorded in Eido with the administrator who did it. The requests themselves, and exactly what is sent, are in Microsoft Graph requests: policies.
What Eido does not access#
For clarity, Eido makes no request to Microsoft for any of the following.
- Mail, calendars, contacts, OneDrive, SharePoint and Teams
- Entra sign-in logs and directory audit logs
- BitLocker recovery keys and Windows LAPS passwords
- Device remote actions through Intune: wipe, retire, delete, restart, sync, remote lock or passcode reset
- Creating, changing or deleting users, groups or role assignments
- Azure subscriptions and resources
Eido’s optional device agent, the Eido Client, can act on a device directly, but it is a separate feature that an administrator switches on per tenant and deploys deliberately. It does not use these Graph permissions.
If you use your own app registration#
With Custom / Manual App Registration you choose the Microsoft Graph application permissions yourself, and Eido can read only what you grant. Use this table to decide.
| To have this in Eido | Grant |
|---|---|
| Devices, people and groups. Required: the sync stops without them. | User.Read.All, Device.Read.All, GroupMember.Read.All, and the permission for Intune reports described under Intune reports |
| Compliance, configuration and app results for each device, discovered apps, Autopilot, Defender, malware, firewall and attestation status, Endpoint Privilege Management and Remote Help | The same Intune reports permission |
| Managed app details, Apple VPP licence counts and the Intune audit log | DeviceManagementApps.Read.All |
| Update rings and Windows driver updates | DeviceManagementConfiguration.Read.All |
| Certificates and tokens | DeviceManagementServiceConfig.Read.All, and DeviceManagementApps.Read.All for VPP tokens |
| Policy backups and settings history | DeviceManagementConfiguration.Read.All, DeviceManagementScripts.Read.All and DeviceManagementApps.Read.All. Add Policy.Read.All to include Conditional Access policies. |
| Remediation and script results | The Intune reports permission, with DeviceManagementScripts.Read.All and Backup Policies on, because Eido reads results for the remediations and scripts it holds |
| The setting-by-setting result of a policy on one device | DeviceManagementConfiguration.Read.All |
| The App Metering set-up check | DeviceManagementScripts.Read.All |
Each row you leave out leaves the matching part of Eido empty. Grant read-only permissions wherever Microsoft offers one. Eido does not write through a custom app registration, so restoring and deploying are not available and a write permission granted for them would never be used.
Reviewing and revoking#
| To do this | Go here |
|---|---|
| See what your tenant has granted | Microsoft Entra admin centre, Enterprise applications, the Eido application, Permissions |
| See when Eido last signed in to your tenant | The same application, Sign-in logs, service principal sign-ins |
| Move from read-write to read-only | Change a tenant’s access level, then delete the read-write application from Enterprise applications |
| Stop Eido reading the tenant and delete what it holds | Remove a tenant |
| Revoke Eido’s access on the Microsoft side | Delete the Eido application from Enterprise applications |
How Eido stores and protects what it reads is covered in Security and your data.
Questions people ask#
Why does a read-only connection need access to every user?#
Intune ties each device to a primary user. To show a name, department or location beside a device, and to let you report by them, Eido reads the user list. Only the properties listed under User properties are read.
Can we limit Eido to some devices or some users?#
The permissions are tenant-wide, because that is how Microsoft Graph application permissions work. What you can limit is what Eido brings in and keeps. Device scoping restricts Eido to chosen platforms, device types or Entra groups. Turning Backup Policies or Sync Discovered Apps off in tenant settings stops Eido reading policy definitions, or the apps found on each device, during a sync.
Will accepting read-write let Eido change things without us knowing?#
No. Background syncing never writes. A write needs an Eido administrator to press restore or deploy and to sign in to Microsoft again at that moment, and it is recorded.
Why is Conditional Access in the list?#
Eido keeps a backup of each Conditional Access policy alongside your Intune policies, so that a change is noticed and the earlier version is on record. Eido only reads them. Turning Backup Policies off in tenant settings stops Eido reading and keeping policy definitions during a sync, Conditional Access policies included.
The consent screen lists a permission that is not on this page. Why?#
This page names the least privileged permission Microsoft documents for each request. Where Microsoft documents several permissions that would do, an application can hold a different one from the one named here, and the consent screen shows the one it holds. The consent screen is the record of what you are granting. If an entry on it is not explained by this page, write to Eido support before you accept.