Deploy the baseline#

Updated in v1.4.5

Access Baseline can create the core Conditional Access policies in your tenant, with the groups and authentication strengths they use. From v1.3.0 it also protects your privileged accounts: they get their own group, a policy that only accepts device-bound phishing-resistant sign-in (CA901), and a passkey profile that only allows device-bound passkeys, with attestation required. You design it in four short steps, check every value on a review screen, type DEPLOY, and it's created.

From v1.4.0 you can run it again at any time. Review compares each baseline policy already in your tenant with the baseline, setting by setting, and you choose which ones to bring back to the baseline. See Running it again: compare and update.

Every policy is created report-only. A report-only policy records what it would have done, and changes nobody's sign-in until you turn it on. Anything that already exists is left as it is, unless you tick Update to the baseline for that policy on Review. The one change that isn't report-only is the passkey profile, and Review and the confirmation both say so.

Open deploy.andykemp.com/baseline, connect your tenant (see Run the assessment), then choose 2. Deploy the baseline at the top, or Deploy the baseline under What happens next at the end of the assessment.

Assess first

Run the assessment before you deploy. It shows which of these policies you already have, whether your break-glass accounts are in place, which admins don't yet have a passkey or security key, and which admins rely on a synced passkey.

Who can run it#

You don't need Global Administrator. The Review screen checks your active roles, and stops with a clear message if one is missing. If you hold Global Administrator, it works, and the page names the smaller roles you could use instead.

Role	When it's needed	Why
Conditional Access Administrator (or Security Administrator)	Always	Creates the authentication strengths and the Conditional Access policies.
Groups Administrator (or User Administrator)	When the tool creates any group (pilot, exclusion, break-glass or privileged accounts) or adds accounts to the privileged group	Creates the security groups.
Privileged Role Administrator	For a new break-glass group, a new privileged accounts group, the exclusion groups, or when you choose accounts to add to the privileged group	These groups are created role-assignable, so only this role can change who is in them. Creating one, or adding members, needs the same role.
Authentication Policy Administrator	When the passkey profile is ticked (it is by default)	Adds the device-bound passkey profile for privileged accounts to the passkey policy.

With the defaults (a new privileged accounts group and the passkey profile), you need all four. The Review screen also reads your existing policies, groups and licences. Global Reader or Security Reader covers that, as for the assessment.

If you hold these roles through Privileged Identity Management (PIM), activate them before you choose Check again on the Review screen. Activate each one just for this job.

The design steps#

Your choices are remembered in this browser tab while you work, so going back and forth between the steps and Review doesn't lose them.

1. Break-glass#

Break-glass (emergency access) accounts are how you get back in if a policy, an outage or a lost phone locks every admin out. A break-glass group is required: you can't go on without one.

Use an existing group: type to search your security groups and pick it.
Create a new group: CA-BreakGlass by default. A new group is role-assignable with no owner, so only Privileged Role Administrators can change who is in it. Creating one needs that role.

The group is left out of every policy the tool creates, CA901 included. That can't be changed.

Before you turn any policy on, the group needs at least two cloud-only accounts on your onmicrosoft.com domain, with no licence and no mailbox, each with a FIDO2 security key kept somewhere safe. This release doesn't create the accounts: create them in the Entra admin center and add them to the group.

2. Privileged accounts#

New in v1.3.0. Your admin accounts go in this group. They get CA901 (device-bound phishing-resistant MFA) and the device-bound passkey profile.

Create a new group: CA-Privileged-Accounts by default. Like the break-glass group, it's role-assignable with no owner, so only Privileged Role Administrators can change who is in it. Creating one needs that role.
Use an existing group: pick it from the search. If it isn't role-assignable, Review warns you.

It must be a different group from the break-glass group (break-glass is left out of every policy; privileged accounts are not) and from the pilot group.

Then choose the accounts to add:

Holding an admin role now lists the accounts that hold one of the 14 admin roles at the moment, with the roles each holds. If you chose an existing break-glass group, its accounts are labelled break-glass account: leave it out. Tick the ones you want, or choose Choose all except break-glass (Choose all of them when the break-glass group is new or empty) to tick everyone else. Roles that are only eligible through PIM show once they're activated.
Add another account searches your users, for admin accounts that don't hold one of those roles right now.
The chosen accounts are listed with a Remove link.

