Implementing Essential Eight: Multi-Factor Authentication (ML1)

Multi-factor authentication is a lynchpin of strong cyber security. It’s also required to reach Essential Eight Maturity Level 1, the government-recommended standard for SMBs.

If you’re working with your IT provider to get to Maturity Level 1, this guide will explain everything you need to know about multi-factor authentication – including hardening tips like Token Protection.

What Is Multi-Factor Authentication?

Multi-factor authentication (MFA) is exactly what it sounds like. When you try to log into an app or another service that has MFA, you’ll need to supply at least 2 proofs of identity to succeed. Proofs of identity can include:

• something you know (such as a PIN or secret question)
• something you have (such as a passkey or digital token)
• something you are (such as a fingerprint or facial scan).

MFA, which was previously known as ‘two-factor authentication’ or ‘2FA’, was developed to protect users from password theft. Without it, an adversary could steal your username and password to an application (say, Microsoft 365) and log in from anywhere in the world. MFA acts as a critical second check that prevents a lot of unsophisticated attacks.

Implementing Multi-Factor Authentication

Because of multi-factor authentication’s effectiveness, it’s required for almost all online applications under the Essential Eight. In most cases, it isn’t hard to set up. Whenever you roll out a new online service that might have access to sensitive data – a CRM, project management software, Microsoft 365 – MFA should be enabled at the point of user account creation.

If a service doesn’t support MFA, you’ll need to talk to your IT provider about a compensating control. (It’s also worth asking yourself why a service doesn’t have MFA. Given MFA’s ubiquity in modern cyber security, its absence probably means there are bigger, more structural security concerns with the service in question.)

Like most things in cyber security, though, multi-factor authentication is necessary but not sufficient. Certain kinds of attacks, like adversary-in-the-middle attacks, can breach it. Your MFA implementation should always be hardened – complemented by additional controls that make it much, much more resilient. I cover 2 of the most effective (geo-blocking and token protection) below.

Geo-Blocking

Should someone be allowed to access your Microsoft 365 tenancy from anywhere in the world? China? Russia? Iran? Even if they have the right credentials, the answer is probably ‘no’. Microsoft Entra’s Conditional Access policies let you put conditions in place around when and where people can log in – and from what devices.

One of the most effective Conditional Access policies involves blocking access based on location. If your staff only work in Queensland, for example, there’s no reason someone in Singapore would need to access your 365 tenancy. Even if they manage to compromise one of your staff accounts, they’ll be blocked from accessing any resources.

Token Protection

When you log into an online service, you’ll generate something called a ‘session token’. This is a bit like getting a wristband at an event. You’ve shown the service your ‘ticket’ (your login credentials), then the service has given you a ‘wristband’ (the token) so you can come and go for a certain amount of time without needing to log in again.

Adversaries, though, can steal your tokens to access your account themselves. Exactly how that process works is complicated – see here for a detailed breakdown – but the important takeaway is that it can’t be prevented by standard MFA. Instead, you’ll need to invest in something called ‘Token Protection’.

Token Protection is a Conditional Access policy that can be set up through Microsoft Entra. It essentially generates tokens that are ‘bound’ to individual devices that are managed via Entra. That means only logins from the device in question will work. Even if an adversary steals the token, they can’t use it. (Think of a bit like a wristband that has your face printed on it – it only works when you’re wearing it.)

Token Protection does have some limitations – for example, it can only be used with native apps, not web apps – so it should be paired with other Conditional Access policies like disabling persistent browser sessions for maximum effectiveness.

Acceptable MFA Implementations

The Essential Eight doesn’t view all multi-factor authentication methods as equal, and for good reason. Certain kinds, such as push notifications, are discouraged because they’re vulnerable to fatigue-based attacks (spamming users with notifications until they accidentally accept). Others, like biometrics and Trust Signals, are disallowed for technical reasons.

The simplest kind of acceptable multi-factor authentication is a one-time password or number matching via a phone-based authenticator app like Microsoft Authenticator. If the authenticator app requires a password or PIN to access, it will meet the requirements for ‘have’ (the app itself) and ‘know’ (the password/PIN).

With that said: authenticator apps aren’t considered phishing-resistant. They’re still vulnerable to token theft. A better implementation is to use Windows Hello for Business, which uses a technology called FIDO2 to authenticate logins cryptographically. To comply with Maturity Level 1, set up Windows Hello to only allows PINs or security keys and require a TPM chip (a physical piece of hardware in a device that stores cryptographic keys and other security information).

If Windows Hello isn’t an option, hardware authenticators like YubiKeys are secured with a PIN (‘know’) and must be physically pressed (‘have’) to permit a sign-in. Like Windows Hello for Business, they’re considered phishing-resistant – more than sufficient to meet Maturity Level 1.