Skip to content
Andy Kemp Consulting

Access Baseline#

Sign-in security · v1.4.5

Access Baseline checks how well sign-in is protected in your own Microsoft tenant, against a best-practice, Zero Trust sign-in baseline. It tells you, in plain language, what's in place, what's missing, why it matters and what fixes it. It starts with passkeys and least privilege. The assessment changes nothing: it only reads.

Then, if you choose, it deploys the core Conditional Access policies, with a break-glass group, a pilot group and the authentication strengths they use. Your privileged accounts get their own group, a policy that only accepts device-bound phishing-resistant sign-in, and a passkey profile that allows device-bound passkeys only, with attestation required. You see every value on a review screen first, and every policy is created report-only, so nobody's sign-in changes until you turn a policy on. (The passkey profile for privileged accounts takes effect straight away, and Review says so.)

It runs in your browser at deploy.andykemp.com/baseline. You install nothing and run no scripts, your Microsoft sign-in stays in the browser tab, and the report is made in the browser and saved to your computer.

Watch the demo Open Access Baseline

What it checks#

The assessment looks at six areas. Each finding has a severity, says why it matters, and says what to do.

Area What it looks at
Licences Whether you have Entra ID P1 (needed for Conditional Access) and P2 (risk policies and just-in-time admin roles).
Break-glass access Whether emergency accounts exist, are left out of every Conditional Access policy, sit in a protected group and have a security key.
Conditional Access Legacy sign-in, device code phishing, protecting security info registration, MFA for everyone, phishing-resistant MFA for admins, Azure management, guests and, with P2, risky sign-ins and users. Also policies that apply to nothing, or sit in report-only.
Authentication methods Passkeys, Microsoft Authenticator, Temporary Access Pass, whether text and voice codes are still allowed, the registration campaign and system-preferred MFA.
How people sign in How many of your members have a passkey, Authenticator, only text codes, or nothing at all.
Admin accounts Admins without a phishing-resistant method, admins who rely on a synced passkey, and how many Global Administrators you have.

Every finding is listed on Findings.

How it works#

  1. Request access. Your organisation asks for Access Baseline and Andy approves it. See Before you start.
  2. Connect. Sign in with an account that holds Global Reader. The first time, someone who can grant admin consent approves three read-only permissions.
  3. Assess. The page reads your tenant, area by area, and shows your roles, a score, and every finding by area.
  4. Download. Save the report as a PDF, the findings as CSV or the full report as JSON. All are made in your browser.
  5. Deploy (optional). Choose the break-glass group, the privileged accounts, the pilot group and the policies, review every value, type DEPLOY, and consent to the deploy permissions. The policies are created report-only. Run it again later and Review compares the policies already there with the baseline; you choose which to update.

See Run the assessment and Deploy the baseline for each step.

What it doesn't do (yet)#

v1.4.5 deploys the core Conditional Access policies, the groups and strengths they use, and the device-bound passkey profile for privileged accounts, and brings existing baseline policies back to the baseline when you choose. These are planned and not yet available:

  • creating break-glass accounts (you create them and add them to the break-glass group);
  • the wider authentication methods (passkeys for everyone, Authenticator, Temporary Access Pass, turning off text and voice codes);
  • turning policies on;
  • widening policies beyond the pilot group.

See Coming next.

Where to go next#