Accounts are only ever added to the group. Anyone already in an existing group stays; nothing is removed. You can also leave the list empty: CA901 still covers the 14 admin roles, and Review reminds you to add separate admin accounts to the group later.

Use separate admin accounts for admin work where you can, not people's everyday accounts. Break-glass accounts don't belong here: they're left out of every policy, and Review warns you if a chosen account is also in the break-glass group.

3. Pilot group#

Policies for your users start on this group only, so you can try them on a few people (IT, say) before everyone. You widen them later, one at a time.

Create a new group: CA-Pilot-Ring0 by default. An assigned security group, with you as owner. Add people to it after Deploy.
Use an existing group: pick it from the search.

The pilot group must be a different group from the break-glass group.

Exceptions (ticked by default, recommended): a group of exceptions for each policy, named CA-Exclude-CA001 and so on. An exception becomes a group membership you can see and review, never an edit to the policy. The groups are role-assignable, so creating them needs Privileged Role Administrator. See Exclusion groups.

4. Policies#

Each policy in the catalogue, with what it does, why it matters and who it applies to. Tick or untick the ones you want. The two locked policies, CA000 and CA901, are marked Always included, and the two risk policies Needs P2. P2 policies are left out automatically if your tenant doesn't have Entra ID P2.

For CA001 there's one extra choice: Also block authentication transfer (ticked by default). See CA001 below.

Below the policies:

Authentication strength: the name of the strength the user policies use. The default is AKC Baseline - No SMS or voice. See The authentication strengths.
Admin strength (CA901): the name of the strength CA901 uses. The default is AKC Baseline - Admin keys. It must be different from the user strength's name. Beside it, a note explains why privileged accounts only use passkeys and a Temporary Access Pass. See The admin strength.
Also limit CA901 to listed authenticators (off by default), with the list of AAGUIDs, one per line, when it's ticked. Attestation in the passkey profile already does the main job, so you only need this as well if another passkey profile that allows synced passkeys also covers your admins; Review tells you. See Limiting passkeys by AAGUID.
Passkey profile: add the Passkey-Privileged passkey profile for the privileged group (ticked by default, recommended), and choose which passkeys privileged accounts may use: Device-bound only, attestation required (recommended), the default, or Also allow synced passkeys (Apple, Google): not recommended. See The passkey profile.

Strength names are between 3 and 30 characters, the most Microsoft allows.

The locked choices#

A few things can't be changed, whatever you choose:

Locked	Why
A break-glass group is required	Without it, a mistake in a policy can lock everyone out.
The break-glass group is left out of every policy the tool creates	That's what break-glass is for.
Every policy is created report-only	You see what it would do before it does it.
CA000 (block legacy authentication) is always included	Without it, password spraying goes straight past every other policy.
CA901 (privileged accounts need device-bound phishing-resistant MFA) is always included	Admin accounts are the most valuable thing to steal.

Policies for your users start on the pilot group. CA901 applies to the privileged accounts group and the admin roles, and the guest policies to guests. All of them are report-only like the rest.

The policies#

Each policy is named <reference> - <name>, for example CA000 - Block legacy authentication, so you can find it in the Entra admin center and so a later run can find it too.

