Skip to content
Andy Kemp Consulting

What's new#

Access Baseline has one version number, shown at the top of the page. Every update gets a new number.

v1.4.5#

Exception groups are protected. See Exclusion groups.

  • New exclusion groups (CA-Exclude-CA001 and so on) are role-assignable, with no owner. Being in one takes someone out of a policy, so only Privileged Role Administrators can now add an exception. Before, a Groups Administrator, a User Administrator or the group's owner could.
  • A plan with exclusion groups needs Privileged Role Administrator at Deploy, as a new break-glass or privileged accounts group already did.
  • Exclusion groups you already have are kept as they are. A group can't be made role-assignable afterwards, so Review names them and says how to protect them.
  • The pilot group is unchanged.

v1.4.4#

Attestation first, the authenticator list optional. See Attestation does the main job.

  • CA901's authenticator (AAGUID) list is now off by default. Attestation in the Passkey-Privileged profile is the main control: only certified FIDO2 security keys and Microsoft Authenticator can register a passkey for a privileged account. The design option is now called Also limit CA901 to listed authenticators.
  • The two pre-filled AAGUIDs are Microsoft Authenticator's, confirmed by Microsoft: iOS 90a3ccdf-635c-4729-a248-9b709135078f and Android de1e552d-db1d-4423-a619-566b625cdc84. They're only used if you turn the list on.
  • Review warns when attestation isn't enough on its own. Attestation only applies when a passkey is registered, Conditional Access doesn't check it at sign-in, and the most permissive passkey profile wins. So when a broader profile (typically Default, for all users) allows synced passkeys and the list is off, Review says so, and what to do: make that profile device-bound with attestation, or turn the list on. See Most permissive wins.
  • A stronger warning appears when neither the list nor the passkey profile is in place, or when passkey profiles aren't turned on in your tenant and the list is off.

v1.4.3#

Privileged accounts use passkeys and a Temporary Access Pass only. See The admin strength.

  • CA901's admin strength, AKC Baseline - Admin keys, now allows only attested, device-bound passkeys (a FIDO2 security key or Microsoft Authenticator) and a one-time Temporary Access Pass, so a new admin can register their first passkey. For an admin account, only a Privileged Authentication Administrator can issue that pass.
  • Certificate-based authentication (smart cards) is no longer accepted for privileged accounts.
  • Windows Hello for Business is no longer accepted, and the "Also allow Windows Hello for Business" option from v1.4.2 has gone.
  • Why: human nature. People reuse their everyday Windows Hello PIN for their admin account on the same PC. Smart cards and their PINs get lent, written down or left in readers, and certificates aren't checked as genuine when they're issued. Passkeys are device-bound, attested and separate from everyday sign-in. The Policies step explains this beside the admin strength.
  • An admin strength created by an earlier version is kept as it is, so it still allows certificates (and Windows Hello for Business, if it did before). Edit it in the Entra admin center, or delete it and deploy again, to bring it up to date.
  • The assessment's admin finding no longer mentions certificates: Windows Hello for Business and certificates don't count. The admin policy check counts a strength of passkeys plus a one-time Temporary Access Pass as phishing-resistant, but not a pass on its own. See Findings.

v1.4.2#

No Windows Hello for Business for admins, by default. See The admin strength.

  • CA901's admin strength, AKC Baseline - Admin keys, now allows device-bound passkeys (security keys, Microsoft Authenticator) and certificates only.
  • "Also allow Windows Hello for Business" is an option, off by default. It ties an admin's sign-in to one PC, and where the admin account and the everyday account share that PC, people tend to use the same Windows Hello PIN for both, so the admin credential is no stronger than the everyday one. A security key or Authenticator passkey keeps them separate. Consider it only on dedicated, managed privileged access workstations.
  • An admin strength created by an earlier version is kept as it is, so it still allows Windows Hello for Business. Edit it in the Entra admin center, or delete it and deploy again, to drop it.
  • The assessment's admin finding is now Every admin has a device-bound passkey or security key, and notes admins who only have Windows Hello for Business. See Findings.

v1.4.1#

