Security and compliance

This page is Eido’s technical overview of security, privacy and compliance, for whoever has to assess Eido before or after it is connected to a Microsoft tenant. The first part covers the Eido platform. The second covers the Eido Client, the optional agent for Windows devices.

For how the product behaves, in terms you can check for yourself on screen, see Security and your data. For support hours, response targets and incident communication, see Support and service delivery.

Last reviewed: 13 October 2026

The Eido platform#

Security and assurance#

Eido maintains a security and compliance programme designed to protect the confidentiality, integrity and availability of customer information.

Eido maintains the following certifications:

• ISO/IEC 27001:2022
• ISO 9001
• Cyber Essentials

The certified management-system scope covers the development and provision of software to enterprises and managed service providers to monitor and support Intune tenants.

Current certification evidence and appropriate security-assurance information can be provided to customers on request.

Regional hosting#

Eido is hosted on Microsoft Azure. Customers select an available hosting location when their Eido environment is provisioned.

A customer’s primary application data is hosted in the region selected for that customer. Specific data-residency, recovery or service requirements may also be documented in the applicable agreement, Data Processing Agreement or service schedule.

See Regions and signing in for the address of each region.

Customer separation#

Eido is a multi-tenant service. Customers in the same region share the platform and are kept apart in the application itself.

• Every record belongs to exactly one customer 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. That is decided by Eido’s servers on every request, from the signed-in person’s account. It does not depend on what a page chooses to show.
• Nothing is shared between organisations. There is no feature for one organisation to see or receive another’s data.
• Regions are separate services. An organisation exists in one region only. Its accounts and its data are not present in the other two.
• Inside an organisation that manages several customers, a person who is limited to one customer sees that customer’s tenants and data and nothing belonging to any other. No role can widen that.

Within an organisation, roles limit what each person can see and do. See How organisations and customers are kept apart and Roles.

Encryption and infrastructure protection#

Eido uses encryption to protect customer information in transit and at rest. Connections between browsers, APIs, Microsoft services and Eido use encrypted HTTPS/TLS communications. TLS 1.2 is the minimum version the platform accepts, and unencrypted HTTP is not served.

Databases, their transaction logs and their backups are encrypted at rest. Data held in file storage is also encrypted. Sensitive service credentials and signing material are kept in a dedicated secrets-management service, and are accessed through identity-based, role-based access controls where supported, not through shared passwords.

The hosting provider is responsible for the physical protection of its datacentres and the underlying managed-cloud infrastructure.

Customer access management#

Customers access Eido using Microsoft Entra ID single sign-on.

Customer administrators manage access to their Eido instance and can view current users and assigned roles. Customers are responsible for reviewing and updating access when users join, change responsibilities or leave their organisation.

Before Eido discloses customer-specific information or performs a sensitive account, access or configuration change through Support, the requester’s identity and authority are verified. Sensitive changes require approval from an administrator of the affected Eido instance.

See Team and Roles.

Eido administrative access#

Authorised members of Eido’s Engineering, Support and Security teams may access a customer’s Eido instance where reasonably necessary to investigate a support request, diagnose a service issue or respond to a security incident.

Eido personnel use individually assigned Microsoft Entra ID accounts protected by Eido security controls, including multi-factor authentication.

This access relates to the customer’s Eido instance and does not provide Eido with direct administrative access to the customer’s Microsoft Intune or Microsoft Entra environment. Where screen sharing or access to a customer-controlled environment is required, Eido requests the customer’s approval.

Secure development and vulnerability management#

Eido uses controlled software-development and release processes that include source control, peer review, automated build and deployment workflows, environment separation, infrastructure as code, testing and security checks.

Every release has a recovery path. Eido’s preference is to correct a fault by rolling forward, with rollback of the application and restoration of data available as a last resort. See Change management and rollback.

Security issues are assessed according to risk and tracked through remediation and corrective-action processes. Eido commissions independent penetration testing at least annually. Customer-safe assurance information may be made available under an appropriate confidentiality agreement.

Monitoring, synchronisation and data quality#

Eido monitors relevant application, platform and synchronisation processes to identify service failures, errors and degradation.

Customers can view synchronisation status within Eido and can manually trigger synchronisation when required. Eido monitors synchronisation health and investigates material synchronisation or data-quality issues through its support process.

Where an issue is identified, Eido investigates whether it relates to Eido processing, Microsoft service availability, permissions, tenant configuration, synchronisation or underlying source data.

