Security model#
What it reads, and what it writes#
The assessment only reads. It asks for read permissions only, and never writes to your tenant.
Deploy the baseline writes, and only when you choose to:
- You see everything first. Review shows every group and member to be added, both authentication strengths, the passkey policy before and after, and each policy's exact Microsoft Graph body. Nothing is sent until you type DEPLOY.
- Report-only. Every policy is created report-only (
enabledForReportingButNotEnforced). It records what it would have done and changes nobody's sign-in until you turn it on yourself. - The passkey profile isn't report-only. It takes effect as soon as it's saved: by default, privileged accounts can only use device-bound passkeys, with attestation. Review warns you, and the DEPLOY confirmation says so.
- Nothing existing is changed unless you choose it. Each group, strength and policy is looked for by name first. An existing group or strength is left exactly as it is. An existing baseline policy is compared with the baseline on Review, and only updated if you tick Update to the baseline for it; even then only the baseline's own settings change, never its state, who it targets, its name or your exclusions. Nothing is ever deleted. Accounts are only ever added to the privileged group, never removed.
- The passkey policy is merged, not replaced. The tool adds or corrects its own Passkey-Privileged profile and its target, and keeps every other profile, target and exclusion. It never turns on passkey profiles for you, because that can't be undone.
- Break-glass is always left out. Every policy excludes the break-glass group, CA901 included, and the tool won't deploy without one. A new break-glass group, a new privileged accounts group and the exclusion groups are role-assignable, so only Privileged Role Administrators can change who is in them.
- What it changes. This release creates groups, adds the accounts you chose to the privileged group, creates two authentication strengths and the Conditional Access policies, updates the existing baseline policies you choose, and adds one passkey profile for privileged accounts. It doesn't create accounts, change any other authentication method, turn policies on or delete anything.
Everything it creates says Created by AKC Access Baseline. in its description.
Your sign-in, in your browser#
- The page runs in your browser and reads Microsoft Graph with your own delegated sign-in, so it can only read what your role allows.
- Your Microsoft tokens stay in the browser tab. AKC never receives them, and no Microsoft token is stored. The deploy permissions are used only in that tab, for the deploy.
- The assessment runs in the browser, and the report (CSV or JSON) is made there and saved straight to your computer. Nothing it finds is sent to AKC.
- AKC records only your tenant's ID and name, to link the tenant to your organisation's Andy Kemp Tools account, and, when you deploy, which deploy steps ran (groups, strength, passkey, policies) and the release. No group names, policy settings or findings are sent.
The report names accounts in your tenant (break-glass accounts, admins without a phishing-resistant method, Global Administrators). Keep it as you would any security report. In the CSV, any cell that starts with =, +, - or @ is made harmless, so a spreadsheet won't treat a name or policy as a formula.
Permissions#
The app, AKC Baseline Deployer, is a multi-tenant app. For the assessment it uses three delegated, read-only Microsoft Graph permissions:
| Permission | Used for |
|---|---|
Directory.Read.All |
Users, groups, roles and licences |
Policy.Read.All |
Conditional Access, security defaults, authentication strengths and the authentication methods policy |
AuditLog.Read.All |
The sign-in methods report |
Consent is granted once per tenant by someone who can grant admin consent; Cloud Application Administrator is enough.
Deploy permissions#
Deploying asks for these, only when you deploy, and only the ones your design needs. They're delegated, so they can only do what your own roles allow, and they're used in that tab only.
| Permission | When | Used for |
|---|---|---|
Policy.Read.All |
Always | Reading existing policies and authentication strengths, so nothing is created twice |
Policy.ReadWrite.ConditionalAccess |
Always | Creating the Conditional Access policies and the authentication strengths |
Application.Read.All |
Always | Required by Microsoft's Conditional Access API |
Group.ReadWrite.All |
When creating groups or adding privileged accounts | Creating the pilot, exclusion, break-glass and privileged accounts groups, and adding members |
RoleManagement.ReadWrite.Directory |
For a new break-glass or privileged accounts group, or adding privileged accounts | Creating a role-assignable group, and changing who is in one |
Policy.ReadWrite.AuthenticationMethod |
When the passkey profile is ticked | Adding the Passkey-Privileged profile to the passkey policy |
The app has no application (app-only) permissions, and no access to Azure Resource Manager.
Least privilege#
- Global Reader is the smallest role that reads everything. Security Reader reads everything except the authentication methods policy.
- The page shows the roles you hold. If you hold more than the assessment needs, such as Global Administrator, a notice names the smaller role and how to activate it just in time with Privileged Identity Management. It's a notice, never a blocker.
- Each area is read on its own, so an area your role can't read is reported as couldn't read rather than stopping the assessment.
- Deploying checks the roles it needs on the Review screen: Conditional Access Administrator always, Groups Administrator to create groups, Privileged Role Administrator for the role-assignable break-glass, privileged accounts and exclusion groups, and Authentication Policy Administrator for the passkey profile. A missing role stops the deploy with a clear message. Global Administrator is never needed. See Who can run it.
Access to the tool#
Access is per organisation: your organisation requests Access Baseline and Andy approves it in the AKC admin centre. Without approval, the page shows only what it does and the request form.
Removing it#
Access Baseline doesn't need to stay in your tenant. Delete AKC Baseline Deployer in Entra admin center > Enterprise applications > AKC Baseline Deployer > Properties, and every permission you consented to goes with it. The groups, strengths, passkey profile and policies it created stay in your tenant, as yours.