Locking down your FIDO2 requirements

Continuing on from my previous post which I hope you found useful to get started with FIDO2: Enabling FIDO2 requirements is pretty easy, but that is only the first step on a long walk. Having FIDO2 enabled doesn’t automatically fix your security like magic, because there are still many threats to be aware of, and your job of keeping your accounts secure never ends.

❗ Create a strategy and define your requirements!

Before you even begin, you must have a strategy around your identity security with your authentication requirements written down. A mental note does not count! Perhaps it seems counter-effective to spend time on this when your days are busy and your task-list never ends, but this is a very important aspect of your cloud security. Whether it’s which MFA methods are allowed or the lifetime of your session tokens, this should be discussed and agreed upon and be a part of your organization’s strategy. You don’t have to make it huge and complicated and described over 15 pages, it’s perfectly fine to keep it simple and shorter. But have a plan! Don’t set this up haphazardly because a feature seems good or bad.

So for the rest of this blog post: We will assume that the requirement is that all elevated accounts (or can elevate through PIM) can only use FIDO2 keys, and TAP (or an existing FIDO2) for onboarding or reset/recovery.

Remove other MFA methods!

This may sound like a simple thing, but trust me that a lot of people doesn’t really consider this point. All accounts can have one or more MFA method registered. And even if you narrow this down using Authentication Methods blade in Entra ID, or with Conditional Access policies, it is a very good idea to remove all other MFA methods from the accounts in question. Especially if it is an account which has existed a long time. You may find a lot of weird stuff here, like on the picture below. In a large and complicated environment it is a real danger of loopholes in your configuration (and technical issues can always occur) which may result in a chance to sign in with a less secure MFA method. 😱

You’ve hopefully heard the phrase “Defense in depth”, which is a security strategy that you should have multiple layers of security features enabled. Like I personally like to say: Security should be in multiple layers, like an onion, and not have single layer like an egg has. This is a great example of just that principle. Even if Conditional Access and authentication methods block older MFA methods, removing them manually adds an extra security layer..

With regards to the requirement stated earlier: Below is how the security info screen should look like. This screen is available at aka.ms/mysecurityinfo

No TAP – No FIDO2

I went through Temporary Access Pass (TAP) in great detail in my last post, so I won’t go through it again here, but TAP is the go-to method for onboarding passwordless signin-methods like FIDO2 keys, and you also need to consider how to distribute the TAP to the end user. All of this was discussed in the previous post, but how can you enforce the use of TAP (or existing FIDO2 key) for MFA registration only? This is an example of how you can achieve that:

Step 1: Create 2 “Authentication strengths”

Located under “Protection” and “Conditional Access“.

• “TAP or FIDO2” for MFA registration which allows only TAP or FIDO2
• “FIDO2 only” for signing in to admin portals which allows only FIDO2 for Authentication.

Step 2: Create a Conditional Access policy which requires your “TAP only” Authentication Strength when registering your security information. Under “Target resources“, select “User actions” and “Register security information“.

Under “Grant“, select the “TAP or FIDO2” authentication strength as requirement.

This policy will block a user from setting up MFA unless they have logged in using a TAP or an existing FIDO2 key.

Step 3: Create a Conditional Access which requires your “FIDO2 only” Authentication Strength when signing in to an admin portal. Under “Target resources“, choose “Select resources” and “Microsoft Admin Portals“.

Under “Grant“, select the “FIDO2 only” authentication strength as requirement.

This policy will block signins to the admin portals unless you authenticate with a FIDO2 key.

AAGUID matters

Each FIDO2 security key has a unique Authenticator Attestation GUID (AAGUID), which allows administrators to enforce policies that allows or blocks authentication using specific vendors and models of FIDO2 keys. AAGUID matters because it allows you to control which trusted and verified FIDO2 keys are used in your environment. This is configured in the FIDO2 properties under “Authentication methods”, meaning that this is a tenant-wide settings and can’t be scoped to for example all privileged accounts.

OK, now we have enforced TAP and FIDO2, so the next logical step is to ensure that administrators work in a secure environment when they sign in, to protect them from spyware, phishing and other vulnerabilities – enter PAW!

PAW is where an admin belongs

Your admin accounts will always be a prime target for any intruders and it is vital that admins sign in from devices where the risk for vulnerabilities and malware are as low as possible. This is where Privileged Access Workstations (PAW) come in. The point of a PAW is to have a separate, dedicated computer to use when you need to sign in with a privileged account, so they don’t sign in to other general-purpose devices. This can drastically reduce the risk of phishing, spyware or other threats.

A PAW is a computer dedicated for this purpose and is not used for anything else, and the privileged account never signs in on any other device than the PAW. Using any other device can introduce vulnerabilities and should be avoided.

There are many ways to set up a PAW, and it doesn’t have to be a complex and massive setup. Remember that any and all security settings make a difference, and don’t let perfection be the enemy of progress.

If you are new to PAW, just keep it simple and use some basic security guidelines to help you get started:

• Use dedicated computers, perform OS hardening. Monitor and patch regularly.
• Local admin rights is a big no-no!!
• Install only the management tools you need from trusted sources.
• Isolate the PAW network from other networks, particularly from ordinary clients or guest networks.
• Use device filters in Conditional Access to make sure privileged accounts use the PAW to sign in, be careful not to lock yourself out though. (When was the last time you tested your break-glass account?)
• There are many options and steps for the hardening of the PAW: TPM, Bitlocker, Secure boot, System Guard etc etc. Microsoft has a few guides to help you get started. Link1, link2

Setting up a PAW probably warrants a blogpost on its own, but the bottom line is to limit signins with privileged accounts to dedicated clients, which is hardened and not used for any other purposes. The goal is to reduce the risk of vulnerabilities and malware where the privileged accounts logs in as much as possible.

In conclusion

Securing your Entra ID accounts with FIDO2 isn’t just about enabling the feature, it’s also about making sure it’s implemented correctly. Start with a clear strategy and goals, implement changes in batches and remember to remove older MFA methods. Also take really good look at where elevated can sign in from, and where they should sign in from. What can you do in your environment to limit the exposure of privileged accounts? If dedicated computers for admins are possible, DO IT! Even a simple PAW setup is far better than none. While a fully hardened PAW is ideal, just having a separate, restricted device for admin tasks significantly reduces risk and improves security.