Open-source alternative to Duo for Windows Logon and RDP

Can privacyIDEA replace Duo for Windows logon and RDP?

For Windows estates, privacyIDEA's Windows credential provider is the self-hosted option for second factors on console logons and RDP sessions, but the gaps need confirming before you plan a switch. Your starting point is usually one of three situations: a Duo renewal, a Windows Server 2016 deadline, or a policy that keeps server logon checks inside your network. Duo's Windows Logon and RDP client adds two-factor authentication to local console logins, incoming RDP sessions and, from version 4.1.0, credentialed UAC elevation. It does not cover PowerShell remoting cmdlets, non-interactive logons or RDP Restricted Admin Mode. Map each of those paths to your administrator workflows before you assume the replacement covers them.

Windows Server 2016 affects both products. Duo states that its support for Windows Server 2016 in this client ends in January 2027, together with Microsoft's support. That date is a planning input for either option. If you keep 2016 hosts running past it, you carry unsupported operating system risk whichever MFA product you use. Ask the privacyIDEA project and its commercial supplier, NetKnights, which Windows versions their credential provider supports, and confirm that the build you deploy runs on your server generation. Upgrade the hosts first or in a separate window so the MFA change is not the only change you are testing.

Two behaviors need a written decision before cutover: offline access and what happens when the MFA server is unreachable. Duo's offline access for Windows Logon is available on Duo Essentials, Advantage and Premier. Otherwise the client contacts Duo's service on TCP port 443, and the FailOpen setting decides whether users can log in without a second factor when Duo is unreachable. The privacyIDEA documentation does not settle how its credential provider handles cached logons or unreachable servers in the same way, so confirm this with the project and test it in a lab. Disconnect the MFA server from a test host, attempt a logon, and record the result. Repeat the test for laptops that leave the network.

Which Windows logons each option protects

This table maps each Windows logon path and factor against Duo's documented coverage, privacyIDEA's Windows credential provider, and Keycloak or authentik. Read the Duo column as the baseline your replacement must match, then check each other column for the gaps. Confirm how privacyIDEA handles every excluded path in its Windows documentation and a test lab before any cutover.

Logon path or factor	Duo Authentication for Windows Logon and RDP	privacyIDEA Windows credential provider	Keycloak or authentik
Local console logon	Yes	Windows logon is the credential provider's purpose. Test on each Windows build you run.	No Windows logon provider in the supported scope. Confirm with the vendor before planning.
Incoming RDP sessions	Yes	Confirm RDP handling in the privacyIDEA Windows documentation and a lab.	Not a direct RDP control. Confirm the vendor's position before relying on it.
Credentialed UAC elevation	Supported from client version 4.1.0	Confirm whether elevation prompts are covered on your Windows version.	Not a UAC control. Confirm with the vendor.
PowerShell remoting cmdlets	No	Confirm exact coverage in privacyIDEA's Windows documentation and a test lab.	Confirm exact coverage with the vendor and in a test lab.
Non-interactive logons	No	Confirm exact coverage in privacyIDEA's Windows documentation and a test lab.	Confirm exact coverage with the vendor and in a test lab.
RDP Restricted Admin Mode	No	Confirm exact coverage in privacyIDEA's Windows documentation and a test lab.	Confirm exact coverage with the vendor and in a test lab.
Offline access when the MFA service is unreachable	Offline access on Duo Essentials, Advantage and Premier; otherwise FailOpen decides	Confirm offline behavior and any cached logon option for your version.	Confirm offline behavior for Windows logon with the vendor.
Factors: push, FIDO2, smartcard, TOTP	Duo push and Duo's factor set; confirm which factors apply to logon in your edition	Supports FIDO2, PIV or x509 smartcards, push, TOTP and HOTP; confirm which the provider accepts	Keycloak OTP and WebAuthn cover SSO logins; confirm which apply to Windows logon

Which open-source option fits Windows logon needs

Replacing Duo for Windows logon and RDP is mostly a question of which component carries the second factor on the Windows host. The cards below separate the credential provider that does that job from the PAM and RADIUS paths meant for other systems, and from the directory services that supply users but do not add a factor.

