Findings#
This page lists every finding Access Baseline v1.4.5 can report, grouped by area as on the page. For each one: what it checks, why it matters and what to do. Some findings only appear in certain cases; those cases are noted.
Statuses#
| Status | Meaning |
|---|---|
| In place | The check passes. |
| Partly in place | It's there, but not enforced or not complete. For a Conditional Access check, this usually means the only matching policy is in report-only. |
| Missing | Nothing does this. |
| To review | A person needs to judge it. |
| Couldn't read | Your role couldn't read this part of the tenant, so it isn't assessed. |
| Not applicable | It doesn't apply to your tenant (for example, no P2 licence). |
The score#
The score is the share of the baseline that's in place, weighted by severity:
| Severity | Weight |
|---|---|
| Critical | 10 |
| High | 5 |
| Medium | 3 |
| Low | 1 |
- In place counts in full.
- Partly in place counts as half.
- Missing counts as nothing.
- To review, couldn't read and not applicable are left out altogether, so they neither raise nor lower the score.
For example, one critical finding in place (10), one high finding partly in place (2.5 of 5) and one medium finding missing (0 of 3) score 12.5 out of 18, which is 69%. If nothing can be scored, the score shows as a dash.
How Conditional Access is matched#
For the checks with a catalogue reference (CA000 and so on), Access Baseline looks for a policy in your tenant that does the same job:
- a matching policy that's on makes it in place;
- a matching policy that's only in report-only makes it partly in place;
- no matching policy makes it missing.
Policies that are off are ignored. The references are from the baseline's policy catalogue, which follows Microsoft's persona-based Zero Trust numbering: CA0xx for everyone, CA1xx for admins, CA2xx for users, CA3xx for guests. CA901, for privileged accounts and admin roles, replaced CA100 in v1.3.0.
Licences#
| Finding | Reference | Severity |
|---|---|---|
| Microsoft Entra ID P1 | Critical | |
| Microsoft Entra ID P2 | Medium |
Microsoft Entra ID P1. Checks for a live subscription that includes P1, on its own or in a suite such as Microsoft 365 Business Premium, E3 or E5 (P2 includes it too). Why: Conditional Access, authentication strengths and dynamic groups need P1. Without it, only security defaults are available. What to do: add Entra ID P1 before deploying the baseline.
Microsoft Entra ID P2. Checks for a live subscription that includes P2. Without it, this shows as not applicable rather than missing, and the risk checks (CA204, CA205) are left out. Why: P2 adds risk-based policies (risky sign-ins and users) and Privileged Identity Management for just-in-time admin roles. What to do: optional. Consider P2 (in Microsoft 365 E5) for admins at least, so their roles can be just in time.
Break-glass access#
Access Baseline works out which accounts and groups are your break-glass ones from your policies: any user or group left out of at least half of the policies that are on or in report-only. The accounts are those users plus the members of those groups.
| Finding | Reference | Severity |
|---|---|---|
| Break-glass group left out of every policy | Critical | |
| Break-glass group can only be changed by Privileged Role Administrators | High | |
| At least two break-glass accounts | High | |
| Break-glass accounts have a FIDO2 key | High |
Break-glass group left out of every policy. In place if a user or group is left out of every policy that's on or in report-only; partly in place if one is left out of most, and the page names the policies it isn't left out of; missing if nothing is left out of even half. If there are no policies yet, it's to review. Why: break-glass accounts are how you get back in when a policy, an outage or a lost phone locks every admin out. They must be left out of every Conditional Access policy. What to do: add the break-glass group to every policy's exclusions.
Break-glass group can only be changed by Privileged Role Administrators. Shown when a break-glass group is found. Checks the group is role-assignable. Why: anyone who can change the group's members can add themselves and slip past every policy. A role-assignable group can only be changed by Privileged Role Administrators; otherwise Groups Administrators, User Administrators and the group's owners can change it. What to do: a group can't be made role-assignable after it's created, so create a new role-assignable break-glass group and use it instead.
At least two break-glass accounts. Counts the break-glass accounts found. Needs the sign-in methods report.
Why: one account is a single point of failure: if its key is lost or it's locked, there's no way back in.
What to do: have at least two, cloud-only on the onmicrosoft.com domain.
Break-glass accounts have a FIDO2 key. Checks every break-glass account has a phishing-resistant method registered (a passkey, FIDO2 security key or Windows Hello for Business), and names any that don't. Needs the sign-in methods report. Why: Microsoft requires MFA to sign in to the admin portals, so a break-glass account with only a password can't do its job. A FIDO2 security key, kept somewhere safe, can. What to do: register a FIDO2 security key on each break-glass account.
Conditional Access#
| Finding | Reference | Severity |
|---|---|---|
| Security defaults are on | Medium | |
| Legacy authentication is blocked | CA000 | Critical |
| Device code flow is blocked | CA001 | High |
| Registering security info is protected | CA002 | High |
| Everyone must use MFA | CA200 | Critical |
| Admins must use phishing-resistant MFA | CA901 | Critical |
| Azure management needs MFA | CA103 | High |
| Guests must use MFA | CA300 | Medium |
| Risky sign-ins need MFA (P2 only) | CA204 | High |
| High-risk users are challenged (P2 only) | CA205 | High |
| Policies that apply to nothing | Medium | |
| Policies in report-only | Low |
Security defaults are on. Shown only when security defaults are on, as to review. Why: security defaults give everyone basic MFA, which is far better than nothing. They can't be tuned, and they must be off before Conditional Access policies can be used. What to do: turn security defaults off only once Conditional Access policies that replace them are on for everyone.
CA000 Legacy authentication is blocked. Looks for a policy for all users and all apps that blocks the Exchange ActiveSync and other clients client app types. Why: old protocols such as POP, IMAP and SMTP basic authentication can't do MFA, so password spraying goes straight past every other policy. What to do: block legacy authentication for everyone.
CA001 Device code flow is blocked. Looks for a policy for all users that blocks the device code flow authentication flow. Why: device code phishing tricks people into signing in a device the attacker controls, and it's one of the most common ways tokens are stolen today. What to do: block device code flow and authentication transfer, with an exclusion group for meeting rooms and kiosks.
CA002 Registering security info is protected. Looks for a policy for all users on the Register security information user action that requires MFA (or an authentication strength) or blocks. Why: without this, an attacker with someone's password can register their own phone or passkey and keep access for good. What to do: require MFA, a Temporary Access Pass or a trusted location to register sign-in methods.
CA200 Everyone must use MFA. Looks for a policy for all users and all apps that requires MFA or an authentication strength. If security defaults are on, the page notes that they already ask for MFA. Why: a password alone is the easiest way in: phished, guessed or reused from another breach. What to do: require MFA for everyone, without SMS or voice, starting with a pilot group.
CA901 Admins must use phishing-resistant MFA. Looks for a policy that targets at least the Global Administrator, Privileged Role Administrator and Conditional Access Administrator roles and requires a phishing-resistant method: the built-in Phishing-resistant MFA strength, or a custom strength that only allows FIDO2, Windows Hello for Business or certificate-based MFA. From v1.4.3, a custom strength of passkeys plus a one-time Temporary Access Pass (like the baseline's admin strength) also counts, but not a Temporary Access Pass on its own. Partly in place if such a policy is only in report-only, or if a policy targets those roles but doesn't require a phishing-resistant method. Up to v1.2.1 this check was CA100; it looks for the same thing, so a policy that covered CA100 covers CA901. Why: an admin's session is the most valuable thing to steal. Ordinary MFA can be phished in real time; passkeys and security keys can't. What to do: require attested, device-bound passkeys (security keys, Microsoft Authenticator), with a one-time Temporary Access Pass to set one up, for every admin role, by role rather than by account name, and for your privileged accounts group. Deploying the baseline creates CA901 to do this. Make sure every admin has a device-bound passkey first (see Every admin has a device-bound passkey or security key and No admin relies on a synced passkey, below).
CA103 Azure management needs MFA. Looks for a policy for all users that requires MFA and covers the Windows Azure Service Management API (or all apps). Why: Azure portal, CLI and PowerShell access reaches every resource in the subscription. What to do: require a phishing-resistant method for Azure management.
CA300 Guests must use MFA. Looks for a policy on all apps that requires MFA and includes guests and external users, or all users without leaving guests out. Why: guests sign in to your data with accounts you don't control. What to do: require MFA for guests and external users.
CA204 Risky sign-ins need MFA. Only checked with Entra ID P2. Looks for a policy for all users that requires MFA or blocks when sign-in risk is high. Why: Identity Protection spots sign-ins that look like an attacker (unfamiliar places, leaked passwords, anonymous networks). What to do: ask for MFA, every time, on medium and high risk sign-ins.
CA205 High-risk users are challenged. Only checked with Entra ID P2. Looks for a policy for all users that requires MFA, blocks or requires a password change when user risk is high. Why: a high user risk means the account is probably compromised. What to do: require phishing-resistant MFA, every time, for high-risk users. That works for passwordless users, unlike require password change.
Policies that apply to nothing. Shown when a policy that's on or in report-only targets no users or no apps, as to review. The page names each one. Why: a policy with no users or no apps never runs, so the protection it was meant to give isn't there. What to do: fix the targeting or delete the policy.
Policies in report-only. Shown when any policy is in report-only, as to review, with their names. Why: report-only is the right way to start, but a policy left there protects nobody. What to do: check each one's report-only results in the sign-in logs, then turn it on.
Authentication methods#
Needs Global Reader: Security Reader can't read the authentication methods policy.
| Finding | Reference | Severity |
|---|---|---|
| Passkeys are allowed | High | |
| People can set up their own passkey | Medium | |
| Microsoft Authenticator is allowed | Medium | |
| Temporary Access Pass is available | Medium | |
| Text and voice codes are off | Medium | |
| Registration campaign nudges people to stronger methods | Low | |
| System-preferred MFA is on | Low |
Passkeys are allowed. Checks the passkey (FIDO2) method is on. Why: passkeys (in Microsoft Authenticator, on a security key or synced by Apple or Google) can't be phished, and they're quicker than a password. What to do: turn passkeys on: device-bound for admins and break-glass, synced allowed for users.
People can set up their own passkey. Shown only when passkeys are on but self-service setup is off, as to review. Why: with self-service setup off, nobody can register a passkey themselves, and Microsoft's API for registering a security key on someone's behalf doesn't work either. What to do: turn self-service setup on in the passkey (FIDO2) settings.
Microsoft Authenticator is allowed. Checks the Authenticator method is on. Why: Authenticator is the stepping stone for people who can't use a passkey yet, and it can hold a device-bound passkey itself. What to do: turn Authenticator on, with app and location context shown.
Temporary Access Pass is available. Checks the Temporary Access Pass method is on. Why: a Temporary Access Pass lets someone sign in for the first time, or after losing their phone, and set up a passkey without ever using a password. What to do: turn it on: one-time use, one hour.
Text and voice codes are off. Missing if SMS or voice call is on. Why: text and call codes can be intercepted by SIM swapping and phished in real time. They're the weakest kind of MFA. What to do: turn them off for a pilot group first, then for everyone, once people have moved to Authenticator or a passkey (see Nobody relies on text or voice codes alone, below).
Registration campaign nudges people to stronger methods. Shown when Microsoft Graph returns the campaign's state. In place if it's enabled, otherwise to review. Why: the campaign prompts people who still use text codes to set up Authenticator at sign-in. What to do: turn it on, with a limited number of skips.
System-preferred MFA is on. Shown when Microsoft Graph returns its state. In place if it's enabled, otherwise to review. Why: it makes sign-in offer the strongest method someone has registered, rather than the one they chose first. What to do: turn it on.
How people sign in#
Uses the sign-in methods report, for members only (guests aren't counted). Each person is placed by the strongest method they've registered, the same way Auth-Onboard does it, so the two tools agree:
| Group | Methods |
|---|---|
| Phishing-resistant | A passkey (synced or device-bound), FIDO2 security key, Windows Hello for Business or macOS secure enclave key |
| Authenticator passwordless | Microsoft Authenticator phone sign-in |
| Authenticator or hardware codes | Authenticator push, or a hardware one-time passcode token |
| Other code app | A code app other than Authenticator |
| Text or voice only | Mobile, alternative mobile or office phone |
| Nothing | No MFA method registered |
| Finding | Reference | Severity |
|---|---|---|
| Everyone has registered MFA | High | |
| Nobody relies on text or voice codes alone | Medium | |
| Passkey adoption | Low |
Everyone has registered MFA. Missing if any member has no MFA method, with the number and percentage. Why: an account with no MFA registered can be taken over with its password, and the attacker can then register their own phone. What to do: protect security info registration (CA002) first, then run an enrolment campaign, for example with Auth-Onboard.
Nobody relies on text or voice codes alone. Missing if any member only has text or voice codes. It also notes how many use a code app other than Authenticator, which an authentication strength without one-time codes won't accept. Why: these people will be locked out when text and voice codes are turned off, so they need moving first. What to do: move them to Authenticator or a passkey before SMS and voice are turned off. Auth-Onboard's campaigns do this.
Passkey adoption. Always to review: it reports how many members have a passkey or security key, and the count in each group above. Why: passkey-only sign-in can only be turned on for people who have a passkey. What to do: move people to passkey-only sign-in only once they have one.
Admin accounts#
| Finding | Reference | Severity |
|---|---|---|
| Every admin has a device-bound passkey or security key | Critical | |
| No admin relies on a synced passkey | High | |
| Fewer than five Global Administrators | Medium |
Every admin has a device-bound passkey or security key. Updated in v1.4.3. Uses the sign-in methods report's admin flag. Missing if any admin has no device-bound passkey or security key; the page names them, and says how many of them only have Windows Hello for Business, which CA901 doesn't accept. Why: CA901 will require a device-bound passkey (a security key or Microsoft Authenticator) for every admin, with a one-time Temporary Access Pass to set one up. Admins without one would be locked out when it's turned on. Windows Hello for Business and certificates don't count. What to do: give each admin a device-bound passkey before CA901 is turned on: in Microsoft Authenticator or on a security key. AKC Key Enrol, for registering a key on someone's behalf, is planned for a later phase.
No admin relies on a synced passkey. New in v1.3.0. Uses the sign-in methods report's admin flag. Missing if any admin's only phishing-resistant method is a synced passkey (one with no device-bound passkey, security key or Windows Hello beside it); the page names them. Admins with no phishing-resistant method at all are covered by the finding above, not this one. Why: a synced passkey lives in a personal Apple, Google or password manager account, which you can't see or control. Microsoft recommends device-bound passkeys for admins. CA901 won't accept a synced passkey. What to do: add a device-bound passkey for each: Microsoft Authenticator or a FIDO2 security key. The baseline's Passkey-Privileged profile then allows device-bound passkeys only.
Fewer than five Global Administrators. Counts who holds Global Administrator right now, and names them. Missing with five or more; to review with fewer than two; otherwise in place. Why: every Global Administrator can do anything in the tenant. Microsoft recommends fewer than five, with day-to-day work done in smaller roles. What to do: with five or more, move day-to-day admins to the smallest role their work needs, and keep Global Administrator for the break-glass accounts and one or two others, ideally just in time with PIM. With fewer than two, keep at least two, so one lost account can't lock you out; the break-glass accounts count.
Areas that couldn't be read#
If your role can't read an area, it shows one finding with the status couldn't read and severity low, giving the reason (for example, Access denied. This needs Global Reader.). It's left out of the score. See Troubleshooting.