Adding multi-factor authentication to a modern identity platform is a configuration exercise. Adding it to a legacy VDI gateway is a project. The gap between those two things is where a significant share of GCC IT security spend gets consumed — not in the MFA itself, but in the integration work required to make MFA behave correctly in front of an environment that was designed a decade before phishing-resistant authentication was a standard requirement.
The specific problem comes up repeatedly in a pattern that most GCC IT teams will recognise: Citrix StoreFront or NetScaler Gateway, an older VMware Horizon environment, or an RDS deployment that has been extended several times since its original build. The organisation needs MFA. The identity platform is Entra ID or an on-premises Active Directory with no clean SAML endpoint. The result is a project that touches the gateway configuration, the RADIUS stack, the NPS extension, and often a custom IDP proxy — a four-week integration with three vendors involved and no single owner.
Why the Standard Approach Gets Complicated
The default path for adding MFA to a legacy gateway is the Azure MFA NPS Extension, which places an NPS server between the VDI gateway and Active Directory and intercepts RADIUS authentication requests. It works, with caveats. The NPS extension requires the NPS server to have internet access to reach Azure MFA endpoints. It does not support hardware tokens without additional configuration. It has known limitations with RADIUS Challenge-Response flows that some gateway implementations rely on for OTP delivery. And it creates a hard dependency on Azure MFA availability for every VDI logon — which is fine until it is not.
Organisations running SAML-capable modern gateways (Citrix Cloud, current-generation Horizon) have a cleaner path: configure an Entra ID Enterprise Application, set up SAML federation, and MFA follows conditional access policy. But legacy on-premises deployments — the ones that were never migrated to cloud-managed gateways, often because the migration cost was deferred and then deferred again — do not have a SAML endpoint. They speak LDAP and RADIUS, and the modern identity approach does not have a clean on-ramp for those protocols.
What a Sensible Architecture Looks Like
The right approach for legacy VDI gateways is an identity broker that speaks the gateway’s native protocol inbound and connects to a standards-based MFA provider outbound. The broker accepts LDAP or RADIUS from the gateway, validates the primary credential against Active Directory, triggers a second factor through whatever method the organisation has standardised on — TOTP app, push notification, hardware token, SMS OTP — and returns a successful or failed authentication to the gateway. The gateway never knows MFA is involved. The user experience is a secondary prompt after the primary password, not a gateway rebuild.
miniOrange provides this as a turnkey integration for Citrix StoreFront, NetScaler, VMware Horizon, and RDS environments. The platform supports RADIUS, LDAP, SAML and OAuth inbound, which means it can sit in front of legacy gateways that cannot be modernised without a full rebuild. It ships with pre-built connectors for the major VDI platforms — no custom development, no four-week integration project. MFA methods include authenticator app push, TOTP, hardware FIDO2 keys, SMS OTP, and email OTP, with per-application or per-group policy to apply different factors to different user populations.
The GCC Compliance Context
The urgency of this in the GCC is partly regulatory. The UAE’s Personal Data Protection Law, Saudi Arabia’s NCA Essential Cybersecurity Controls, and Qatar Central Bank regulations for financial services all include requirements for multi-factor authentication on systems that process personal or financial data. Legacy VDI environments that provide access to ERP, banking applications, or patient records fall squarely within scope. “We plan to implement MFA” is no longer an acceptable audit response in any of these frameworks — the control is expected to be in place and evidenced.
The practical question for most GCC IT security teams is not whether to implement MFA but how to do it without a six-month gateway migration project running in parallel. An identity broker that adds MFA to the existing stack without requiring changes to the gateway itself is typically the answer that fits the timeline and the budget.
If you are running a legacy VDI gateway that needs MFA and have been deferring it because the integration looked complicated, we run 30-minute architecture sessions to map the specific gateway configuration against the integration options. Reach out through our contact page to book one.