Phishing-Resistant Multi-Factor Authentication

Phishing resistant Multi-Factor Authentication (MFA) is on track to become the de facto standard when enterprises and organizations look to roll out new authentication solutions. However, the technologies behind this term, and the capabilities, deployment steps, and supporting infrastructure can take many shapes. This guide aims to equip you with knowledge needed to deploy a new Phishing resistant MFA solution, or take the needed steps to enhance and upgrade your existing tooling to meet this standard.


Phishing resistance is more than a buzzword, it’s the best way to protect authentication
processes. Many methods exist to achieve this goal, learn more about them
here: Phishing-resistant authentication methods


As with any journey, it is important to begin by defining your goals and objectives. The following pages should help you navigate this path, provide links to documentation needed to perform the technical and non-technical deployments, and highlight use cases that may help determine details about your deployment.


One should begin by looking at the types of technologies they wish to secure. Here is a short list of common tooling that our professional services teams have encountered and successfully integrated with phishing resistant MFA solutions:

  • Windows
  • MacOS
  • *nix
  • Android
  • iOS
  • RDP/Remote Desktop solutions
  • Citrix Storefront
  • VMware Horizon
  • …and many more

As with any major technology effort, we suggest performing an inventory of the technologies that you wish to secure within your existing infrastructure. This can help determine the best path forward and highlight any potential roadblocks you may be able to head off.


Use Case Information
If you have questions or need more details about how specific use cases translate to
authentication solutions you can view this Use Case article.


I have an on-premise MS Active Directory

  • We have Microsoft Active Directory Servers that are deployed on premise and do not synchronize with Azure Active Directory (It may synchronize with other directory services like Google Directory Service, Oracle Directory or RadientOne.)
  • Workstations, Servers and Laptops are ‘Domain Joined’ and End Users log in with domain accounts (DOMAIN\USER) via Windows login or with a locally installed SSO client (Ping, Safenet, others.) Web based SSO portals often have different credentials.

I have Hybrid Azure Active Directory

  • We have Microsoft Active Directory servers that are deployed on premise and use the Azure AD Connect to synchronize accounts to an Azure Domain.
  • Workstations, Servers and Laptops are joined to the domain and log in with either domain (DOMAIN\USER) or Azure (USER@DOMAIN) accounts. End users can log in locally, via a local SSO client, or to web portals via a SSO client with the same credentials.

I have Azure Active Directory

  • We only have Azure AD for directory tasks, with no on premise domain controllers.
  • Servers, Workstations and Laptops may be joined to the Azure domain and users log in with Azure credentials (USER@DOMAIN) OR users may log into them with local credentials. Most resources are protected via SSO Login based on a web client. Local applications will require Azure credentials (USER@DOMAIN) to log in via the web.

I have another Directory system

  • We have a non Microsoft Active Directory system. These can be locally hosted directory tools (OpenLDAP, Radiant Logic VDS, others.) or cloud based directories (Google Directory Services, Oracle Directory Services, RadiantOne, others) or some combination of the two.
  • Laptops, Servers and Workstations are not domain joined, and are generally accessed via Local credentials or via a locally installed SSO client. Resources are accessed via SSO protected Web portals or via custom LDAP Integrations.

I have no directory system

  • We do not leverage a central directory of users, instead we grant users access manually via inbuilt tools, SSO portals connected to individual/personal accounts, or via shared accounts.