Protect Legacy Technologies with Multi-Factor Authentication


The Common Challenge of Protecting Legacy Technologies & Private Resources

Many organizations rely on a mix of legacy or older technologies and private resources as part of their core business systems.

These technologies typically have been around for a long time and may be difficult to both replace (because production systems and flows rely on them) and secure (because MFA was not common when older technologies were designed).

This article explains how you can use Twingate to protect resources that were never designed for it with Multi-Factor Authentication.

Here are some examples of such technologies that do not typically benefit from Multi-Factor Authentication or integration with Single Sign-On (SSO):

  • secure shell (ssh)
  • remote desktop servers (RDP, Citrix, Windows Remote Desktop Services)
  • databases servers, (Microsoft SQL Server, MySQL, Oracle, PostgreSQL, etc.)
  • file sharing servers
  • custom web apps on web servers

Beyond the security concern, there is often a practical & logistical aspect creating further friction: removing access to an employee no longer needing access to such a resource often requires manual & specialized work.

Both of these issues represent security exposures that are easy to remedy with Twingate.

Multi-Factor Authentication with Twingate

Twingate allows you to layer on MFA to any legacy technology by applying a Security Policy.

Since Twingate also leverages your Identity Provider, you will be able to require users to authenticate with it before accessing those legacy resources which means much easier management when an employee leaves your organization: no more left over access requiring app-specific intervention every time.

Simply disable their SSO account and.. voila!

How It Works

Twingate monitors requests from any user device at network level: If the request is meant for a resource secured by Twingate, Twingate holds the request while checking and enforcing the associated Security Policy.

For example: if Twingate determines the user is authorized to access your Mainframe but the applicable Security Policy requires MFA, Twingate will prompt the user for MFA Authentication and only if authentication succeeds will Twingate allow the request through.

If a user doesn’t have authorization to access the resource, the request never leaves the device, rendering the requested app completely inaccessible (even if the user somehow obtained valid credentials for it).


Because Twingate works at network level, nothing about the legacy application or technology needs to be changed or reconfigured to allow this to work.

Did this page help you?