Ref	Name	Applies to	What it does	Why
CA000	Block legacy authentication	Pilot group	Blocks POP, IMAP, SMTP, Exchange ActiveSync and other old protocols that can't do MFA. Always included.	Password spraying goes straight past every other policy through them.
CA001	Block device code flow and authentication transfer	Pilot group	Blocks the device code sign-in and, if ticked, passing a sign-in from one device to another (a PC to a phone with a QR code). Leaves out the Device Registration Service, so devices can still register.	Device code phishing is one of the commonest ways tokens are stolen today.
CA002	Protect security info registration	Pilot group	Registering a phone or passkey needs MFA without text or voice codes, or a one-time Temporary Access Pass (the user strength).	Otherwise someone with a stolen password can register their own method and keep access.
CA103	Azure management needs strong MFA	Pilot group	The Azure portal, CLI and PowerShell (Windows Azure Service Management API) need the user strength: no text or voice codes.	Azure management reaches every resource in your subscriptions.
CA200	Everyone needs MFA, without text or voice codes	Pilot group	Every sign-in, to every app, needs the user strength: a passkey, Windows Hello, Authenticator, a code app or a hardware token. Text and voice codes don't count.	A password alone is the easiest way in, and text codes can be intercepted.
CA204	Risky sign-ins need MFA every time	Pilot group	Medium and high risk sign-ins need the user strength, every time (sign-in frequency: every time). Needs P2.	Identity Protection spots sign-ins that look like an attacker.
CA205	High-risk users need phishing-resistant MFA	Pilot group	Users at high risk need phishing-resistant MFA, every time. Works for passwordless users, unlike require password change. Needs P2.	A high user risk means the account is probably compromised.
CA300	Guests need MFA	All guests and external users	Guests and external users must do MFA to reach your apps.	Guests sign in to your data with accounts you don't control.
CA301	Guests can't reach admin portals	All guests and external users	Blocks guests and external users from the Microsoft admin portals.	No guest should be administering your tenant.
CA901	Privileged accounts need device-bound phishing-resistant MFA	Privileged accounts group and the 14 admin roles	They must sign in, to every app, with a device-bound passkey (a security key or Microsoft Authenticator), or a one-time Temporary Access Pass to set one up: the admin strength. Synced passkeys, Windows Hello for Business and certificates don't count. Always included.	An admin session is the most valuable thing to steal. Ordinary MFA can be phished in real time, and a synced passkey is only as safe as the personal Apple or Google account it syncs through.

All are in the plan by default (CA204 and CA205 only with P2). Every policy leaves out the break-glass group and, if you chose exclusion groups, its own exclusion group.

"Everyone needs MFA" means everyone in the pilot group for now. Widening the user policies beyond the pilot isn't in this release.

CA901 replaces CA100

Up to v1.2.1 the admin policy was CA100 - Admins need phishing-resistant MFA, using Microsoft's built-in Phishing-resistant MFA strength. From v1.3.0 the tool deploys CA901 instead, which also covers your privileged accounts group and doesn't accept synced passkeys. A CA100 policy that an earlier release created stays in your tenant, as it is: CA100 isn't part of the baseline any more, so the tool doesn't compare or update it, and it never deletes a policy. Once CA901 is in place, you can delete CA100 in the Entra admin center.

The admin roles in CA901#

CA901 applies to the 14 roles Microsoft recommends phishing-resistant MFA for, chosen by role, not by account name, as well as everyone in the privileged accounts group:

Global Administrator, Application Administrator, Authentication Administrator, Billing Administrator, Cloud Application Administrator, Conditional Access Administrator, Exchange Administrator, Helpdesk Administrator, Password Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator and User Administrator.

The break-glass group is left out, even though break-glass accounts usually hold Global Administrator.

Give admins a device-bound passkey first

CA901 would block any admin who doesn't have a device-bound passkey (Microsoft Authenticator or a security key). A synced passkey doesn't count, nor do Windows Hello for Business or a certificate (smart card), and if you turned on CA901's authenticator list, neither does a security key whose model isn't on it. A new admin can use a one-time Temporary Access Pass to register their first passkey. It's report-only, so nothing is blocked yet, but sort this out before you turn it on. The assessment's Admin accounts card shows who still needs one, who only has Windows Hello for Business, and who relies on a synced passkey.

Guests#

CA300 and CA301 cover every kind of guest and external user: internal guests, B2B collaboration guests and members, B2B direct connect users, service providers and other external users, from any external tenant.

The authentication strengths#

The user strength#

CA002, CA103, CA200 and CA204 use a custom authentication strength, AKC Baseline - No SMS or voice (or the name you gave it). It allows MFA without text or voice codes, with the same methods as Auth-Onboard's, so the two tools agree:

Method	In Microsoft's terms
Passkey or FIDO2 security key	`fido2`
Windows Hello for Business	`windowsHelloForBusiness`
Certificate-based authentication (multifactor)	`x509CertificateMultiFactor`
Microsoft Authenticator passwordless sign-in	`deviceBasedPush`
Password and Microsoft Authenticator push	`password,microsoftAuthenticatorPush`
Password and a code app	`password,softwareOath`
Password and a hardware token	`password,hardwareOath`
One-time Temporary Access Pass, for first sign-in	`temporaryAccessPassOneTime`

