Why do assessors dislike "Groups" in Conditional Access Policies within Microsoft 365?
So, here you are, about to complete your Cyber Essentials/Baseline Verified Assessment. The assessor gets you to log in to your Microsoft Office 365 tenant as an administrator and asks you to prove that 100% of all sign-in-enabled entities are protected with enforced MFA. You utilise groups for this, and your assessor is NOT HAPPY! - but why?
What's wrong with groups?
The first issue with groups is that, generally, unless you are using Dynamic Group Memberships, it requires a human to pop someone into a group, and humans make mistakes, get distracted, and have other challenges on their time.
When assessing Group Membership for MFA enforcement versus EntraID Sign-In-Enabled entity numbers, we absolutely never find a match; there are always some identities that are not (in theory) covered by MFA, and it is up to you to prove to your assessor that you are covered!
The most common comment from someone in tech is, "Well, we add everyone" (and when we find that is not the case, "We missed that one"). So why is it not better to say "All Users" in the policy in the first place if you enforce it for all anyway?
Are we saying you don't have MFA on 100% of accounts?
No, absolutely not, but can you be sure? We cannot. Therefore, how can you demonstrate this?
Break-Glass Account?
OK, notwithstanding the above (and that, to be clear, is to use all users), the next issue we see as assessors is "we need a break-glass account"!
Yes, you do; you should ALWAYS have an account not included within the Conditional Access Policy (CA) to ensure that if you "mess it up", that account can still get in, BUT IT SHOULD BE MFA PROTECTED!
This, therefore, is an exclusion, not a reason to use Groups!
So, what should we do?
Ensure that all sign-in-enabled entities (that includes everything, so guests and externals) have MFA enforced by having ALL USERS enabled within your MFA policy (you need one policy for this—see separate options for Teams Rooms/Services/Copiers, etc.). Yes, do exclude the one "Break-Glass Account".
Don't use anything that requires "Human Intervention"; thus, remove the "Human Error"!
What is the perfect "Assessor Based" solution for MFA enforcement?
That is an excellent question, and if you read the above, you probably already know the answer. We have written a great article about how to sort this in MS365 - you can enable 2FA, Security Defaults, and Conditional Access can find that here; however, in brief:
- If not using Conditional Access (CA) enabled Security Defaults.
- Have an "All Users" conditional access policy, excluding an "MFA Protected Break Glass Account", which enforces MFA for everyone (no groups).
- Have, if you require, excluded accounts in 2, above, for copiers and service accounts, where you then have an additional policy that prevents sign-in (Block Access) from all IP addresses, except for wherever that device/service is located (named locations), using the IP as the secondary factor.
Using these two policies, you can demonstrate to your assessor that you have 99.99% sign-in-enabled accounts with MFA enforcement, except the break-glass account(s). Then, showing that the account has MFA enabled, you can make that 100% within a few minutes of the assessment, making us, your assessors, very happy.
Break-Glass Accounts
This is probably a wrong choice of name here, but these accounts are merely those not included within any conditional access policy, still protected with MFA, but not subject to policies; thus, if you mess up a Geo-Location Policy or Block-Access Policy, you have an account that can log in, and recovery is possible.
Our KB about 2FA/MFA is where to go to help you here!