Implementing multi-factor authentication

Using multi-factor authentication (MFA) would prevent a lot of the incidents we see. Credential harvesting campaigns and credential dumps can cause a lot of damage if the only control preventing unauthorised access is a password or PIN.

Below are steps you can follow to identify which systems would most benefit from configuring MFA.

Identify ways users can authenticate

Review the systems your organisation uses to understand the different ways a user can authenticate. This will help you identify:

  • what systems are being used
  • who uses them (for example all staff, or administrative IT staff)
  • how they are accessed (for example internet accessible, or internal network only)
  • if MFA is needed.

If you've recently completed our advice on changing default credentials, you should have an up-to-date knowledge of this already.

Changing default credentials

You should prioritise setting up MFA for high-risk systems, such as internet-facing systems and administrative systems.

Internet-facing systems are reachable over the internet and are considered high risk because anyone can attempt to authenticate. This includes systems that all staff use such as:

  • VPN
  • webmail
  • version control and code repositories (like GitHub)
  • social media
  • cloud services.

Administrative services are used to manage your organisation’s software or hardware, such as internet-exposed services like SSH and RDP. Access to these systems should be limited to your system administrators or IT teams.


If you're implementing MFA in an organisation with a lot of systems, focus on getting these high risk systems protected. Then consider the rest. You also want to consider any regulations or standards that may require you to have MFA configured, such as PCI standards.

Once you have identified the systems that need MFA, check if it is available. If you are a user of a system and have no control over authentication configurations, you will be reliant on the system owner or vendor providing this functionality. This is the case for most cloud services. If you manage the system and have control over authentication configurations, you will have to implement your own authentication module to handle new methods of authentication.

Configure MFA

Work out which of the methods available fit your needs best. The methods fall into three categories:

  • Something you know – This includes things like passwords, passphrases, PINs, or knowledge-based questions. On their own, these are weak forms of authentication as an attacker can steal a copy of it. They are usually easy to guess, where people use default or commonly used passwords, or easy to find, where people use non-unique or poorly stored/written down passwords.
  • Something you have – This includes hardware devices that store keys, provide one-time passwords (OTP), or produce push notifications. There are multiple options, listed below in preferred order:
    1. universal 2nd factor (U2F) security key devices (like a YubiKey)
    2. smartphone apps that provide a user with an approve/deny push notification.
    3. key fobs that generate a OTP
    4. smartphone apps that generate a OTP
  • Something you are – This includes biometric checks, such as fingerprint or face scans. This type of authentication is gaining popularity, especially with the latest smart phones from Samsung and Apple. This relies on the accuracy of the biometric scan and the uniqueness of the values and is not a secure authentication method on its own (single factor).

Which methods are available to you depends on who manages the system and what configurations they have available.

Enabling it on systems you use

If you’re a consumer of a system, you will need to enable MFA. Ask the system owner or vendor what MFA methods are available, for example Google Accounts offers OTP over smart phone app, push notifications to smart phone, and U2F. In some cases, you could also set up policies for your organisation’s account that forces all users to use MFA on their individual accounts.

Some systems may not have MFA available, and you should re-consider using the system as MFA configurations would have to be implemented by the system owner or vendor.

If there are several methods available to use, avoid ones that are easy to bypass, like OTP over SMS. If weaker authentication methods are your only option, it’s better than not having MFA at all. This is because the situation presents two different risks. For example, with OTP over SMS:

  1. Risk that an attacker gets unauthorised access to your account because they were able to brute force your password. This is an attack that is easy to automate and is low cost/low effort to an attacker. Using OTP over SMS removes you from the “low hanging fruit” pool of users.
  2. Risk that an attacker gets unauthorised access to your account because they are able get your OTP and your password. They can do this by identifying the number the gets the SMS notifications and attempt to transfer that phone number to a SIM card under their control. This is an attack that is more targeted and requires more time/effort from an attacker.

OTP that need to be entered into a system are not flawless as it requires you to transpose the number from your device to the system. Attackers can use phishing pages or social engineering in attempt to get this OTP from you.