If none of those four policies is in your plan, the user strength isn't created. CA205 uses Microsoft's built-in Phishing-resistant MFA strength, and CA300 uses the standard Require multifactor authentication control.

The admin strength#

Updated in v1.4.3

CA901 uses a second custom strength, AKC Baseline - Admin keys (or the name you gave it). From v1.4.3 it allows passkeys and a Temporary Access Pass, and nothing else:

Method	In Microsoft's terms
Attested, device-bound passkey: a FIDO2 security key or Microsoft Authenticator (limited by the passkey profile, and by AAGUID too if you turn on the list, below)	`fido2`
One-time Temporary Access Pass, so a new admin can register their first passkey	`temporaryAccessPassOneTime`

Certificate-based authentication (smart cards) and Windows Hello for Business aren't accepted. The "Also allow Windows Hello for Business" option from v1.4.2 has gone.

Why only passkeys and a Temporary Access Pass#

The Policies step explains this beside the admin strength, because it's about human nature:

People reuse what's easy. On a PC they also use for everyday work, people set the same Windows Hello PIN for their admin account as for their everyday one, so Windows Hello for Business would make the admin sign-in only as strong as the everyday one.
Smart cards get shared. Cards and their PINs get lent, written down or left in readers, and certificates aren't checked as genuine when they're issued.
Passkeys can't be phished or reused. A passkey on a security key or in Microsoft Authenticator is bound to that device and checked as genuine when it's registered (attestation), and it's separate from everyday sign-in.
A Temporary Access Pass gets a new admin started. It's one-time and short-lived, so they can register their first passkey. For an admin account, only a Privileged Authentication Administrator can issue one.

If you choose Also allow synced passkeys for privileged accounts (see The passkey profile), the page says privileged accounts can use synced passkeys too, as well as the one-time Temporary Access Pass. Nothing else is added.

It's always created, because CA901 is always in the plan. If a strength with that name already exists, it's kept exactly as it is, including which methods and authenticators it allows, and Review warns you. An admin strength created by an earlier version still allows certificates, and Windows Hello for Business too if it was created before v1.4.2 or you allowed it, but not the Temporary Access Pass. To bring it up to date, edit the strength in the Entra admin center (Authentication methods > Authentication strengths), or delete it and deploy again.

Attestation does the main job#

New in v1.4.4

What keeps privileged accounts to genuine, device-bound passkeys is attestation in the Passkey-Privileged passkey profile. With the recommended choice, a privileged account can only register a passkey that proves it's a certified model: a FIDO2 security key or Microsoft Authenticator. Synced passkeys can't be attested, so they can't be registered under that profile.

Attestation is checked when a passkey is registered, not at sign-in: Conditional Access doesn't check it. And when someone is in more than one passkey profile, the most permissive wins. So if a broader profile, typically Default for all users, allows synced passkeys, your admins could still register one through it. Review warns you when that's the case, and you have two ways to close the gap: make that profile device-bound with attestation, or turn on CA901's authenticator list, below.

Limiting passkeys by AAGUID#

Updated in v1.4.4

Every passkey and security key model has an AAGUID, an ID for the make and model of authenticator. Also limit CA901 to listed authenticators is off by default from v1.4.4. Tick it, and the admin strength only accepts passkeys from the models you list. Synced passkeys (iCloud Keychain, Google Password Manager, password managers) don't match, so they can never satisfy CA901, even if another passkey profile allows them. That's why it's the other fix when a broader profile allows synced passkeys.

When you tick it, the list starts with Microsoft Authenticator's device-bound passkeys, as confirmed by Microsoft. They're only used if the list is on:

Authenticator	AAGUID
Microsoft Authenticator for iOS	`90a3ccdf-635c-4729-a248-9b709135078f`
Microsoft Authenticator for Android	`de1e552d-db1d-4423-a619-566b625cdc84`

Add your security keys' AAGUIDs, one per line (commas or spaces work too; the tool tidies the list and removes repeats). Each one is a GUID. To find a key's AAGUID:

In the Entra admin center: open a user who has registered that key, choose Authentication methods, and open the passkey's details. The AAGUID is shown there.
From the key's maker: most publish the AAGUIDs of their models.