privacyIDEA Windows credential provider

This is the primary fit for Duo's Windows Logon and RDP client, since privacyIDEA integrates with Windows logon through a credential provider and is licensed under AGPLv3. Confirm that the provider covers each logon path you need today, including console logon, incoming RDP and credentialed UAC elevation, because Duo's own coverage has limits you should match or document. Test RDP with your current session policies before cutover.

Offline and unreachable MFA behavior

Duo's client offers offline access on certain plans and a FailOpen setting that decides whether users log in without a second factor when Duo cannot be reached. A self-hosted MFA server changes where that risk sits: if the privacyIDEA server or its network path is down, you decide the fallback. Write down the intended behavior for console, RDP and local administrator accounts, then test it with the MFA server stopped.

PAM module for Linux hosts

For mixed estates, privacyIDEA's PAM module covers Linux logins rather than Windows ones, so it is an adjacent path, not a replacement for the credential provider. Use it for the SSH and console logins that Duo Unix currently handles on Linux servers. Verify the factor set and fallback behavior on each distribution you run, since the facts supplied do not list per-distribution support.

RADIUS for network and VPN access

privacyIDEA's RADIUS integration serves VPNs and network devices that send RADIUS requests, which is a different flow from Windows logon. Choose it when the Windows estate also has VPN concentrators, which Duo often protects through its proxy. Confirm with your vendor that each device can send the RADIUS fields privacyIDEA expects, and test the challenge-response flow before you retire the Duo proxy.

FreeIPA as a directory source

FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD, and can create mutual trusts with Microsoft Active Directory. It supplies identities and Kerberos authentication, but it does not add a second factor to Windows logon by itself. privacyIDEA can read users from LDAP stores, so a FreeIPA deployment can serve as the user source behind the MFA layer. Confirm the trust and attribute mapping in your own lab.

Samba AD as a directory source

Samba AD can take the role of a domain controller for user accounts, group membership and Windows logon authentication. As with FreeIPA, it is a directory source, so the second factor still has to come from privacyIDEA or another MFA component. Check that your Windows clients join and authenticate against Samba as expected, and that the LDAP attributes privacyIDEA needs are exposed to it.

What happens when the MFA server is unreachable

Duo's Windows client behaves in one of two ways when its service cannot be reached, and the reader's first task is to find out which one applies to each logon path. By default the client needs outbound TCP 443 to Duo's cloud to verify the second factor. Offline access for Windows Logon is available only on Duo Essentials, Advantage and Premier, so a lower tier has no offline fallback. Separately, a FailOpen setting decides whether a user can log in without a second factor when Duo cannot be reached. Confirm the tier on the current Duo contract and read the FailOpen value in the deployed client configuration on every server, because the two settings are easy to assume rather than verify.

With privacyIDEA there is no equivalent default to inherit. The credential provider's behavior when the privacyIDEA server is down, the availability of cached or offline credentials, and any fail-open option must be designed and tested in your own environment. Test each logon type: console login, RDP into a server, RDP into a workstation, and the account used by scheduled tasks or services. Simulate an outage by blocking the path to the privacyIDEA nodes, then record exactly what each user sees. Keep the design in writing, and confirm the current credential provider options against the privacyIDEA documentation for the version you deploy.

Fail-open is a risk decision, not an engineering default. Name an approver, usually the CISO or the owner of the access policy, and record the reason, the scope (which servers and groups), the duration and the compensating control, such as alerting on local logons during the outage. Break-glass accounts need their own procedure: keep a small number of named local administrator accounts, store their credentials offline under dual control, exclude them from normal MFA only where the approved design requires it, and test that the accounts still work during a simulated outage. Review each break-glass use after the event and rotate the credentials.

How to move Windows logons from Duo to privacyIDEA

This sequence moves Windows console logons, RDP sessions and UAC elevation from Duo's cloud-dependent client to privacyIDEA's credential provider, with a tested fallback and a clear fail-open decision before any host is switched. Each step closes with a check, so the cutover happens by host group rather than all at once.

