How well is sign-in protected in your tenant?

Your organisation requests access to Access Baseline on deploy.andykemp.com, and Andy Kemp Consulting approves it. Approval is per organisation.

The assessment doesn't: it reads your directory, policies and the sign-in methods report, and changes nothing. Changes happen only if you choose to deploy the core policies, after you've reviewed every value and typed DEPLOY. Even then, every policy is created report-only on a pilot group, and an existing policy is only updated if you choose that on the review screen.

For the assessment, Global Reader, the smallest role that reads everything it checks. Security Reader works too, apart from the authentication methods policy. To deploy, Conditional Access Administrator, plus Groups Administrator for new groups, Privileged Role Administrator for the role-assignable break-glass, privileged accounts and exclusion groups, and Authentication Policy Administrator for the passkey profile. Granting consent needs someone who can grant admin consent, such as a Cloud Application Administrator.

Only your tenant's ID and name, to link it to your organisation. Your tokens stay in your browser tab, and the findings and report never leave your browser.

It's left as it is unless you choose otherwise. Access Baseline finds each existing baseline policy by name, or by the reference at the start of the name if someone renamed it, and the review compares it with the baseline, setting by setting. Tick "Update to the baseline" for a policy and only the baseline's own settings change: its state, who it targets, its name and your exclusions are kept. A policy missing the break-glass exclusion is ticked for you. Existing groups and authentication strengths are never changed, and nothing is removed. The passkey policy is merged: its own profile is added, and every other profile and target is kept.

Yes. Conditional Access needs Entra ID P1, but the assessment still runs without it and says so, alongside everything else it checks.

Because of human nature. 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 and their PINs get lent, written down or left in readers, and certificates aren't checked as genuine when they're issued. A passkey on a security key or in Microsoft Authenticator is bound to that device, checked as genuine when it's registered, and separate from everyday sign-in. A one-time Temporary Access Pass gets a new admin started, and for an admin account only a Privileged Authentication Administrator can issue one.

Yes, the core Conditional Access policies, and device-bound passkeys for your privileged accounts. Your break-glass group is required and left out of every policy, the user policies apply to a pilot group, and every policy is created report-only after you've reviewed every value. Turning policies on, widening them beyond the pilot, break-glass accounts and the wider authentication methods come next.