Troubleshooting#

An area shows "couldn't read"#

Each area is read on its own. If your role can't read one, that area shows a single couldn't read finding with the reason, and the rest of the assessment carries on. Areas that couldn't be read don't count towards the score.

Area on the page	What it reads	Roles that can read it
Licences	Your subscriptions	Global Reader or Directory Readers
Conditional Access and Break-glass access	Conditional Access policies, security defaults and authentication strengths	Global Reader or Security Reader
Authentication methods	The authentication methods policy	Global Reader. Security Reader can't read it.
How people sign in, the admin check, and the break-glass account and key checks	The sign-in methods report	Global Reader, Security Reader or Reports Reader
Admin accounts: Global Administrators	Who holds Global Administrator	Global Reader or Directory Readers

The simplest fix is to use Global Reader, which reads all of them. Then choose Check again.

Break-glass access is worked out from your Conditional Access policies, so if they can't be read, break-glass can't be assessed either.

"Global Reader is missing", but I have it#

The page checks your active roles. If you hold Global Reader through Privileged Identity Management, activate it, wait a minute, then choose Check again.

"Need admin approval" when connecting#

The app hasn't been consented to in your tenant yet. Ask someone who can grant admin consent (Cloud Application Administrator is enough) to open deploy.andykemp.com/baseline, connect, and approve the three read-only permissions for AKC Baseline Deployer. After that, you can connect with Global Reader.

If you deleted the app after an earlier assessment, consent is asked for again.

In v1.0.0 this message could appear when connecting even though the sign-in had just worked. v1.0.1 fixes it. If you still see it, reload the page (Ctrl+F5, or Cmd+Shift+R on a Mac) to make sure you have v1.0.1; the number is at the top of the page.

If your sign-in has genuinely expired, for example after leaving the tab open a long time, choose Sign in again.

I can't see the assessment#

Your organisation needs to be approved for Access Baseline. The page shows where your request is: if it's requested, it's waiting for approval; if it's declined or paused, talk to Andy.

Break-glass accounts aren't found#

Access Baseline treats as break-glass any user or group left out of at least half of the Conditional Access policies that are on or in report-only. If your break-glass accounts aren't left out of most policies, they won't be recognised, and that is itself the finding: they should be left out of every policy.

The Conditional Access checks say "missing", but I have a policy for that#

A policy only counts if it matches the check closely. For example, CA200 looks for all users and all apps; a policy for one group or one app doesn't count. Policies that are off are ignored, and a policy in report-only counts as partly in place. The exact match for each check is on Findings.

Deploying the baseline#

"You need … active" on the Review screen#

A role the deploy needs isn't active for you. The message names it:

Conditional Access Administrator (or Security Administrator): always needed, to create the strengths and the policies.
Groups Administrator (or User Administrator): needed when the tool creates a group or adds privileged accounts.
Privileged Role Administrator: needed for a new break-glass group, a new privileged accounts group, the exclusion groups, or adding accounts to the privileged group.
Authentication Policy Administrator: needed when the passkey profile is ticked.

If you hold the role through PIM, activate it, then choose Check again. If you can't get Privileged Role Administrator, ask someone who has it to create the role-assignable groups and add the privileged accounts, then choose Use an existing group and leave the account list empty. If you can't get Authentication Policy Administrator, untick the passkey profile, or ask someone who has it to deploy again later. See Who can run it.

"Security defaults are on"#

This is a warning, not a blocker. The policies are created report-only, which works alongside security defaults. Before you turn any policy on, turn security defaults off (Entra admin center, Overview > Properties > Manage security defaults). Don't turn them off until your Conditional Access policies are ready to take over.

The break-glass group "isn't role-assignable"#

Your existing break-glass group was created without Microsoft Entra roles can be assigned to the group. That means Groups Administrators, User Administrators and the group's owners can change who's in it, and so slip past every policy. You can still deploy, but a group can't be made role-assignable afterwards, so the better fix is a new group:

Go back to Change the design and choose Create a new group for break-glass (this needs Privileged Role Administrator), or create a role-assignable group yourself and pick it.
Move the break-glass accounts into it.

"A group called … already exists and isn't role-assignable"#