See What Eido syncs.

Incident response#

Eido maintains an incident-management process covering detection, assessment, containment, investigation, remediation, customer communication and lessons learned.

Suspected security incidents affecting customer data are treated as urgent. Where a confirmed data breach affects customer data, Eido notifies the customer’s designated primary contact without undue delay and, in any event, within 48 hours of becoming aware of it. Eido then provides further information as the investigation progresses.

Security concerns can be reported through support.eido.io or [email protected]. More specific notification requirements may be included in applicable contractual documentation.

Backup and recovery#

Eido uses its hosting platform’s managed backup and recovery capabilities to support service restoration and point-in-time recovery. Backup data is encrypted and is stored using managed cloud services.

No backup is kept for longer than four weeks.

Eido maintains documented recovery procedures and tests them through its business-continuity arrangements. Customer-specific recovery objectives may be contractually agreed where required.

Data export and offboarding#

Customers can export information directly from Eido using built-in self-service export functionality, subject to their permissions and access scope.

Customers should complete any required exports before terminating their use of the service. Disconnecting a linked Intune tenant initiates deletion of its synced operational data from Eido’s active systems, with residual backup copies expiring through the applicable backup-retention process, within four weeks.

See Removing access and deleting data.

Data retention and deletion#

Eido keeps what it reads from a tenant for as long as the tenant is linked, and brings it up to date at every sync. Beyond that, each kind of record has its own limit, after which it is permanently deleted.

Deletion is triggered in three ways.

Copies held in encrypted backups are not edited. They expire with the backups themselves, the oldest of which is four weeks old. See Backup and recovery.

Deleting data from Eido changes nothing in Intune or Entra. To ask for your organisation’s data to be deleted, see Asking for your data to be deleted.

Privacy, subprocessors and assurance#

Eido processes customer information only as required to provide, secure and support the service and in accordance with applicable contractual and data-processing obligations.

Eido maintains information about approved subprocessors and manages material changes in accordance with its Data Processing Agreement and applicable customer terms.

Subject to relevance, confidentiality and security requirements, Eido may provide customer-safe assurance materials including certification evidence, security and architecture summaries, regional-hosting information, penetration-test executive summaries, business-continuity information and relevant access-control or audit evidence.

See the Terms of Service and the Data Processing Agreement.

The Eido Client#

Client overview#

The Eido Client is a lightweight Windows service that extends the visibility and support Eido provides on managed devices. Intune stays in charge of policy and device management. The Eido Client sits alongside it and adds live inventory, health monitoring and on-demand IT support tools that Intune doesn’t natively provide.

It installs as a standard Windows service under the SYSTEM account, deployed like any other Win32 application, usually pushed out through Intune.

What the Eido Client can do#

Supported devices#

The Eido Client is supported on Windows 11, 64-bit (x64), on any version that Microsoft still supports. The device must be enrolled in Intune, in a tenant that is linked to Eido. A device that is not in Intune cannot enrol.

It is built for devices with one user: physical PCs and Windows 365 Cloud PCs. Multi-session Azure Virtual Desktop hosts are not supported.

The client also installs on Windows 10 version 22H2, which is how Windows 11 Readiness is reported for devices that have not been upgraded yet. Windows 10 is no longer supported by Microsoft, so Eido supports the client there on a best-effort basis.

What it collects about people#

Most of what the Eido Client collects describes the device. Three things relate to the people who use it.

The Eido Client does not capture the screen or record keystrokes, and it is not a remote control tool. A script runs on a device only if an administrator has approved its exact content.

Each capability has its own switch for each tenant. The client is switched on for a tenant only after an administrator has confirmed, on behalf of the organisation, that it is authorised to deploy it and that any notices and consents the law requires have been given and obtained.

Data residency#

Eido runs three independent regional deployments. Each customer is provisioned into exactly one region at onboarding and customer data stays in that region. There is no cross-region replication and no global control plane that stores customer data.

How it works#

The Eido Client is installed once, typically through Intune, and re-establishes trust automatically from that point on.