Inventory Duo-protected hosts and logon types
Ask the Windows administrators to list every server and workstation where the Duo Authentication for Windows Logon and RDP client is installed, and record which logon paths each one protects: local console logons, incoming RDP sessions and credentialed UAC elevation. Note any hosts where Duo does not apply, such as PowerShell remoting or non-interactive logons, so those gaps are documented rather than assumed covered. Confirm which hosts use offline access and which FailOpen setting is configured. Done when you have a host register with protected logon types, client versions and current FailOpen settings for each machine.
Confirm Windows Server version support path
Check the operating system version of every host in the inventory. Duo states that its support for Windows Server 2016 in this client ends in January 2027, together with Microsoft's support for that release, so any 2016 host needs a replacement or upgrade plan that finishes before that date. Confirm with Microsoft's lifecycle documentation and your own support agreements which versions remain supported for the privacyIDEA credential provider, and ask the vendor to confirm compatibility in writing. Done when every host has a named OS version and a supported path, and the 2016 hosts are listed with an owner and a date you have agreed internally.
Stand up privacyIDEA with an LDAP resolver
Deploy privacyIDEA on infrastructure inside your network, following the installation guidance for your Linux distribution, and connect it to the directory that holds your Windows accounts through an LDAP or Active Directory user ID resolver. Set up the service accounts, TLS for LDAP, and the admin roles the team will need. Test that a sample of users resolves correctly, including users in nested or disabled groups. Done when privacyIDEA lists the expected Windows users from the resolver and an administrator can log in to the management interface, with the test results kept for the change record.
Enroll users with a fallback method
Enroll each pilot user with a primary factor such as push through the privacyIDEA Authenticator app, FIDO2 security keys or TOTP, and register a second method so no one is locked out if a phone is lost or a device fails. Users who already use standard TOTP apps can keep them, but push requires the privacyIDEA Authenticator app. Re-registration of existing Duo Mobile users and any hardware token imports follow the separate migration guide, so this step only covers the enrollment rules you set for Windows logons. Done when every pilot user has a primary and a backup factor, and the help desk has a documented recovery procedure.
Pilot the credential provider on a test OU
Install the privacyIDEA Windows credential provider on a small set of test machines placed in a dedicated test organizational unit, and run the full set of logon paths against them: console logon, RDP sessions, UAC elevation and a failed second factor. Test the behavior when the privacyIDEA server is stopped or unreachable, and compare it with what Duo did under the same conditions in the inventory. Record any logon path that the credential provider handles differently from Duo's coverage. Done when every logon type in the inventory has a pass or fail result on the test hosts, and each difference from Duo has an accepted decision.
Define offline and fail-open policy
Decide, in writing, what happens when privacyIDEA cannot be reached and whether any users may log on without a second factor. Compare this with Duo's behavior: Duo's offline access for Windows Logon depends on the Duo edition, and otherwise the client needs its service on TCP port 443, with the FailOpen setting controlling whether users log in without 2FA. Set the equivalent policy for privacyIDEA, including whether cached offline logons are allowed, which accounts are exempt, and who approves changes. Have the security owner sign off. Done when the policy document names every host group and the fail-open setting for each, and the approver has signed it.
Cut over by host group
Move hosts to the privacyIDEA credential provider in small groups, starting with the lowest-risk servers and ending with privileged administration hosts. Before each group changes, confirm a rollback path exists, such as a documented way to reinstall the Duo client, and take a snapshot where the platform allows it. After each group, test console, RDP and UAC logons with a pilot account and confirm the help desk has no unexplained lockouts. Done when each host group shows successful logon tests, the change log records the date and approver, and no group is left in an unknown state.
Retire the Duo client and keys
After every host group has been stable for a period your change board sets, uninstall the Duo Authentication for Windows Logon and RDP client from each machine and remove the integration keys from the configuration. Revoke the Duo integration in the Duo admin console for this use, and confirm that no host still contacts Duo's service. Keep the final inventory, the policy document and the test records as evidence for your audit file. Done when a scan of the host fleet shows no Duo client installed, the Duo integration is disabled, and the closure record is filed.

