Give identity and access its own lane, not a line inside "Microsoft 365."
MFA enrollment, a Conditional Access rule, a new SSO connection, a guest account nobody remembers inviting — these usually get absorbed into "Microsoft 365 administration" until a client asks a direct question about one of them. Naming this as its own inspectable lane beats discovering the gaps live.
What enters the identity and access lane.
Useful when MFA resets, access grants, and guest reviews are currently handled ad hoc by whoever is on the ticket, instead of following a written procedure.
MFA enrollment and method resets for named users, Conditional Access policy administration against an approved baseline — location, device, and risk conditions — SSO and SAML connections for third-party applications the client has already approved, and scheduled guest and external-account reviews confirming which outside accounts still need access.
An access review runs on its agreed cadence and returns a list of current guest and external accounts with a keep-or-remove recommendation attached; a Conditional Access change is applied against the documented baseline, or returns as an exception naming what it would affect.
The named identity provider and its administrative access method, the approved Conditional Access baseline, the SSO/SAML application list already cleared for connection, and a defined cadence for guest and access reviews.
Where identity work stops being routine.
- A new Conditional Access policy, or a change that could lock users outReturns for approval before it is applied — a mistake here can affect an entire client group at once, not just one request.
- An MFA reset requested mid-support-callIs checked against the authorized-requester list like any other access request; someone saying they are locked out is not, by itself, authorization.
- A new SSO or SAML application connectionIs proposed against the approved application list — connecting an unreviewed third-party app to the identity provider is a security decision, not a setup checkbox.
- A suspected compromised accountEscalates immediately as a security incident, ahead of the standard exception queue — see the security-baseline lane for what happens next.
These triggers do not name a specific identity platform; the actual provider and baseline belong in the written lane definition. A leaver's access removal is a joiner/mover/leaver event too — see that lane for the offboarding-specific safe-stop.
Who decides, once an identity request stops being routine.
| Approved MFA enrollment or reset | Delivery applies it against the documented authorization check. |
|---|---|
| New Conditional Access policy or rule change | Named security owner approves, per the escalation matrix. |
| New SSO/SAML application connection | Selling practice or client approves the application before delivery connects it. |
| Guest and external-account review | Delivery runs the review and reports; removal decisions return to the named owner. |
Ask these before assuming identity is covered.
- Does the lane name the actual identity provider, or just say "Microsoft 365"?Entra ID, a separate SSO provider, and a Google identity are not interchangeable in scope.
- Who is on the authorized list for an MFA reset request?Confirm it before the first "I'm locked out" call, not during one.
- Does anyone actually review the guest-account list, or does it just get generated?A report nobody reads is not a control — see how the compliance-evidence lane treats the same problem.
- What happens to a Conditional Access change that would affect every user at once?It should trigger the same exception path every time, not only when someone remembers to ask.
See where identity work joins the rest of the tenant.
Microsoft 365 administration in the service catalog still covers the mailbox and license side of the tenant — identity is the lane underneath it.