MFA for data centers: Securing access to Windows data center applications
How data centers providing remote client access to Windows data center applications use UserLock MFA.
Published March 18, 2026)
)
)
)
For many data centers and hosting providers, Microsoft Remote Desktop Services (RDS) remains a core platform for delivering Windows applications to remote users. By hosting applications centrally and publishing them through technologies such as RemoteApp, RD Web, and RD Gateway, organizations can provide secure access to mission-critical Windows software without installing it on individual user devices. However, implementing multi-factor authentication (MFA) for data centers in these scenarios can quickly become complex.
RDS is a centralized system that makes it possible for employees, partners, or clients to access Windows applications remotely from any device. Often described as legacy software, it turns out that large numbers of companies are still heavily dependent on Windows applications, including Microsoft’s own apps, to carry out a wide range of tasks.
Running those applications on a local PC is hard to manage in our era of remote and mobile working, where not everyone uses a Windows device. RDS overcomes this by running Windows applications centrally and serving or “streaming” them to users, where they appear to run locally.
This usually happens using Microsoft’s RD Gateway as the secure proxy without the need for a VPN connection:
RemoteApp is the standard method, making data center applications accessible via client software called Windows App (formerly Remote Desktop).
RD Web is a variation offering non-Windows and BYOD support, giving browser-based access to applications via an IIS web server.
Remote Desktop provides access to a complete Windows desktop, including applications.
Why MFA is difficult to implement on client access to data center applications hosted via Remote Desktop Services (RDS)
Because these are remote connections, they represent a major security risk. MFA is one of the best ways to mitigate that risk. However, this is not easy to achieve using Microsoft’s native on-prem tools, such as RADIUS/Network Policy Server (NPS), which is why many organizations look for alternatives.
UserLock’s approach is similar to deploying a dedicated on-premises MFA solution integrated with Active Directory (AD) to authenticate remote users.
The MFA prompt presented to the user is triggered by UserLock agents installed at different points, depending on the RDS architecture in use.
Because, in an RDS environment, authentication can occur at different points, such as the entry portal (IIS/RDWeb), the gateway (RD Gateway), or the session host itself (RemoteApp/Remote Desktop), UserLock provides MFA through its agents deployed on RDWeb and RD Session Hosts.
For many data centers, implementing MFA on the RD Gateway connection is the default. This authenticates users at the perimeter before they access the RemoteApp server, also called the RD session host.
The limitation of relying on RD Gateway alone is that it does not provide strong authentication by itself. It only secures the transport layer (HTTPS) and controls access, but does not enforce MFA.
To ensure strong authentication for both external and internal sessions, MFA must be applied at the RD Session Host (RemoteApp/Remote Desktop) level.
With UserLock, MFA is enforced at the session host, meaning users authenticate only once, and no duplicate MFA prompts occur.
RD Web is a third approach. In this scenario, data centers can apply MFA on the RD Web connection via IIS, which acts as a web front door for the application server.
Try UserLock MFA for data centers
Start your free 30-day trial with unlimited users, no credit card required, and technical support every step of the way.
A hosting company deployed UserLock to provide MFA for a large base of SMB customers remotely accessing custom SAP Windows applications via RemoteApp and RD Web through RD Gateway.
In this setup, the simplicity of the user experience was critical. Hosting clients didn’t want users to jump through unnecessary hoops to authenticate.
RemoteApp makes this straightforward. The application is served or published remotely, but feels as if it is being run locally. It appears in the Windows Start menu alongside other applications, just as if it were installed on the device.
UserLock keeps security simple. Infrastructure stays lean, since UserLock requires only a single agent (called the Desktop Agent) on to apply MFA and context-aware access controls on RemoteApp access.
Admins configured UserLock to prompt once per session, a specific duration, or for specific users or AD OU Groups. This lets admins set the right level of authentication without adding friction for end users.
For RD Web access via IIS, the web server processes authentication requests before they reach the host server. In this scenario, the UserLock agent is installed on the IIS server, enabling the same user configuration options described above.
Accessing applications today can happen from multiple locations, on multiple operating systems and devices, and at any time of day or night. This makes MFA an essential security control, even if implementing it is not always straightforward.
Remote access to Windows applications via RDS for data center clients is a special use case. Windows was not set up to make MFA support a simple plug-and-play, not least because where the MFA prompt is applied depends on how RDS is being used.
UserLock’s agent-based deployment model gives organizations the flexibility to choose for themselves, without forcing a choice between security and simplicity. MFA can be applied at one of several access points depending on the specific deployment. Wherever authentication occurs, admins can get the same configuration options and access controls, all tied directly to AD policies.