Running privacyIDEA beside the rest of Duo during the cutover

Many Windows servers will keep Duo for other reasons during the transition. A host may still sit behind the Duo Authentication Proxy for a VPN, use Duo for SSO, or rely on Duo Unix for SSH on the same fleet. Leave the Duo Windows Logon and RDP client in place on these hosts until their own cutover window, and do not remove it just because another Duo integration has moved. Each integration should be inventoried on its own so no logon path loses its second factor by accident.

Inventory per integration: List which Duo integrations each host uses, including the Windows client, the proxy, SSO applications and Unix modules.
Keep the Duo client until its window: Do not uninstall the Windows client on a host until privacyIDEA is verified for every logon type that host serves.
Protect shared accounts: Accounts that reach several integrations should keep a working second factor on every path during the transition.
Document exceptions: Record which hosts remain on Duo and why, so the list is reviewed before the contract ends.
Avoid double prompts: Confirm that a single logon does not trigger both Duo and privacyIDEA challenges.

Before leaving any host in this state, check the Duo documentation for the Windows client and confirm how its FailOpen and offline settings behave on that host.

What do teams ask before replacing Duo for Windows logon?

Does privacyIDEA cover UAC elevation and PowerShell remoting?

Confirm this in a lab before you commit, because the facts available for this page do not list privacyIDEA's coverage by logon type. Duo's client protects local console logins, incoming RDP sessions and, from version 4.1.0, credentialed UAC elevation. It excludes PowerShell remoting cmdlets, non-interactive logons and RDP Restricted Admin Mode. privacyIDEA integrates with Windows logon through a credential provider, so ask the vendor and your test results whether each of these paths triggers the second factor on your Windows versions. Record a pass or fail for console logon, RDP, UAC prompts and remoting. Any path that stays outside MFA needs a compensating control, such as limiting remoting to hardened jump hosts and logging administrative sessions.

What happens to Windows logons if the MFA server is down?

The answer depends on the configuration you choose, and you should decide it in writing before rollout. Duo's client needs outbound access to Duo's cloud on TCP port 443, and its FailOpen setting decides whether users can log in without a second factor when Duo is unreachable. Offline access for Windows Logon is available on Duo Essentials, Advantage and Premier. For privacyIDEA, confirm the offline and unreachable-server behavior of its credential provider for your version before finalizing the design. Plan for high availability with at least two privacyIDEA nodes close to your domain controllers, define fail-closed or fail-open per logon type, keep break-glass administrator accounts under controlled custody, and test each failure case with the server stopped.

How long does a Windows logon MFA rollout take?

No duration is supplied for this work, so ask for a timeline in the written scope instead of relying on a generic figure. The main drivers are the number of hosts, the mix of Windows versions, and the directory design. Duo states that its support for Windows Server 2016 in this client ends in January 2027, together with Microsoft's support, so any Server 2016 estate needs an upgrade or replacement plan with a fixed date. Directory design matters because privacyIDEA reads users through LDAP or Active Directory resolvers, and nested groups, multiple domains and service accounts add testing. Enrollment volume, the size of the pilot group and approved change windows also set the pace. Ask for the schedule to be tied to these inputs.

What does self-hosting privacyIDEA for Windows logon cost?

The cost is a set of components, and most of them recur. The privacyIDEA software is licensed under AGPLv3, so there is no license fee for the open-source edition itself. Expect costs for the servers that run it, including a second node for high availability and a non-production copy for testing, plus any operating system and database licensing your standards require. An optional NetKnights Enterprise Edition subscription is available if you want vendor support. Recurring items include SMS messages if you enable SMS, replacement hardware tokens, and staff time for patching, upgrades, enrollment and help desk calls. The one-time items are design, deployment, Group Policy work and testing. Compare this model with Duo's published per-user editions, and ask any implementer to itemize each component in the quote.

Can an internal team deploy privacyIDEA for Windows logon alone?

