The operating principle
Three dimensions of privilege
Microsoft's least-privilege model asks what permissions an administrator needs, over which scope and for how long. A sensible managed-service plan limits all three and protects emergency access.
Classify the work before assigning roles
User account creation, licence assignment, password recovery, app consent and role assignment are separate tasks. Microsoft documents lower-privilege roles for many of them: User Administrator for user management, License Administrator for licences and narrower helpdesk roles for selected recovery actions.
Create a role-to-task matrix from the actual work queue. Any exception requiring broader access should have a named reason, time boundary and customer authorisation.
| Business request | Access question | Control to record |
|---|---|---|
| New starter | Who approves group membership? | Request, job function and data owner |
| Licence change | Is the licence tied to security controls? | SKU, feature dependency and payer |
| Admin elevation | Why is this role necessary now? | Duration, approver and audit event |
| Third-party app | Which delegated/application permissions are requested? | Owner, consent and credential rotation |
| Locked-out administrator | Can the tenant recover safely? | Emergency account test and independent custodian |
Protect emergency access without weakening normal control
Recovery accounts should be controlled and tested by the customer's authorised owner. If every administrator depends on the same Conditional Access or identity configuration, a policy mistake could prevent recovery.
Document a separate operational path for privilege escalation, service-provider offboarding and an unavailable identity provider. Ensure its credentials are not circulating in support tickets or email threads.
App identities need ownership too
Application registrations and service principals may retain privileges long after the person who created them has left. Inventory owners, consent, permissions, secret or certificate expiry and why each integration exists.
Revoking an unknown app without discovery can interrupt payroll or CRM workflows. The safer approach is to identify the owner and business dependency before approving changes.
Documented administration controls
- People, groups and service principals inventoried
- Privileged role assignments reviewed against tasks
- Emergency access has a custodian and safe verification process
- External application consent recorded and reviewed
- Supplier access revocation and exit procedure documented
A practical privileged-access review without disabling the business
Begin with the roles that carry the greatest blast radius, then establish whether each assignment is permanent, eligible through Privileged Identity Management or unnecessarily broad. Match the task to the least privilege Microsoft documents. Check the service principals as carefully as human administrators: an old integration may hold powerful application permissions even after the staff member who created it has left.
Review Conditional Access and authentication changes through an approved change window, including an emergency access account excluded from accidental lockout in line with the client's security model. The emergency account must remain under customer control and be monitored. Never propose disabling security policy merely to simplify an administrator's day-to-day workload.
| Identity control | Evidence to collect | Red flag |
|---|---|---|
| Admin role inventory | Assigned roles, scope and assignment duration | Permanent Global Administrator for routine support |
| Application consent | Publisher, requested scopes and business owner | Orphaned app with high-privilege API access |
| Emergency access | Named custodians and documented test | Every administrator can be locked out by one policy |
| User lifecycle | Role approval and group ownership | Automatic broad access without approval |
Change records must include the ability to recover
Before changing a policy or privileged assignment, write down who approved the change, which users or apps may be affected, the expected result and a reversible plan where technically possible. A Conditional Access change may require report-only evaluation and a protected pilot group; a role change requires audit history and owner confirmation. Escalate destructive or irreversible operations for separate sign-off.
Measure governance through fewer unowned privileged identities, documented application owners and evidence that joiners and leavers receive the right access—not a fabricated percentage reduction in risk.
Documented administration controls
- Role changes mapped to Microsoft's published task permissions
- High-risk service principals have named owners
- Customer-owned emergency access is tested safely
- Approval evidence captured for privileged or policy changes
- Supplier access can be revoked without losing customer control
A mature Entra service gives the business a smaller privileged footprint and a better explanation of every important access decision.
Primary technical references
Check current feature and licence requirements before changing a tenant. A service description is not evidence that a customer has purchased or activated an option.
Commercial next step
Assess identity administration coverage
Tell us the tenant size, current admin arrangement and whether your priority is everyday provisioning, privileged roles or application access.
Request an administration assessment