Privileged passkeys, attestation required. See The passkey profile.

  • Device-bound only, attestation required, by default. The Passkey-Privileged profile allows only device-bound passkeys (a FIDO2 security key or Microsoft Authenticator), and each one has to prove it's a genuine model when it's registered.
  • A separate choice: "Also allow synced passkeys (Apple, Google): not recommended". It allows iCloud Keychain, Google Password Manager and password managers as well, so attestation is turned off for that profile (synced passkeys can't be attested), and CA901's authenticator list is turned off (synced passkeys have no model to list). The page, Review and the DEPLOY confirmation all warn that it isn't recommended.

v1.4.0#

Compare and update: running Deploy again is now a way to bring existing policies back to the baseline. See Running it again: compare and update.

  • Existing baseline policies are found by their exact name, or else by the reference at the start of the name, so a renamed policy isn't created twice.
  • Review compares each one with the baseline, setting by setting, and shows matches the baseline or a table of each difference, with what's yours and kept.
  • "Update to the baseline", chosen per policy, changes only the baseline's own settings: the apps, client apps, authentication flows, risk levels, the grant or authentication strength, sign-in frequency on CA204 and CA205, CA901's admin roles (only ever added) and the break-glass exclusion.
  • It never changes the policy's state (on or report-only), who it targets, its name, your extra exclusions, terms of use or other controls.
  • A policy missing the break-glass exclusion is ticked for update by default. Everything else is left as it is unless you tick it.
  • The DEPLOY confirmation lists the policies to be updated, and the Done screen says how many were updated to the baseline.

v1.3.0#

Privileged accounts, with device-bound keys only. See Deploy the baseline.

  • CA901 replaces CA100. Privileged accounts need device-bound phishing-resistant MFA targets the 14 admin roles and your privileged accounts group, with the break-glass group left out. It's always included and report-only. A CA100 policy from an earlier release is left in your tenant as it is.
  • A new admin strength, AKC Baseline - Admin keys: device-bound passkeys, Windows Hello and certificates. By default its passkeys were limited by AAGUID to the authenticator models you list, with Microsoft Authenticator's filled in, so synced passkeys never satisfy CA901 (off by default from v1.4.4). See Limiting passkeys by AAGUID.
  • A new design step, Privileged accounts: an existing group, or a new role-assignable CA-Privileged-Accounts. It suggests the accounts holding an admin role now, with break-glass accounts labelled and left out of Choose all except break-glass, and has a search to add others. Members are only ever added, never removed.
  • The Passkey-Privileged passkey profile: device-bound, attestation enforced, targeted at the privileged group only. Every other profile and target is kept. Review shows the passkey policy before and after, and warns when a broader target still allows synced passkeys (the most permissive profile wins). It's skipped if your tenant hasn't turned on passkey profiles, and it takes effect straight away: it isn't report-only, and the DEPLOY confirmation says so. See The passkey profile.
  • Deploy order: groups (and privileged members), strengths, passkey profile, policies.
  • New role and permissions: Authentication Policy Administrator for the passkey profile; the Policy.ReadWrite.AuthenticationMethod permission; and RoleManagement.ReadWrite.Directory also for a new privileged accounts group and adding its members. See Who can run it.
  • A new assessment finding: No admin relies on a synced passkey. The admin policy check is now CA901, and looks for the same thing as CA100 did. See Findings.

v1.2.1#

  • Fixed deploying stopping at the authentication strength. Microsoft limits its name to 30 characters, so the default is now "AKC Baseline - No SMS or voice" and the name box allows 30 characters. If a deploy stopped there, run it again: the groups it already created are found and kept.

v1.2.0#

Deploy the core Conditional Access policies. The assessment is unchanged. See Deploy the baseline.

  • 2. Deploy the baseline, after the assessment: three short steps for the break-glass group, the pilot group and the policies.
  • A break-glass group is required: an existing one, or a new role-assignable one. It's left out of every policy.
  • A pilot group (existing or new), and optionally one exclusion group per policy (CA-Exclude-CA001 and so on).
  • The core policies: CA000, CA001, CA002, CA100, CA103, CA200, CA300 and CA301, plus CA204 and CA205 with Entra ID P2. CA000 and CA100 are always included.
  • CA001 leaves out the Device Registration Service, so devices can still register, and blocking authentication transfer is optional.
  • A custom authentication strength, AKC Baseline - No SMS or voice, with the same methods as Auth-Onboard's.
  • Review checks your roles, the P1 licence, security defaults, the break-glass group and what already exists by name, shows every group, the strength and each policy's exact settings, and asks you to type DEPLOY.
  • Everything is created report-only. Anything that already exists by name is left exactly as it is, so running again is safe.
  • Extra permissions are asked for only when you deploy, and only the ones your design needs. See Consent to the deploy permissions.

v1.1.0#

The findings, laid out to be understood at a glance. The checks themselves are unchanged.

  • Your result first: a score dial, a one-line verdict, and the six areas with a bar each. Select an area to filter.
  • Fix these first: the five most important gaps, in order.
  • Passkey readiness: how your members sign in today, in four bands.
  • Conditional Access coverage and Admin accounts at a glance.
  • All findings with filters and search. Each opens to what was found, why it matters and what to do, with a link to the docs.
  • Progress since your last run, remembered in your browser only.
  • Save as PDF: an Andy Kemp Consulting branded report.
  • Long account names wrap on phones.

v1.0.1#

  • Fixed a false "Your Microsoft sign-in has expired" message that could appear when connecting your tenant.

v1.0.0#

The first release: a read-only assessment of sign-in security in your tenant, at deploy.andykemp.com/baseline.

  • Six areas: licences, break-glass access, Conditional Access, authentication methods, how people sign in, and admin accounts. See Findings.
  • Each finding with its severity, the catalogue reference where there is one, why it matters and what to do.
  • A score weighted by severity.
  • Your roles, with a notice when you hold more than the assessment needs, and the roles the deploy phase will need.
  • Findings as CSV and the full report as JSON, made in your browser.
  • Three read-only permissions; Global Reader is all you need to run it.
  • Sign-in strength worked out the same way as Auth-Onboard, so the two tools agree.