A capable internal team can do it if it has Linux server administration skills, working knowledge of your LDAP or Active Directory layout, and experience deploying Windows components through Group Policy. privacyIDEA's installation documentation covers installation with pip and on Ubuntu and CentOS or RHEL-family systems, so the server build is standard work. The risk sits in the Windows side. A faulty credential provider rollout can lock users out of workstations or servers, so the team needs a lab that mirrors production, a staged pilot, a tested rollback and documented break-glass access. If nobody on the team has done a credential provider rollout before, plan for outside help on that stage and keep the rest in house.

How should a team test privacyIDEA for Windows logon in a lab?

Build the test environment on the same installation path you plan to use in production, following the privacyIDEA installation documentation. Connect it to a copy of your directory, or a read-only test resolver, so you can check user lookups before any real account is involved. Enroll a small set of test accounts with standard TOTP first, then add push or other factors once the basics pass. Run a fixed test matrix covering console logon, RDP, UAC prompts, PowerShell remoting, non-interactive logons, offline use, and the server-down case. Keep dated results with the Windows build numbers. The matrix becomes the evidence your change board and auditors will ask for.

When should we ask DeployOpen for a fixed-scope quote?

Ask for a quote once you can describe the host inventory, the Windows versions in use, the directory layout, the factors you need and your target dates. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. DeployOpen does not publish a price list, so the quote follows from the written scope. DeployOpen also prepares systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications. Share your inventory early so the scope reflects your real environment.

What the self-hosted Windows MFA cost includes

The cost of replacing Duo Authentication for Windows Logon and RDP with privacyIDEA's Windows credential provider is spread across several components, and most of them are not license fees. The software itself is licensed under AGPLv3, so the main line items are the servers that run privacyIDEA in a highly available pair, the directory integration that resolves users from Active Directory or LDAP, the hardware tokens or passkeys you choose to issue, and any SMS gateway if SMS stays in the design. If you want vendor support, the optional Enterprise Edition from NetKnights is a separate subscription, and privacyIDEA.org is the place to confirm what it covers. Ask your Duo account team for current pricing and confirm which Duo edition includes offline access for Windows Logon, since that feature is limited to Duo Essentials, Advantage and Premier. Compare that edition against the full set of components above, not against the Duo line item alone.

Some costs are one-time and some recur. One-time work covers the design of logon scope, the pilot on a small set of Windows Servers and workstations, the cutover, and the credential provider packaging and testing. Recurring costs cover the MFA servers and their patching, directory maintenance, token replacement when hardware tokens are lost or fail, and the help desk time spent on enrollment and lockouts. Lockouts are often the largest hidden cost, because a user who cannot pass MFA on a console or RDP session needs a supervised recovery path. Your plan should define who can issue a recovery, how it is verified, and how often it is reviewed. Ask any implementation partner for a written scope that names the pilot exit criteria, the testing matrix covering offline and unreachable-server behavior, and the handover of runbooks, so the quote can be compared line by line with your internal effort.

Risks that delay or derail the Windows MFA switch

Most delays in a Windows MFA switch come from timing, enrollment and fallback decisions rather than from the credential provider itself. The cards below cover the risks that tend to surface late, each with a check you can run before cutover.

Windows Server 2016 support ends

Duo states that its support for Windows Server 2016 in its Windows Logon and RDP client ends in January 2027, together with Microsoft's support for that release. Any host still on Windows Server 2016 will need either an upgrade or a documented exception before that date, whichever MFA product you run. Check the inventory of logon and RDP targets now, and confirm with privacyIDEA's credential provider release notes that the version you plan to deploy supports every operating system in that list.

Lockout during enrollment

Switching the second factor for administrators and remote users before they have enrolled can leave them unable to log on at all. Enroll a small pilot group first, including at least one local administrator account that is excluded from the new policy until the rollout is complete. Confirm that each user has a working second factor and a recovery path before you remove Duo from their logon policy.

Unreachable MFA server without a tested fallback

Duo's client contacts Duo's cloud on TCP port 443, and its FailOpen setting decides whether users log on without a second factor when Duo is unreachable. A privacyIDEA deployment on your own network removes the internet dependency, but it adds an internal server that can also fail. Decide explicitly whether the credential provider fails open or closed, then test a logon with the MFA server stopped and with the network path cut.

