Cloud identity governance checklist, with Microsoft Entra as a documented example. Exact controls, role names and licensing differ across providers.
Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.Inventory identities and trust paths
Prefer scoped roles and time-limited elevation to routine use of a broad standing administrator account when the platform supports the required workflow. Keep emergency access independent enough to survive failure of normal sign-in. Federation and single sign-on simplify central control, but also create a dependency; an emergency design must account for that dependency rather than adding an unmonitored bypass.
List employees, guests, service accounts, application identities and supplier access. Record the owner and purpose of each privileged identity. Map federation, synchronisation and single sign-on dependencies so a failure in one system does not surprise every connected service.
Look for credentials and tokens used outside interactive sign-in. Removing a user from a group may not revoke an application secret or a separately provisioned SaaS account. Document which system is authoritative for each identity lifecycle.
Reduce standing privilege deliberately
Assign the smallest role and resource scope needed for the job. Separate ordinary work from administration and use time-limited elevation where supported and appropriate. Review direct assignments as well as group-derived permissions.
Test a restricted identity against both an allowed and a forbidden task. A successful login does not prove that authorisation is correct. Before reducing access, identify any automation or operational dependency that uses the role and plan a controlled transition.
Design emergency access and authentication
Use strong authentication for privileged access and keep recovery methods protected. Microsoft’s current emergency-access guidance recommends independent cloud-only access paths, monitoring and periodic validation. Follow the current tenant-specific requirements rather than copying an old exception recipe.
Record who may use emergency access, how credentials are retrieved and how use is reviewed. An account that nobody has tested or whose credential depends on the failed identity provider does not provide a dependable recovery path.
Review, revoke and verify
Set a recurring access review with an accountable service owner. Remove stale access through the provider’s supported process and check active sessions, refresh tokens and downstream applications as applicable. Preserve audit evidence for privileged changes.
Use an approved test account to exercise offboarding. Confirm both that access ends and that legitimate service ownership remains intact. If the platform cannot provide the required control or audit visibility on the current plan, record the gap and choose a proportionate compensating measure or plan change.
Close the identity lifecycle with verification
- Inventory
Identify people, applications, suppliers, owners and trust paths.
- Scope access
Approve the smallest role and resource scope; check allowed and forbidden tasks.
- Review
Reconcile direct and inherited access with current responsibilities.
- Revoke and verify
Check sessions, tokens and downstream accounts; preserve legitimate service ownership.
Measure privilege coverage by effective access
In an illustrative review of ten people with effective privileged access, eight current approvals give 80% reviewed coverage. Counting only direct assignments can miss group-derived privilege, while counting multiple roles held by one person can inflate a people-based denominator. State whether the measure concerns identities, assignments or resources.
Microsoft’s emergency-access baseline calls for two or more cloud-only accounts and validation at least every 90 days. Follow that documented baseline alongside event-triggered checks after material changes. These are recommended controls, not evidence that any account in your tenant has been configured or tested.