Anyone whose key model isn't listed would be blocked once CA901 is turned on, so check the report-only results first. The Temporary Access Pass isn't affected by the list.

If you leave the list off, Review warns you when it isn't enough on its own: see The checks.

If you choose Also allow synced passkeys for privileged accounts (see The passkey profile), the list is turned off and can't be ticked: synced passkeys have no authenticator model to list, so they could never pass it. The page says why.

Microsoft's terms: the restriction is a fido2CombinationConfiguration on the admin strength, with allowedAAGUIDs. It's added straight after the strength is created. An existing strength isn't changed.

The passkey profile#

Updated in v1.4.1

With Add the Passkey-Privileged passkey profile ticked (the default), the tool adds a passkey profile called Passkey-Privileged to your tenant's passkey (FIDO2) policy, targeted at the privileged accounts group only. You choose which passkeys it allows:

Choice	Passkeys allowed	Attestation	CA901's authenticator list
Device-bound only, attestation required (recommended), the default	Device-bound only: a FIDO2 security key or Microsoft Authenticator	Required at registration, so the authenticator has to prove it's a genuine model	Optional, off by default
Also allow synced passkeys (Apple, Google): not recommended	Device-bound and synced: iCloud Keychain, Google Password Manager and password managers as well	Off, because synced passkeys can't be attested	Turned off: synced passkeys have no model to list

Device-bound with attestation is what Microsoft recommends for admins, and what the baseline uses.

Synced passkeys aren't recommended for privileged accounts

A synced passkey is copied to every device signed in to the person's Apple or Google account, which you can't see, manage or wipe, and it can't be checked as genuine. Anyone who gets into that personal account gets an admin sign-in. The page shows this warning when you choose it, and Review and the DEPLOY confirmation say it isn't recommended. Keep it for a short transition at most, then switch back to device-bound and deploy again.

In Microsoft's terms, the recommended choice sets the profile to passkeyTypes: deviceBound with attestationEnforcement: registrationOnly. Allowing synced passkeys sets deviceBound,synced with attestation disabled.

Every other passkey profile and target stays as it is. Microsoft replaces the whole list of profiles and the whole list of targets when either is saved, so the tool reads the current policy, adds or corrects its own profile, and saves the full lists back: the profiles first, then the targets. If the privileged group was already targeted with other profiles, it now uses only Passkey-Privileged, and Review says so. If the passkey method was off, it's turned on for every existing target, not only privileged accounts, and Review says that too.

This takes effect immediately

Unlike the policies, the passkey profile isn't report-only. As soon as Deploy saves it, the recommended choice means privileged accounts can only register and use device-bound passkeys, with attestation. Any synced passkey they registered stops working for sign-in. Review shows this as a warning, and the DEPLOY confirmation says so.

Most permissive wins#

When someone is in more than one passkey target, the most permissive profile wins. So if another profile that allows synced passkeys is targeted at all users (or at another group your admins are in), privileged accounts can still use a synced passkey under that profile. Review warns you when that's the case.

Attestation doesn't help here: it's only checked at registration, under the profile the passkey is registered with, and Conditional Access doesn't check it at sign-in. If Review warns about a broader profile, do one of these:

Make that profile device-bound with attestation, in the Entra admin center (Authentication methods > Passkey (FIDO2)). Then no profile your admins are in allows synced passkeys.
Turn on CA901's authenticator list (see Limiting passkeys by AAGUID). Then a synced passkey can't satisfy the admin policy, whatever the passkey profiles allow.

Changing the choice later#

Deploy again with the other choice. Passkey-Privileged is corrected to match, and Review shows the passkey policy before and after first. Nothing else about the profile's target, or any other profile, changes.

When passkey profiles aren't turned on#

Passkey profiles are something your tenant has to turn on in the passkey policy, and turning them on can't be undone. Access Baseline never makes that change for you. If they aren't on, the passkey profile step is skipped, not failed: Review warns you, and the Done screen lists it as skipped. Without the profile, attestation isn't required for privileged accounts, so only CA901's authenticator list can keep synced passkeys out of admin sign-in. If the list is off as well, Review 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 later, turn passkey profiles on yourself in the Entra admin center (Authentication methods > Passkey (FIDO2)), then deploy again. Everything else is found by name and kept, so only the profile is added.

