Skip to content
Docs

Mideye Fleet and the Mideye endpoint: how it works

Someone sits down at a Windows computer, or opens a Remote Desktop session to a server, and types a user name and password. Most of the time that is the whole story, and that is exactly the problem: a stolen password opens the door. Mideye adds one more question to that moment. The phone buzzes, the user taps Approve, and Windows continues. This page explains what happens behind that tap, which parts are involved, and where your data goes.

The pieces

Section titled “The pieces”
Each Windows computerMideye FleetMideye Server (your network)or Mideye CloudUser's phoneor tokenMideye sign-in tileMideye BrokerMideye Agent local pipepulls policy,sends status and events(mutual TLS)HTTPSTouch push

One installer on every computer. The Mideye endpoint is a single Windows installer (MSI) for Windows 11 and Windows Server 2019, 2022 and 2025. It puts three parts on the computer:

PartWhat it does
Credential ProviderThe Mideye tile on the Windows sign-in, unlock and Remote Desktop screens.
Mideye BrokerA Windows service that talks to Mideye Server or Mideye Cloud and decides whether the sign-in may continue.
Mideye AgentA Windows service that connects the computer to Fleet. It stays stopped on a computer that is not managed by Fleet.

The tile and the broker talk over a local channel on the computer only. Installing the MSI changes nothing at sign-in: nobody sees the Mideye tile until an administrator turns protection on, and protection cannot be turned on without a break-glass account, your way back in.

A second-factor service. Each computer checks the second factor with your own Mideye Server, one to five of them in failover order, or with Mideye Cloud when you do not want to run a server.

Mideye Fleet, if you want it. Fleet is a web application where you configure groups of computers, connect your Mideye Servers and see which computers need attention.

Local or Fleet: two ways to run a computer

Section titled “Local or Fleet: two ways to run a computer”

A standalone computer is configured on the computer itself with Mideye Configuration, or with Group Policy or Intune for many computers at once. This is a good start for a pilot, and for sites where a central server is not wanted.

A managed computer takes its configuration from a policy in Fleet. Mideye Configuration on that computer becomes read-only: the policy decides. A standalone computer can join Fleet later without a reinstall, and the MSI can also join Fleet during the install.

The way Fleet and the computers talk is designed so that Fleet is never a door into your computers:

  • The computer calls Fleet, never the other way around. The agent checks in, fetches its policy and uploads status and events. Fleet has no way to connect to a computer.
  • Mutual TLS. A computer only gets in after an administrator approves it in Fleet. From then on it proves who it is with its own certificate, and its key never leaves the computer.
  • Signed policies. The computer only accepts a policy signed by its own Fleet, whose identity it pinned when it joined.
  • No secrets in the policy. What a computer needs to keep secret stays on that computer.

Who sees what

Section titled “Who sees what”

A sign-in involves a password and a phone number. Mideye keeps them apart.

Windows and Active Directory check the password, as always. With your own Mideye Server as backend, the password also travels to it over HTTPS, and the server checks it against its own directory, so a code or a Touch approval only counts together with the right password. The server already knows each user’s phone and tokens.

With Mideye Cloud, no password ever leaves the computer. The cloud gets what it needs to reach the user and check the answer. For a Touch, that is the phone number and the text of the push and SMS, which by default names the user and the computer; you can change that text. For a code, it is the token and the code.

Mideye Fleet never sees a password either. It is not on the sign-in path at all; it sees policies, computer status and sign-in events.

How users sign in

Section titled “How users sign in”

The user always starts with the Windows user name and password, then answers the second factor on the same tile:

  • Mideye Touch: a push to the phone, approve with one tap.
  • A one-time code from a hardware token, a YubiKey or an authenticator app.
  • Assisted Login: a named approver, for example a colleague or the helpdesk, confirms the sign-in for a user who has no phone at hand, by phone or with codes.

What users see is described step by step in What users see at sign-in.

Enrolment at the tile. With Mideye Server, users can set up an authenticator app right at the Windows sign-in: scan a QR code, type one code, done, with no separate portal. You decide how much proof that enrolment needs.

When something is out of reach

Section titled “When something is out of reach”
  • Fleet is down. Nothing changes for users. Each computer keeps the last policy it received and keeps asking for the second factor. Fleet is needed to change settings, not to sign in.
  • A Mideye Server is down. The computer tries the next Mideye Server in its list.
  • No Mideye Server can be reached, for example a laptop on a train. If you allow it, a user with an authenticator-app entry for this computer can still sign in offline. The entry is sealed with the computer’s TPM, works only on that computer, and only for a limited number of days after the user’s last online sign-in. Without that, the break-glass path is the way in.

Versions

Section titled “Versions”

Mideye Fleet and the current Mideye endpoint are published as preview releases on the download portal. Features can still change between versions. This documentation describes Mideye endpoint 0.24.52, Mideye Fleet 0.27.0 and Mideye Server 6.6.11.

Where to go next

Section titled “Where to go next”

Planning starts with the requirements. The step-by-step guides, from the Fleet installation to policies, break-glass and troubleshooting, are linked from the two sections below.