1. Installation. An MSI installs the client as a Windows service and records the platform URL and a one-time enrolment token supplied at deployment.
2. Identity generation. On first run, the client generates its own key pair inside the Windows protected key store. The private key is marked non-exportable and never leaves the device.
3. Enrolment. The client presents the enrolment token once to register itself with Eido. The token is single-use and is discarded immediately after enrolment succeeds.
4. Ongoing trust. From then on, every request the client makes is individually signed with its private key. No password, API key or shared secret is stored on the device.
5. Heartbeat and sync. The client checks in on a short, fixed interval to report health and pick up configuration changes, and submits inventory and monitoring data on its own schedule.

What is kept on the device#

• The program is installed under Program Files\Eido Agent.
• Its working data is under C:\ProgramData\Eido\Agent, readable only by SYSTEM and local administrators. It holds the device’s enrolment, its settings, performance measurements for the last seven days, data waiting to be sent to Eido, and the client’s own log files, which are kept for seven days.
• The private key is held in the Windows protected key store, marked non-exportable. It is not a file in the working data.
• No password, API key or shared secret is stored on the device.

Uninstalling the Eido Client removes the service, the program and its data from the device.

Security#

Trust rooted in a device-generated certificate. Every Eido Client is identified by a certificate it generates on the device itself during enrolment, not by a credential that Eido hands out and shares. The private key is created inside the Windows protected key store, marked non-exportable, and never leaves the device. There are no passwords, API keys or service-account credentials stored on endpoints.

Signed requests, always. Every request the client makes to Eido is individually signed and time-stamped to prevent replay. A request that fails signature or timestamp verification gets rejected before it’s processed.

Outbound only, no inbound ports. The client only ever initiates connections outward. Eido never opens a connection to a device, and no inbound port is opened on the customer network.

A live metrics channel that only works on demand. A small, separate channel carries live performance metrics to the portal, authenticated with the same on-device certificate over a mutually authenticated TLS connection. It doesn’t carry anything else. No telemetry is pushed from the device, and the channel only responds when a technician asks for a live view from the portal.

Automatic certificate rotation. The device certificate is valid for two years and gets checked automatically ahead of expiry. Rotation happens with no manual intervention or re-enrolment needed.

Guardrails on remote actions. Where remote support actions are enabled for a tenant, they’re deliberately constrained. Every action is logged before it runs and rate-limited per user and per device. The technician also has to freshly re-authenticate with Microsoft Entra ID right beforehand, so a stored login session on its own isn’t enough. A small set of sensitive system targets is refused by the client itself, no matter who is asking, so the protection still holds even if a technician’s account were compromised. If activity looks unusual, further actions in scope are automatically paused until an authorised administrator reviews and clears it.

Where a remote action guardrail is triggered, Eido automatically generates an internal alert for review. If the activity is determined to require a security investigation, Eido will notify the affected customer through their designated contact and provide relevant updates as the investigation progresses.

Code signing and updates#

Every released version of the Eido Client is code signed by Eido, both the installer and the program it installs.

New versions are released to devices in stages. A device is offered a new version when it checks in, downloads it from Eido over HTTPS, and upgrades itself. Before it installs anything, the client:

1. checks that the download matches the SHA-256 hash Eido published for that version
2. verifies that the download carries a valid code signature, and that the signature is Eido’s

An update that fails either check is refused and reported to Eido, and the device stays on the version it has. The download is kept in the client’s own protected folder while it is checked, not in a shared temporary folder.

Auto Update can be switched off for a tenant. Its devices then stay on the version they have until it is switched back on, or until a newer package is deployed through Intune.

Connectivity#

The Eido Client requires outbound network access only. It never listens for inbound connections, and no port needs to be opened on the customer network for it to function.

Protocols#

All traffic uses TLS 1.2 or higher. The HTTPS channel carries individually signed, time-stamped REST requests. The live metrics channel uses MQTT v3.1.1 over TLS, authenticated with the client’s own certificate (mutual TLS) instead of a password or shared secret. Every connection is initiated by the client. Eido never initiates a connection to a customer device.

Proxies and TLS inspection#

The client runs under the SYSTEM account and automatically uses the machine’s configured proxy, so no separate proxy configuration is normally needed. Where a network applies TLS inspection to outbound traffic, *.azure-devices.net needs to be excluded from it. The live metrics channel depends on a mutual-TLS handshake using the client’s own certificate, and a TLS-terminating proxy breaks that handshake. If the exclusion isn’t possible, only the live metrics view is affected. Enrolment, heartbeat, inventory, configuration and support actions all keep working normally, since they only depend on the platform URL.

For deploying and configuring the client, see The Eido Client.