This page is for whoever has to assess Eido before it is connected to your Microsoft tenant, or review it afterwards. It describes how Eido behaves today, in terms you can check for yourself in the product. Where a topic has its own article, this page gives the summary and links to the detail.
Eido’s certifications, hosting regions, encryption, backups and the way its own staff access is governed are in Security and compliance. Sub-processors and contractual commitments are in the legal documents linked under Terms and data processing, and anything not covered there can be asked for of Eido support.
At a glance#
- Sign-in is Microsoft only. Eido has no usernames or passwords of its own. Your Entra multi-factor and Conditional Access rules apply to every sign-in.
- A Microsoft account is not enough. A person also needs a user in Eido, with a role.
- Syncing only reads. Eido never changes anything in Intune or Entra as part of a sync, at any access level.
- You choose the access level for each Intune tenant: read-only, read-write, or an app registration you control.
- Organisations are kept apart, and so are the customers inside an organisation that manages several.
- Each region is a separate Eido service. An account exists in one region only.
- Optional features stay off until somebody chooses them. The Eido Client and Eido AI are made available by Eido on request. Odie is switched on or off by your administrator.
- Administrative actions are recorded, with who did them and when.
Signing in#
Everybody signs in with Sign in with Microsoft. Eido never sees or stores a password, and there is nothing in Eido to reset.
Because the sign-in happens at Microsoft:
- your organisation’s multi-factor authentication and Conditional Access policies apply
- disabling somebody’s Entra account stops them signing in to Eido
- Eido uses the person’s sign-in name and display name from the sign-in. If your administrators have linked roles to Entra groups, it also uses the identifiers of the security groups the person is in. It reads nothing else from their account
Signing in to Microsoft successfully does not, by itself, give anybody access. Eido then looks for a user whose email address is that sign-in name. If there is none, the sign-in is refused. A user is created either by an administrator on the Team page, or, if your administrators have set it up, automatically for members of an Entra group that is linked to a role.
The permissions the sign-in uses, and the messages a refused sign-in shows, are in Regions and signing in.
Sessions#
Once signed in, a person stays signed in on that browser. Eido ends the session, and asks for a fresh Microsoft sign-in, when:
- the sign-in reaches its maximum age, however active the person has been
- the person presses Logout, which ends the session on Eido’s side as well as in the browser
- an administrator changes the person’s role, or the customer they are limited to
- an administrator removes the person from Team
- the person’s role comes from an Entra group and they are no longer in it
- the browser the session was started in changes
A session belongs to one browser. Signing in on a second device does not carry the first one’s session with it.
Confirming identity before a sensitive action#
Some actions change something outside Eido. Before one of these, Eido asks the person to sign in to Microsoft again in a small window, even though they are already signed in to Eido. The check is made by Eido’s servers, not only by the page, so it cannot be skipped by calling Eido directly.
It is asked for before:
- running a tool action that changes a device, from the device’s Tools tab
- approving a remediation script proposed by Eido AI
- deploying a policy template to Intune
- restoring a policy from a backup
The confirmation lasts a short while, then is asked for again. A person who cancels it changes nothing. See Confirming it is you before a sensitive action.
Roles and least privilege#
What a person can see and do is decided by their role. See Roles.
| Control | What it does |
|---|---|
| Built-in roles | There are two: Admin, and Read All Devices, which is not an administrator. They cannot be edited. |
| Custom roles | Roles you create. A custom role is never an administrator. |
| Access Designer | On a custom role, any data view can be Blocked outright, or given Required Filters that are always applied when somebody with the role queries it. This is how you limit a role to one department, one platform or one set of devices. |
| Customer Access | For organisations that manage several customers, a role can be limited to selected customers, and a person can be limited to exactly one. |
| Roles from Entra groups | A role can be filled from Entra security group membership instead of being assigned by hand. Membership is read at sign-in. Somebody who is no longer in the group is refused at their next sign-in. See Linking roles to Entra groups. |
Two levels of administrator exist. An instance-level administrator manages the whole organisation: Intune tenants, roles, integrations and features. An administrator who is limited to one customer can open only the Admin pages that make sense for that customer, and cannot move people outside it. See Instance-level and customer-level administrators.
Permissions are enforced by Eido’s servers on every request. Hiding a menu entry is a convenience, not the control: somebody who opens an Admin address from a bookmark without the right role is turned away in the same way.
To take somebody’s access away, remove them on the Team page. They are signed out at once, and any scheduled reports and export jobs they own are switched off.
How organisations and customers are kept apart#
Between organisations#
Everything in Eido belongs to exactly one organisation: its Intune tenants, devices, people, dashboards, reports, settings and audit records. Every request is answered from the organisation of the person who made it. There is no feature for sharing data between two organisations.
Between customers inside one organisation#
A managed service provider can hold several customers in one organisation, each with its own Intune tenants. See Customers.
- A person who is limited to a customer sees that customer’s tenants and data, and nothing belonging to any other customer or to the organisation as a whole. No role can widen that.
- A dashboard or report that somebody shares is visible only to people in the same organisation and the same customer. Sharing gives others a read-only view. Only the owner can change or delete it.
- Alerts created for one customer cover that customer only.
Between regions#
Eido runs as three separate services: Europe (eu.eido.io), United Kingdom (uk.eido.io) and United States (us.eido.io). Each has its own accounts and holds its own organisations’ data. Your organisation is created in one region and exists in that region only: its people cannot sign in at either of the other two addresses. See Regions and signing in.
The Azure region behind each one is listed under Regional hosting.
What Eido reads from your tenant#
Connecting an Intune tenant is a separate step from signing in, and only an instance-level administrator can do it. It is granted by Microsoft admin consent, which Microsoft’s own consent screen describes in full. See Connecting Intune.
| Access level | Summary |
|---|---|
| Read-Only Access | Read-only access to Intune devices, policies and users. Enough for everything in Eido except policy management. |
| Read-Write Access | The same reading, plus the ability to deploy and restore Intune policies. Access to users stays read-only. Needed for policy management only. |
| Custom / Manual App Registration | An app registration that you create in your own tenant, with the permissions you decide to give it. |
Points a reviewer usually wants confirmed:
- A sync only reads. It runs about once an hour for each tenant and changes nothing in Intune or Entra.
- Eido writes to Intune in two cases only, both needing Read-Write Access, both started by an administrator, and both needing the identity confirmation described above: restoring a policy from a backup, and deploying a policy template.
- With the two standard access levels, Eido holds no password or secret of yours. Access rests on the consent your administrator granted, which you can withdraw at any time in the Microsoft Entra admin centre.
- With your own app registration, you give Eido its client secret. It is stored encrypted and is never shown again in the product. The field in tenant settings is always blank, and entering a value replaces the stored one.
- Eido does not read mail, files, Teams, Entra sign-in logs, BitLocker recovery keys or local administrator passwords, and has no Intune action that wipes, retires, restarts or deletes a device.
The full list of what is read, the resources involved and the two write cases is in Permissions Eido needs. How often each area is read is in What Eido syncs.
Limiting what Eido brings in#
The Microsoft permissions are tenant-wide, because that is how application permissions work. What you can limit is what Eido keeps:
- Device scoping restricts a tenant to chosen platforms, device types or Entra groups. Devices outside the scope are not brought into Eido.
- Backup Policies and Sync Discovered Apps, in a tenant’s features, can each be switched off. Eido then stops reading policy definitions, or the list of apps found on each device.
The Eido Client#
The Eido Client is an optional agent for Windows devices. It is not installed by connecting a tenant, and nothing on this page so far involves it.
- It is made available by Eido on request. Until then there is no switch for it.
- It is switched on per Intune tenant by an instance-level administrator, who must first accept an acknowledgement on behalf of your organisation. The acknowledgement states that the client collects information from managed endpoints and lets authorised users carry out diagnostic and administrative actions on them.
- You deploy it yourself, through Intune or another tool. Eido cannot push it to a device.
- On the device it runs as a Windows service under the SYSTEM account and makes outbound connections only. Nothing connects in to the device.
- Each capability has its own switch per tenant: app metering, monitoring, inventory, Windows events, automatic updates, and each of the live tools.
- Actions that change a device are a separate switch again. With Enable Write Actions off, the tools are read-only for that tenant. With it on, each kind of action (services, processes, registry, print queue, user sessions) can still be switched off individually. Only administrators see these actions, each one needs the identity confirmation described above, and each is recorded.
The addresses and ports a device must be able to reach are in What devices need to reach.
AI features#
Eido has two AI features. They are separate, and neither is needed for the rest of Eido to work.
| Feature | How it becomes available | Controls |
|---|---|---|
| Eido AI (AI Diagnostics and Intune Changes) | Made available by Eido on request. It cannot be enabled from inside the product. Once it is available, an instance-level administrator switches AI Diagnostics on under Admin, Eido AI. | An administrator chooses whether a suggested fix always waits for a person. A script can run on a device only after an administrator has approved its exact content. Approving a remediation needs the identity confirmation described above. |
| Odie, the assistant on every page | Switched on or off for the organisation by an instance-level administrator under Admin, Odie Assistant. | Each person can hide him for themselves. Everything Odie does runs under the permissions of the person asking, so he cannot show anybody data their role does not allow. What he builds is private to that person. |
Using either feature means that the content of the request is sent to an AI model. Exactly what is sent is listed in What is sent to the AI model for Eido AI, and What Odie sends to the AI model for Odie.
What is recorded#
Eido keeps an audit record of what people do in it. Each entry has the date, the person’s name and email address, the action, what it was done to, the detail of what changed, and the IP address it came from. Where a secret was changed, the record says that it changed and not what it changed to.
Recorded actions include:
- every sign-in
- a sign-in refused because the person is no longer in an Entra group linked to their role, and a role or account that was set from an Entra group
- people added, changed and removed, and roles created, changed and deleted
- customers added, changed and deleted
- an Intune tenant linked, changed, synced on demand or removed
- integrations added, changed and removed
- a policy template deployed and a policy restored
- changes to Eido AI and Odie settings, and each script approval
- acceptance of the terms of service
You can read these yourself. In Query Hub, choose the Audit Log view. Like any view it can be searched, filtered and saved as a report. People see the entries for their own organisation, and people limited to a customer see that customer’s only. See Building a query.
Two related records:
- Intune Audit Logs, also a Query Hub view, is Microsoft’s record of who changed what in Intune, read from your tenant at each sync. It is not a record of what happened in Eido.
- Scripts run by Eido AI are listed under Script Runs in AI Diagnostics.
Terms and data processing#
Use of Eido is governed by two documents:
When a new organisation is first opened, Eido shows Terms of Service & Data Processing Agreement over the whole product. An administrator must confirm they are authorised to accept both on behalf of the organisation before anybody can use it. Everybody else sees a message asking them to contact their administrator. Acceptance is needed once per organisation, is recorded with who accepted and when, and is asked for again if the terms change materially. See Signing up.
Switching the Eido Client on has its own acknowledgement, described above, which is also recorded.
Removing access and deleting data#
You can do most of this yourself, without contacting us.
| To do this | Do this |
|---|---|
| Stop one person using Eido | Remove them on Team. They are signed out at once. |
| Stop Eido reading an Intune tenant, and delete what it holds about it | Remove the tenant. The tenant leaves the list immediately and everything collected from it is then deleted in the background. This cannot be undone. |
| Withdraw the consent on the Microsoft side | Delete the Eido application from Enterprise applications in the Microsoft Entra admin centre. Removing a tenant in Eido does not do this for you. |
| Move a tenant from read-write to read-only | Change the tenant’s access level, then delete the read-write application in Entra. |
| Stop the Eido Client | Switch it off for the tenant, and uninstall it from devices with the tool you deployed it with. See Switch it off, or remove it. |
| Stop using AI features | Switch AI Diagnostics off under Admin, Eido AI, and Odie off under Admin, Odie Assistant. |
Removing a tenant changes nothing in Intune or Entra. Your devices, policies and users are untouched.
Asking for your data to be deleted#
To have your whole organisation deleted from Eido, including its people, settings, dashboards, reports and audit records, raise a ticket with Eido support as an administrator. Tell us:
- your region and the name of your organisation
- whether you want everything deleted, or one tenant or customer only
- who we should confirm to when it is done
It helps to remove your Intune tenants yourself first, as described above, and to delete the Eido application from your Entra tenant, so that nothing is being read while the request is handled.
An organisation whose free trial has expired and has not been extended is deleted automatically. See When the trial ends.
For a request about one individual’s personal data, such as a data subject request under data protection law, write to the same address. The individual’s details in Eido come from your Entra tenant, so a change made there is reflected in Eido at the next sync.
Reporting a security concern#
If you think you have found a security problem in Eido, or that an account or a linked tenant has been misused, see Reporting a security concern.
Questions a reviewer usually asks#
Does Eido need a Global Administrator account to keep working?#
No. A Global Administrator is needed once, to grant consent when the tenant is linked. After that Eido signs in to the tenant as an application. The person who granted consent does not need to keep that role afterwards.
Can Eido staff or another customer see our tenant?#
Another customer cannot. Every record belongs to one organisation, and requests are answered only from the organisation of the person making them. For how Eido’s own staff access is governed, see Eido administrative access.
Can we restrict Eido to part of our estate?#
Yes, in two ways. Device scoping limits which devices are brought in at all. Roles limit what each person can see of what has been brought in.
Can a person with a read-only role cause a change in Intune?#
No. Writing to Intune needs an administrator, a tenant linked with Read-Write Access, and a fresh Microsoft sign-in at that moment.
What happens to our data if we stop using Eido?#
Remove your tenants and ask us to delete the organisation, as described above. If you were on a trial that has expired, see Plans and billing.
Where can I find certifications, sub-processors and retention periods?#
Certifications are listed in Security and compliance. For sub-processors and retention periods, check the Data Processing Agreement, and raise a ticket with Eido support for anything it does not answer.