Mideye Credential Provider

MFA for Windows RDP and Logon

Add Mideye two-factor authentication (MFA / 2FA) at the Windows logon screen itself, a native credential provider DLL that protects every Remote Desktop (RDP) session and every console logon. Drops in alongside your existing Mideye deployment with no backend changes.

Per-machine drop-in. Cloud or air-gapped on-prem. Deployable via MSI or Group Policy.

10-minute Quickstart Contact Sales

When the Mideye Credential Provider is installed, the Windows logon screen prompts for a second factor before letting any user in. The user types their Windows password as usual; Mideye then prompts for a Touch push on the Mideye+ app, a hardware-token OTP, or a code from any standard authenticator. Windows finishes the logon only when MFA succeeds. There is no other tile, no fallback, no shortcut.

The Mideye logon tile on a Windows logon screen, the white-framed Mideye 'e' mark with the "Mideye MFA" caption, the "Mideye Login" heading, and Username and Password fields below.

Why MFA at the logon ceremony?

Your Mideye Authentication Service already covers VPN, RADIUS-protected apps, ADFS, and RDS. The Mideye Credential Provider extends that protection to the place those integrations can't reach, the Windows logon screen itself, on every host where users RDP in or sit down at the console.

Closes the RDP attack surface

Stolen credentials are the leading vector for ransomware on Windows fleets. The credential provider intercepts every RDP and console logon, regardless of which application the user is heading for.

Same Mideye, no backend changes

Talks to the same Mideye Authentication API or on-prem Mideye Server you already use for RADIUS, ADFS, and RDS integrations. A signed MSI lays down two COM DLLs and a configuration tool, no second backend, no new identity store, no AD schema changes.

Air-gapped option

On-prem mode talks to a local Mideye Server over a static Bearer token. Hardware-token OTP, no internet egress required.

How users authenticate

Three method families ship today. The credential provider chooses based on what's configured per user, no method picker for the user to fumble.

Cloud or on-prem, pick per machine

A single registry value (`Mode`) picks the backend. Same MSI, same configuration tool, same docs.

Cloud mode
  • OAuth2 client credentials → Mideye Authentication API
  • Touch push, SMS magic link, hardware-token OTP, Assisted Login
  • Server-Sent Events for instant logon feedback
  • Outbound HTTPS only, port 443
On-prem mode
  • Static Bearer token → local Mideye Server
  • Hardware-token OTP only
  • No internet egress required

In on-prem mode, Touch and Assisted Login are force-disabled at startup, the local Mideye Server has no corresponding endpoints.

Safe defaults, no surprises

The credential provider is built to fail closed without locking you out and to keep secrets and PII out of plain registry values.

Lockout-resistant

A misconfigured deploy is silently inactive, not lockout-causing. Activation refuses without at least one configured Break-Glass principal.

Encrypted at rest

OAuth client secrets are stored as DPAPI-encrypted REG_BINARY blobs bound to the machine key. They never leave the host as plaintext.

PII masked in logs

Phone numbers and token serials are masked in every log line, including in debug mode. Break-Glass logons are audited individually via Windows Event Log.

Deployment

One signed MSI, three delivery paths:

Interactive MSI

Pilot install on a single host, wizard, license, install, configure.

Silent MSI (`msiexec /qn`)

SCCM, scripted rollouts, custom orchestration. Per-host JSON config applied separately.

Group Policy

Software Installation policy + a startup script that applies the per-OU JSON config. AD-joined fleets.

Where to read next

Feature overview

What each piece does: install, registry config, cloud / air-gapped, login schedule, Break-Glass, per-user overrides, approvers, customisation.

Quickstart

Zero to MFA on RDP in ~10 minutes, install, paste Client ID and Secret, add Break-Glass, activate, enforce on RDP.

Architecture

How the credential provider DLL plugs into Windows LogonUI; the MFA decision ladder; cloud + on-prem flow diagrams.

Frequently asked questions

How do I add MFA to Windows Remote Desktop (RDP)?

Install the signed Mideye Credential Provider MSI on every Windows host where RDP terminates, paste the Client ID and Secret from your Mideye Authentication Service, configure at least one Break-Glass principal, then activate. The Mideye tile replaces the default Windows password tile and prompts for a second factor on every RDP and console logon. End-to-end install runs in about 10 minutes per host.

Does Mideye Credential Provider work without internet?

Yes. In on-prem mode it talks to a local Mideye Server with a static Bearer token and supports hardware-token OTP only, no internet egress required. Cloud mode uses outbound HTTPS to the Mideye Authentication API and adds Touch push and Assisted Login. A single registry value picks the mode per machine.

What Windows versions are supported?

Windows Server 2019, 2022, and 2025. Both Active Directory domain-joined hosts and workgroup / standalone hosts are supported. Entra-ID-only joined machines are not currently tested or supported.

Ready to evaluate the Mideye Credential Provider?

Run the 10-minute quickstart on a test VM, or talk to us about a pilot in your environment.