Gaps in Restricted Admin and non-interactive logons

Duo's Windows Logon and RDP client does not cover PowerShell remoting cmdlets, non-interactive logons or RDP Restricted Admin Mode. A privacyIDEA credential provider covers the interactive logon path, so these flows may need separate controls, such as network segmentation, jump host restrictions or scheduled task accounts with managed credentials. Inventory these flows in your environment, then confirm in writing with privacyIDEA which of them the replacement covers.

Credential provider compatibility across versions

A credential provider runs inside the Windows logon process, so a mismatch with the operating system build or with other credential providers can block logons on a single host. Build a test matrix that covers each Windows Server and Windows client version in production, plus any smartcard or third-party provider already in use. Pilot each combination on a non-production host and record the result before expanding the rollout.

When privacyIDEA fits and when to keep Duo for Windows

privacyIDEA fits best when the MFA data and decisions must stay inside your own network, or when one self-hosted platform should cover Windows logon, Linux PAM, RADIUS for VPNs and web SSO instead of several vendor products. If your security policy or sovereignty rules require that enrollment records, token seeds and authentication logs never leave your data centers, a self-hosted credential provider talking to an on-premises privacyIDEA server is a direct fit. The same applies to isolated OT, defense or lab segments where the Duo client cannot reach Duo's cloud over TCP port 443. Teams that already run Active Directory and want one place to manage OTP, FIDO2 and smartcard factors for both console and RDP logons will find the consolidation argument strongest. Before committing, map every logon path you protect today, because the Duo feature set differs from privacyIDEA's, and some Duo behaviors have no direct equivalent that you should test.

Duo may remain the simpler choice where its cloud service, offline access tier and existing support contract already meet your requirements. If your Duo edition includes offline access for Windows Logon, you keep a second-factor path when the Duo service is unreachable, and a FailOpen decision your security team has already reviewed. A current Duo support agreement also means vendor escalation paths, documentation and update delivery that you would need to replace with your own runbooks, staff or an implementation partner. Ask your Duo account team to confirm which edition, offline tier and client version you run, and whether a Windows Server 2016 plan is needed, since Duo states its support for this client on Windows Server 2016 ends in January 2027 together with Microsoft's support. Those answers determine the migration deadline more than preference does.

Use the decision as a short written test: list the logon types in scope (console, RDP, UAC elevation, and any non-interactive or PowerShell remoting access that Duo does not cover), the offline behavior each requires, and the operating system timeline for each host. If on-premises data residency and offline MFA are mandatory, privacyIDEA deserves a proof of concept on one Windows host that tests the credential provider, the offline mode you need and the failure path when the privacyIDEA server is down. If the existing Duo contract, offline tier and support model meet all of these, keeping Duo for Windows and reviewing self-hosted options for the other MFA flows is a defensible decision. Document either outcome so auditors can see that the choice was deliberate.

How DeployOpen scopes and delivers Windows MFA replacement

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, including the privacyIDEA credential provider for Windows logon and RDP. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory which logons are protected today: console, RDP, UAC elevation and any other interactive paths.
Confirm the Windows Server versions in use, including the Windows Server 2016 support end that affects both Duo and the replacement plan.
Record the offline access and fail-open policy each account group needs, agreed in the written scope.

How we build

Deploy the privacyIDEA server and connect it to your existing Active Directory or LDAP user store.
Install and configure the Windows credential provider on a pilot group of servers and workstations.
Test console logon, RDP, UAC elevation and the behavior when the MFA server is unreachable before rollout.

How we hand over

Provide documentation of the architecture, configuration, factor policies and recovery procedures for your team.
Deliver the enrollment and help desk runbook covering lost tokens, device changes and emergency access.
Document the controls and evidence produced so your auditors can assess them independently.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan privacyIDEA version upgrades and patch the credential provider alongside Windows updates.
Confirm with your team which support tier and response expectations apply before the engagement starts.