You asked for a new break-glass or privileged accounts group, but a group with that name is already there and isn't role-assignable, so the tool can't use it as one. Either choose that group with Use an existing group (and accept the warning above), or give the new group a different name.

A group or policy name already exists#

Access Baseline finds everything by name before it creates anything. If a pilot group, exclusion group, privileged accounts group or authentication strength with the same name is already there, it's kept and left exactly as it is, and Review marks it (exists: kept). Its settings aren't changed.

Policies are different from v1.4.0: an existing baseline policy is compared with the baseline, and you can choose to update it. See the next three sections.

If an existing group or strength isn't what you want, rename it in the design, or rename or delete the existing item in the Entra admin center, then choose Check again.

A policy was renamed, and I don't want a second copy#

You don't get one. Each baseline policy is found by its exact name, or else by the reference at the start of the name, so CA200 - Require MFA for all users is still found as CA200. Review shows it under its current name, with Name: … under Kept as yours: the name is never changed.

It's only found while the reference stays at the start of the name. If someone moved or removed the reference, or two policies start with the same reference, the tool can't tell which is the baseline's, and Review shows the policy as New. Put the reference back at the start of the right policy's name in the Entra admin center (or rename the other one), then choose Check again.

"Exists: differs in … ways, left as it is"#

The policy is there, but some of the settings the baseline owns are different: the table shows each one, as it is in your tenant and as the baseline would have it. That's only a report. Nothing changes unless you tick Update to the baseline for that policy.

Leave it unticked if the difference is deliberate. Tick it to bring those settings back to the baseline. A policy missing the break-glass exclusion is ticked for you, because without it a mistake in that policy could lock everyone out: untick it only if you've a good reason, and add the exclusion yourself before turning anything on.

An update only changed part of the policy#

That's by design. Update to the baseline changes only the settings the baseline owns: the apps, client apps, authentication flows, risk levels, the grant or authentication strength, sign-in frequency on CA204 and CA205, CA901's admin roles (missing ones added, none removed) and the break-glass exclusion.

It never changes the policy's state, who it targets, its name, your extra exclusions, terms of use or other controls, so a policy you turned on, or widened from the pilot to all users, stays that way. Those are listed under Kept as yours on Review. If you want to change one of them, do it in the Entra admin center. See What "Update to the baseline" changes.

"Passkey profiles aren't turned on in this tenant"#

Your tenant's passkey (FIDO2) policy doesn't use passkey profiles yet. Turning them on can't be undone, so Access Baseline leaves that to you. This is a warning, not a blocker: the deploy runs, and only the passkey profile is skipped (the Done screen lists it as skipped). Without the profile, only CA901's authenticator list keeps synced passkeys out of admin sign-in. If the list is off too, Review also warns that nothing keeps synced passkeys away from privileged accounts yet: turn on passkey profiles and deploy again, or turn on the list.

To add the profile, turn passkey profiles on in the Entra admin center (Authentication methods > Passkey (FIDO2)), then deploy again. Everything already created is found by name and kept, so only the profile is added. See When passkey profiles aren't turned on.

"The privileged group is in the passkey policy's exclude list"#

The privileged accounts group is excluded in the passkey (FIDO2) policy, which blocks passkeys for everyone in it, so a profile for it would never apply. Review stops here. Either remove the group from the passkey policy's exclude list in the Entra admin center (Authentication methods > Passkey (FIDO2)), then choose Check again, or untick the passkey profile in the design.

If the group is added to the exclude list after Review, the passkey step stops with the same message. Remove it there, then choose Run again.

Review says another passkey profile allows synced passkeys#

The warning starts "Another passkey profile that allows synced passkeys is targeted at all users", or, for other groups, says how many other targets allow synced passkeys. It's a warning: the Passkey-Privileged profile is still added.

Attestation in Passkey-Privileged only applies when a passkey is registered, and Conditional Access doesn't check it at sign-in. When someone is in more than one passkey target, the most permissive profile wins. So while a broader profile that allows synced passkeys (typically Default, for all users) also covers your admins, they could still register a synced passkey through it, and with CA901's authenticator list off, it would satisfy CA901.

Fix it in one of two ways:

