Touch-AcceptCloud + on-prem
The user's Mideye+ app rings; one tap on Approve completes the logon. SMS magic-link fallback for users without the app installed. Reduces phishing risk, since there is no one-time code to trick out of the user.
Mideye Credential Provider · Early access
MFA for Windows RDP and logon.
A native credential provider DLL that adds Mideye two-factor authentication at the Windows logon screen itself, on every Remote Desktop session and console logon. Drops in alongside your existing Mideye deployment with no backend changes.
- Per-machine drop-in
- Cloud or air-gapped on-prem
- MSI or Group Policy
Why the logon screen
The gap your other integrations can't reach.
Your Mideye Authentication Service already covers VPN, RADIUS-protected apps, ADFS, and RDS. The credential provider extends that protection to the Windows logon screen itself, on every host where users RDP in or sit down at the console. The user types their Windows password as usual; Mideye then prompts for a Touch-Accept on the Mideye+ app, an SMS magic link, or a hardware-token OTP. Windows finishes the logon only when MFA succeeds. Activation covers RDP and the console together, and it will not hide the standard Windows tile until a real Mideye logon has proved the host can actually let someone in.
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. A signed MSI lays down two COM DLLs and a configuration tool. No second backend, no new identity store, no AD schema changes.
On-prem, including air-gapped
On-prem mode talks only to your local Mideye Server, over a static Bearer token, with no internet access needed on the endpoint. Every method is available; a fully air-gapped server falls back to hardware-token OTP.
Overview
How it works, in short.
A short overview of what the credential provider does and where it fits. Walkthroughs of the logon experience itself are on the way.
Authentication methods
Three ways to approve a logon.
The credential provider picks for the user, from what is configured for them. Touch-Accept starts immediately where it is available, and a choice is only ever offered as a fallback, when the push cannot be delivered or answered and a token is available instead.
Hardware token OTPCloud + on-prem
One-time codes from HID Approve and YubiKey hardware tokens, and from any standard OATH-HOTP token. Press the button or tap the key, type the code, in. The only method that also works fully air-gapped, with no network at all.
Assisted LoginCloud + on-prem
Four-eyes approval: the user requests; an approver on a separate phone confirms. In cloud mode approvers can be local SAM users, AD domain users, or external phone-only contacts with no Windows account on the host. In on-prem mode the approver list comes from the Assisted Login profile on your Mideye Server, so it is managed centrally rather than per machine.
Deployment modes
Cloud or on-prem, picked per machine.
Same MSI, same configuration tool, same docs. A single registry value (Mode) picks the backend.
Cloud mode
- OAuth2 client credentials → Mideye Authentication API
- Touch-Accept, SMS magic link, hardware-token OTP, Assisted Login
- Server-Sent Events for instant logon feedback
- Outbound HTTPS only, port 443
One registry value:
ModeOn-prem mode
- Static Bearer token → local Mideye Server
- Touch-Accept, SMS magic link, hardware-token OTP, Assisted Login
- TOTP self-enrolment at the logon screen
- No internet access needed on the endpoint
On-prem is not a cut-down mode. The endpoint sends a user id and the Mideye Server resolves the phone number or token itself, reaching the Mideye cloud on the endpoint's behalf where a phone method needs it, so the Windows host never needs internet access. A server with no cloud channel at all reports that fact, and the logon tile falls back to hardware-token OTP rather than leaving the user waiting.
Safe defaults
Fails closed, without locking you out.
Built to keep secrets away from non-admin eyes, keep PII out of the logs, and make a bad deploy harmless.
Lockout-resistant
A misconfigured deploy is silently inactive, not lockout-causing, and activation refuses without at least one Break-Glass principal. Mideye also will not become the only tile on a surface until a real logon there has proved it can admit someone.
Secrets locked down
API credentials live in a registry key readable only by SYSTEM and Administrators, and are never written to logs or exports. They never leave the host.
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.
1
Interactive MSI
Pilot install on a single host: wizard, license, install, configure.
2
Silent MSI
msiexec /qn for SCCM, scripted rollouts, and custom orchestration. Per-host JSON config applied separately.
3
Group Policy
Software Installation policy plus a startup script that applies the per-OU JSON config. Built for AD-joined fleets.
Documentation
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.
Read the overviewQuickstart
Zero to MFA on RDP in ~10 minutes: install, paste Client ID and Secret, add Break-Glass, activate, then prove a logon.
Open the quickstartArchitecture
How the credential provider DLL plugs into Windows LogonUI; the MFA decision ladder; cloud and on-prem flow diagrams.
See the architectureFAQ
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. That is about 10 minutes per host. Activation protects RDP and the console together, and it protects itself first: MFA is demanded from the first logon, but the standard Windows tile stays visible until the host has completed one successful Mideye logon on that surface. A configuration that cannot admit anyone therefore leaves you a way in instead of locking out the machine. Once a real logon has proved the host, Mideye becomes the only tile.
Does Mideye Credential Provider work without internet?
Yes. In on-prem mode the credential provider talks only to your local Mideye Server, over a static Bearer token, and the endpoint needs no internet access of its own. On-prem is not a reduced mode: Touch-Accept and Assisted Login work there too, because the Mideye Server makes those calls on the endpoint's behalf. On a genuinely air-gapped server, which reports that it has no cloud channel, the logon tile falls back to hardware-token OTP, which needs no network at all. A single registry value picks cloud or on-prem per machine.
What Windows versions are supported?
Windows Server 2019, 2022 and 2025, and Windows 11 (23H2 or later) desktops. x64 only. Every DLL change is verified in the lab on one client each of Server 2019, 2022 and 2025 before release, because credential-provider behaviour differs between those versions in ways that can lock users out. Both Active Directory domain-joined and workgroup / standalone hosts are supported. Windows 10 and Windows Server 2016 are not supported - both leave Microsoft support in January 2027. Entra-ID-joined and hybrid-joined machines are not tested yet.
Is the Mideye Credential Provider generally available?
It is in early access. Everything described on this page is implemented and documented, and we are running supervised pilot deployments ahead of the 1.0 release. Contact us to join the early-access programme and we will plan the rollout with you.
Ready to evaluate?
Run the 10-minute quickstart on a test VM, or talk to us about an early-access pilot in your environment.