Azure Access Management

Two different things get conflated in most identity deployments: defining the shape of access control, and actually holding or activating privileged access. The first is configuration and safe to automate. The second is a live security event and needs a human control point, not a merge button.

This section covers who and what gets access in the tenant, and how that access is granted. The rules it follows, meaning which tier each role is and how each tier is delivered, are defined in the Security Model.

Sign-in protection

• Conditional Access: the 16 policies that decide who can sign in, from where and how, plus the cutover and lockout recovery steps.
• Break-Glass Accounts: the emergency access accounts, and how they are protected, monitored and tested.
• Privileged Access Workstations: dedicated devices for Tier 0 work (a known gap).

Human access

• Guest Access: how external users are invited, restricted and removed.
• Access Packages: requestable, approved, time-limited access through Entra ID Governance — including the privileged personas (PAGs) and the read-only personas.
• Access Reviews: scheduled checks that people who hold access still need it, and what the tenant should review.

Machine access

• Platform Service Principal Vending: creating the platform team's machine identities under Lane A, and how workload identities differ.
• Workload Identity Vending: managed identities created by workload pipelines, through Lane B, within guardrails.

Other references:

• Security Model
• Role Tier Mapping: Entra ID and Azure RBAC
• Tier 0 Pipeline Design
• Tenant Root Bootstrap
• Management Group Hierarchy
• Microsoft Entra PIM documentation