Make that profile device-bound with attestation. In the Entra admin center, go to Authentication methods > Passkey (FIDO2), open the profile, allow device-bound passkeys only and require attestation. Check first that the people it covers don't rely on synced passkeys. If the broader target is a group rather than all users, you can instead keep privileged accounts out of that group.
Turn on CA901's authenticator list. Go back to the design's Policies step, tick Also limit CA901 to listed authenticators, and add your security keys' AAGUIDs to Microsoft Authenticator's. A synced passkey then can't satisfy CA901, whatever the profiles allow. See Limiting passkeys by AAGUID.

Then choose Check again. With the list on, the warning stays, but says the list keeps synced passkeys out. See Most permissive wins.

"Nothing keeps synced passkeys away from privileged accounts"#

CA901's authenticator list is off, and either the passkey profile is unticked or passkey profiles aren't turned on in your tenant. Then neither attestation nor the list stops a privileged account using a synced passkey. Tick the passkey profile (turning on passkey profiles in your tenant first if Review says they're off, then deploying again), or turn on CA901's authenticator list.

"Also limit CA901 to listed authenticators" can't be ticked#

You chose Also allow synced passkeys (Apple, Google): not recommended for privileged accounts. Synced passkeys have no authenticator model to list, so they could never pass CA901's list, and the two can't be used together. To use the list, choose Device-bound only, attestation required (recommended). See The passkey profile.

An admin's security key isn't in the AAGUID list#

With Also limit CA901 to listed authenticators on, CA901 only accepts passkeys from the models you listed. An admin whose security key model isn't listed would be blocked once CA901 is turned on. In report-only, their sign-ins show that CA901 would have failed.

Find the key's AAGUID (open the user in the Entra admin center, choose Authentication methods, and look at the passkey's details, or ask the key's maker), then:

Before you deploy: add it to the list in the design's Policies step.
After you deploy: an existing admin strength is kept as it is, so deploying again won't change its list. Add the AAGUID to AKC Baseline - Admin keys in the Entra admin center: Authentication methods > Authentication strengths, open the strength, and edit the passkey's advanced options.

An admin only uses a smart card or Windows Hello for Business#

From v1.4.3, CA901's admin strength accepts only attested, device-bound passkeys and a one-time Temporary Access Pass. Certificate-based authentication (smart cards) and Windows Hello for Business don't count, so an admin who signs in only with one of those would be blocked once CA901 is turned on. In report-only, their sign-ins show that CA901 would have failed, and the assessment's Every admin has a device-bound passkey or security key finding names them.

Give each of them a passkey in Microsoft Authenticator or on a FIDO2 security key before you turn CA901 on, using a Temporary Access Pass to register it (next section). They can keep their smart card or Windows Hello for their everyday account. See The admin strength for why.

Issuing a Temporary Access Pass for an admin#

A one-time Temporary Access Pass lets an admin sign in once and register their first passkey, and CA901 accepts it for that. For an admin account, only a Privileged Authentication Administrator can issue one; an Authentication Administrator can't. The Temporary Access Pass method has to be turned on in your tenant (Authentication methods > Temporary Access Pass), and the assessment's Temporary Access Pass is available finding shows whether it is.

In the Entra admin center, open the admin's account, choose Authentication methods > Add authentication method > Temporary Access Pass, make it one-time, and give it the shortest lifetime that works. Hand it over in person or over a channel you trust.

"A chosen account is also in the break-glass group"#

You chose an account for the privileged group that's also in the break-glass group. Break-glass is left out of every policy, so CA901 won't apply to it. Break-glass accounts don't belong in the privileged group: go back to Change the design and remove it from the list.

"Conditional Access needs Microsoft Entra ID P1"#

No licence with Entra ID P1 was found (it's in Microsoft 365 Business Premium, E3 and E5). Conditional Access can't be created without it, so the deploy won't go ahead.

Deploy stopped part-way#

Fix the cause the message gives (for example, a PIM role that has expired), then choose Run again. Each step finds what's already there first, so it only adds what's missing.

"Couldn't record this step with AKC"#

Your tenant isn't affected: the step worked. Only AKC's record of which steps ran couldn't be saved.