Identity-first Azure: the baseline every landing zone should start with

1. Create admin separation

   Create separate admin accounts for anyone with privileged access.

   Baseline:

   • One “normal” user identity for daily work
   • One “admin” identity for privileged actions (no email use, no browsing)

   If you use admin workstations or hardened browser profiles, apply them to admin identities first.

2. Define your admin roles (small set, least privilege)

   Start with the smallest useful set.

   Typical roles:

   • Platform Admin: owns management groups, policy, subscription vending
   • Security Admin: owns Defender/Sentinel integration and security config
   • Network Admin: owns connectivity patterns, DNS zones, firewall/vWAN config

   If you automate PIM assignments, keep the Terraform lean:

   pim-platform-admin.tf

   resource "azuread_group" "platform_admin" {
     display_name     = "alz-platform-admin"
     security_enabled = true
   }
   
   data "azuread_directory_role" "platform_admin" {
     display_name = "Privileged Role Administrator"
   }
   
   resource "azuread_privileged_role_assignment_schedule" "platform_admin" {
     principal_id         = azuread_group.platform_admin.object_id
     role_definition_id   = data.azuread_directory_role.platform_admin.template_id
     permanent_assignment = false
   
     schedule {
       type            = "Once"
       start_date_time = "2026-01-12T09:00:00Z"
       expiration {
         type     = "AfterDuration"
         duration = "PT1H"
       }
     }
   
     justification = "Platform maintenance"
   }

   Avoid giving everyone Owner. Owner is convenient, but it’s also an incident generator.

3. Enable PIM for privileged role elevation

   Set a policy that privileged roles are:

   • Eligible (not permanent)
   • Time-limited activation
   • Require MFA
   • Require justification (and optionally approval for the highest roles)

   Practical defaults:

   • 1–4 hour activation for high privilege roles
   • approval required for the most sensitive roles (your call)
4. Create and protect break-glass accounts

   Break-glass accounts exist for a scenario where Conditional Access or MFA is misconfigured and admins get locked out.

   Baseline:

   • At least 2 break-glass accounts
   • Strong passwords stored offline in a secure process
   • Exempt them from some controls carefully (or use emergency access accounts)
   • Monitor and alert on any sign-in

   Document who can use them and what “emergency” means.

5. Conditional Access baseline for admins

   Keep this practical. You can add nuance later.

   Admin baseline:

   • Require MFA for admin identities
   • Block legacy auth (if applicable)
   • Restrict admin access to trusted locations/devices (if your org can)
   • Enforce sign-in risk policies if using Identity Protection

   The goal is to reduce credential replay and opportunistic admin compromise.

6. Standardize RBAC assignments at management group scope

   Assign platform roles at the correct scope.

   Recommended:

   • Platform team roles assigned at Platform management group
   • Workload team roles assigned at subscription scope or workload MG scope

   If you assign high privilege at tenant root “just to make it work”, you will keep it forever.

7. Workload identity: prefer managed identity and federated credentials

   For apps and automation:

   • Prefer managed identities for Azure-hosted workloads
   • Prefer federated credentials (OIDC) for GitHub Actions / CI pipelines where possible
   • Avoid long-lived service principal secrets

   This drastically reduces the “credential in a pipeline” risk.

8. Secrets and keys: make them boring

   If you must store secrets:

   • Put them in Key Vault (or your chosen secret store)
   • Control access via RBAC
   • Use private connectivity if you’re operating in a private network model
   • Rotate secrets on a schedule

   The best secret is one you don’t need. The second best is one you can rotate without drama.

9. Logging and alerting for identity events

   You should treat identity events as security signals.

   Minimum:

   • alert on privileged role activation
   • alert on break-glass sign-in
   • alert on risky sign-ins (if available)
   • audit role assignment changes

   If you don’t alert on privilege changes, you’re blind to the highest-risk activity.

Success criteria for your identity baseline

• ✓

  Admins use separate admin identities for privileged work.

• ✓

  Privileged roles are eligible and activated just-in-time via PIM.

• ✓

  Break-glass accounts exist, are protected, and are monitored.

• ✓

  Conditional Access baseline is enforced for admin identities.

• ✓

  Workloads use managed identity or OIDC federation; secrets are not sitting in pipelines.

• ✓

  Role assignments are group-based and documented.