If the privileged group is in the passkey policy's exclude list, passkeys are blocked for it entirely. Review stops with a message: remove the group from the exclude list, or untick the passkey profile.

Exclusion groups#

If you leave A group of exceptions for each policy ticked, the tool creates one security group for each policy in your plan, named CA-Exclude-<reference> (for example CA-Exclude-CA200). Each policy leaves out its own exclusion group as well as the break-glass group.

So when someone needs an exception, such as a meeting room device that can't do MFA, you add them to that policy's exclusion group rather than editing the policy. Every exception is a membership you can see and review, and every member should have a reason.

Updated in v1.4.5

Exclusion groups are role-assignable, with no owner. Being in one takes someone out of a policy, so who can add a member matters as much as the policy itself. Only Privileged Role Administrators (and Global Administrators) can change who is in a role-assignable group. Groups Administrators, User Administrators and automated tools with group rights can't.

Exclusion groups created by v1.4.4 or earlier are ordinary groups with you as owner, and a group can't be made role-assignable afterwards. The tool keeps them and warns you on Review. To protect one, put it in a restricted management administrative unit, and check who is in it. One catch: Microsoft Entra access reviews can't be used on a group while it's in one.

The groups are created empty.

Review#

Nothing has changed yet when you reach Review. The page reads your tenant ("Checking your tenant: roles, licences, break-glass and what already exists") and shows the result before anything is sent.

The checks#

These stop the deploy until they're fixed (marked ✕):

