Identity and Access

Separate human identity, application identity, and external-connection identity. Each has a different lifecycle and should be reviewed independently.

Human Identity

• Use the customer's approved SSO provider and tenant.
• Map roles and teams to job responsibilities, not individual exceptions.
• Restrict owner and administrator roles.
• Define onboarding, role-change, and offboarding procedures.
• Use Admin Mode only for intentional support, governance, or investigation.
• Record who can approve security, access, production, and emergency changes.

Workload Identity

Use managed identities for service-to-service access where supported. Assign separate identities to workload groups so one compromised service does not inherit unrelated permissions.

Grant the smallest required Azure roles at the narrowest practical scope. Prefer identity-based access to storage, registries, databases, monitoring, and secret stores over static access keys.

External Connection Identity

Connections to email, CRM, collaboration, advertising, or other business systems should use:

• a dedicated service account where shared production access is required,
• the minimum provider scopes,
• team-scoped sharing,
• function-level confirmation for write actions,
• a named credential owner and rotation procedure,
• provider-side logs and revocation capability.

Review application registrations, managed identities, service accounts, role assignments, dormant users, and privileged groups at an agreed cadence and after every ownership change.

See Create Teams and Assign Users and Define Access Policies.