A role you need isn't active. The message names the role and what it's for.
No Entra ID P1. Conditional Access needs it (it's in Microsoft 365 Business Premium, E3 and E5).
The break-glass group, or the privileged accounts group, can't be found. Choose it again.
A group with the name of your new break-glass or privileged accounts group already exists and isn't role-assignable. Choose it as an existing group, or use a different name.
The privileged group is in the passkey policy's exclude list. Remove it there, or untick the passkey profile.

These are warnings: you can still deploy, but read them:

Security defaults are on. Report-only policies work alongside them, but security defaults must be turned off before you turn any policy on.
The existing break-glass group isn't role-assignable. Groups Administrators, User Administrators and its owners could change who's in it, and so slip past every policy. A group can't be changed to role-assignable afterwards, so consider a new one.
The break-glass group has fewer than two members. Keep at least two break-glass accounts in it, each with a FIDO2 security key.
A new break-glass group will be created empty. Add at least two cloud-only break-glass accounts to it, each with a FIDO2 security key, before turning any policy on.
The existing privileged accounts group isn't role-assignable. Groups Administrators, User Administrators and its owners could take someone out of it and weaken their sign-in.
Existing exception groups aren't role-assignable. The warning names them. Groups Administrators, User Administrators and the groups' owners can add someone and take them out of a policy. See Exclusion groups.
A chosen account is also in the break-glass group. Break-glass is left out of every policy, so CA901 won't apply to it.
No accounts are chosen for the privileged group. CA901 still covers the 14 admin roles.
The admin strength already exists and is kept as it is, including which authenticators it allows.
Nothing keeps synced passkeys away from privileged accounts, if CA901's authenticator list is off and you unticked the passkey profile. Turn one of them on.
CA901's authenticator list is off and passkey profiles aren't turned on, so nothing keeps synced passkeys away from privileged accounts yet. Turn on passkey profiles and deploy again, or turn on the list.
Passkey profiles aren't turned on, so the passkey profile is skipped.
The passkey profile's effects: privileged accounts can only register device-bound passkeys, and any synced passkey they registered stops working for sign-in; the passkey method will be turned on if it was off; the privileged group will use only the device-bound profile if it had others; and a broader target that allows synced passkeys (see Most permissive wins).
Another passkey profile that allows synced passkeys is targeted at all users, typically Default. With CA901's authenticator list off, it says admins could still register a synced passkey through that profile, and Conditional Access doesn't check attestation at sign-in, and tells you to make that profile device-bound with attestation, or turn on the list. With the list on, it says the list keeps synced passkeys out, so keep it on. If the broader targets are other groups, it says how many, and to keep privileged accounts out of them or turn on the list.
Some policies already exist and are kept as they are unless you choose to update them below. The warning says how many, and which differ from the baseline, or that they all match.
The break-glass group isn't excluded from an existing policy. The warning names the policies. Update them on Review, or add the exclusion yourself, before turning anything on.
Privileged accounts will be allowed synced passkeys, if you chose that: not recommended.

When your roles are enough, the list shows You hold the roles this needs. If you hold more than needed, a notice names the smaller role and how to activate it with PIM. It's a notice, never a blocker.

The exact settings#

Below the checks, Review shows:

Groups: each group, whether it's new or existing, its owner, and (exists: kept) where a group of that name is already there. Each account to be added to the privileged group has its own line (Add … to CA-Privileged-Accounts); accounts already in it aren't listed.
Authentication strength: the user strength's name and every method it allows, with the exact body sent to Microsoft.
Admin strength: its name, its methods and, if you turned on the list, the AAGUIDs its passkeys are limited to, with the exact body sent to Microsoft, restriction included.
Passkey profile: whether it will be added, corrected, is already in place, or is skipped. When something will change, the passkey policy is shown Now and After, side by side: each profile with its passkey types and attestation, each target with its profiles, and each exclusion.
Conditional Access policies: each one marked new (+), already there and matching the baseline (=), or already there and different (≠), with who it applies to. For a policy that differs, a table shows each difference, with Update to the baseline below it: see Running it again. For every new policy, The exact settings sent to Microsoft opens the full Microsoft Graph body. Groups and strengths that don't exist yet appear as (new group: name) or (new strength: name) until Deploy creates them.

Choose Check again after fixing something, or Change the design to go back.

Typing DEPLOY#

When you choose Deploy, a confirmation tells you how many policies it will create, all report-only, plus the groups, members and authentication strengths listed; that nobody's sign-in changes until you turn a policy on; and that anything already there is left exactly as it is. If you ticked Update to the baseline for any policy, it lists them, and says only the parts the baseline owns change: their state (on or report-only), who they target and your exclusions are kept. If the passkey policy will change, it also says what privileged accounts will be allowed (device-bound passkeys only, attestation required; or synced passkeys allowed, not recommended), that it happens straight away, and that this change isn't report-only. Type DEPLOY to go ahead.

Deploying needs more Microsoft Graph permissions than the assessment. They're asked for at this point only, when you deploy, and used in this tab only. They're delegated, so they can only do what your own roles allow, and they're never stored.

If they haven't been granted yet, Review lists them and the button reads Consent and continue. You go to Microsoft to consent, and come back to Review. These permissions need admin consent, so the first time, someone who can grant admin consent approves them.

Permission	When it's asked for	What it's for
`Policy.Read.All`	Always	Reads existing Conditional Access policies and authentication strengths, so nothing is created twice.
`Policy.ReadWrite.ConditionalAccess`	Always	Creates the Conditional Access policies and the authentication strengths.
`Application.Read.All`	Always	Microsoft's Conditional Access API needs it to read the apps a policy refers to.
`Group.ReadWrite.All`	When creating any group, or adding accounts to the privileged group	Creates the pilot, exclusion, break-glass and privileged accounts groups, and adds the members.
`RoleManagement.ReadWrite.Directory`	For a new break-glass group, a new privileged accounts group, the exclusion groups, or adding accounts to the privileged group	Creating a role-assignable group, and changing who is in one, needs it.
`Policy.ReadWrite.AuthenticationMethod`	When the passkey profile is ticked	Adds the Passkey-Privileged profile to the passkey policy.

Deploy#

Deploy runs four steps in order, and shows each one's progress and a log:

Groups: the break-glass group (if new), the pilot group (if new), the privileged accounts group (if new), the chosen privileged accounts added to it, and the exclusion groups.
Authentication strengths: the user strength, if a policy in the plan uses it, and the admin strength, with its AAGUID restriction if you turned on the list.
Passkey profile: Passkey-Privileged, targeted at the privileged group. Skipped if passkey profiles aren't turned on, or if you unticked it.
Conditional Access policies: each new one report-only (enabledForReportingButNotEnforced), leaving out the break-glass group. Each existing policy you chose to update is read again and brought back to the baseline.

Before creating anything, each step looks for it by name. If it's already there, it's kept and left exactly as it is: an existing group or strength is never changed or overwritten, and nor is an existing policy, unless you ticked Update to the baseline for it. Privileged accounts already in the group are left there, and nobody is removed. Every object it creates says Created by AKC Access Baseline. in its description, so you can tell it apart.

The passkey profile is also an exception: if Passkey-Privileged is already there but doesn't match your choice (device-bound with attestation, or synced allowed), or isn't the only profile for the privileged group, it's corrected. Review shows this before and after.

Running again is safe. If a step fails part-way, fix the cause and choose Run again: it only adds what's still missing.

AKC records which steps ran (groups, strength, passkey, policies), with your tenant's ID and the release. No names, settings or tokens are sent. If that record can't be saved, the log says so; your tenant isn't affected.

Running it again: compare and update#

New in v1.4.0. You can run Deploy again whenever you like: to add a policy you left out, after someone has edited a policy, or after a new release. Nothing existing changes unless you choose it.

How existing policies are found#

Each baseline policy is looked for by its exact name first. If there's no exact match, it's looked for by the reference at the start of the name, so CA200 - Require MFA for all users is still found as CA200 after someone renamed it. That way a renamed policy isn't created twice. Conditional Access policies have no description field, so the reference in the name is what the tool relies on: keep it at the start when you rename one.

Only a clear match counts. If two policies both start with the same reference, neither is used, and the baseline policy is treated as new.

What Review shows#

Review compares each policy it found with what the baseline would create today, setting by setting:

Exists: matches the baseline (=): nothing to do.
Exists: differs in … ways, left as it is (≠): a table lists each difference, with Setting, In your tenant and Baseline columns. Below it, Kept as yours lists what's yours and never changes, such as the policy's state, a new name, Targets all users (widened from the pilot) or Your other exclusions.

Each policy that differs has its own Update to the baseline tick box. A policy missing the break-glass exclusion is ticked by default, because that's the most serious difference. Every other policy is left as it is unless you tick it.

What "Update to the baseline" changes#

Only the settings the baseline owns:

The baseline owns (can be updated)	Yours (never changed)
The apps and user actions it covers (your own extra app exceptions are kept)	The state: on, off or report-only
Client app types	Who the policy targets, for example widened from the pilot to all users
Authentication flows (CA001)	The name
Sign-in and user risk levels (CA204, CA205)	Extra exclusions
The grant: block, require MFA or an authentication strength	Terms of use
Sign-in frequency: every time (CA204 and CA205)	Other grant and session controls
CA901's admin roles: missing roles are added, never removed
The break-glass exclusion

When you deploy, each policy you ticked is read again, and only those parts are sent. The log says Updated … to the baseline. Its state, targeting and your exclusions are kept. If it already matches by then, it's left alone.

An update doesn't turn a policy on or back to report-only: a policy you've turned on stays on, with the baseline's settings.

Done: what to do next#

The last screen says how many items were created, how many policies were updated to the baseline (for example, updated 1 policy to the baseline), and how many already existed and were left as they were, with a list of what was created and anything skipped (such as the passkey profile, if passkey profiles aren't turned on). Nobody's sign-in has changed by the policies. Then:

Make sure the break-glass group has at least two cloud-only accounts, each with a FIDO2 security key.
Add a few people to the pilot group: IT first.
Give every admin a device-bound passkey: Microsoft Authenticator or a security key. CA901 would block any admin without one; synced passkeys, Windows Hello for Business and certificates don't count.
Once the pilot has been running, check what each policy would have done: in the Entra admin center, Conditional Access > Insights and reporting, or the sign-in logs' report-only tab.
Turn policies on, and widen them beyond the pilot, in the Entra admin center for now, one policy at a time. The tool doesn't do this yet.

When you've finished, you can remove the tool's access: see Afterwards: remove the app.

Not in this release yet#

These are planned, not available in v1.4.5. See Coming next.

Creating break-glass accounts. Create them yourself in the Entra admin center and add them to the break-glass group.
The wider authentication methods: passkeys for everyone, Authenticator settings, Temporary Access Pass, turning off text and voice codes, the registration campaign. v1.4.5 only adds the passkey profile for privileged accounts.
Turning policies on. Everything stays report-only until you change it in the Entra admin center.
Widening policies beyond the pilot group, to wider rings and then all users.