Azure identity baseline for landing zones

Why identity-first is the fastest path to “secure by default”

In Azure, identity is your control plane. If an attacker (or a rushed engineer) can get privileged identity access, all the networking controls and policy guardrails become speed bumps.

An identity baseline is not about locking people out. It’s about creating a predictable model where:

• platform admins can do platform work safely
• workload teams can ship without needing broad rights
• credentials stop living in pipelines and random scripts
• you can explain “who can do what” in 60 seconds

What good looks like

• Admin separation – every privileged user has a dedicated admin identity, MFA, and Conditional Access policies applied.
• Group-based RBAC with PIM – roles are assigned to Entra groups, not individuals, and are eligible (not permanent).
• Documented break-glass – two or more emergency accounts with phishing-resistant sign-in, monitored, validated at least every 90 days.
• Workload identity pattern – managed identities for Azure hosts, OIDC federation for CI/CD, Key Vault for secrets behind private endpoints.
• Policy + logging – Azure Policy enforcing RBAC hygiene, PIM activity logged to a central workspace, alerts hitting the SOC.

Baseline decision points

1. Scope for admin roles – Tenant root vs management group, who owns what, and which roles exist (Platform, Security, Network, Workload).
2. PIM configuration – Activation durations, approval requirements, justification text, and notifications.
3. Conditional Access baseline – MFA requirements, trusted locations, device compliance expectations, and break-glass exclusions.
4. Break-glass process – Who holds credentials, when they’re used, how they’re monitored/resets.
5. Workload identity strategy – Managed identities vs service principals, when to use OIDC federation, and how to track secrets.
6. Logging + alerting – Where PIM/Sign-in logs land, which alerts go to the SOC/platform, and how exemptions are tracked.
7. Cost/trade-offs – Entra ID P1/P2 licensing coverage and training needs for engineers.

Signal vs noise

• Enable now: Separate admin accounts, PIM eligibility, CA baseline, break-glass monitoring, managed identities for new workloads.
• Enable at Day 30: Full OIDC federation for all CI/CD, automatic revocation of unused service principals, policy enforcement of MFA for workload admins.
• Probably never: Permanent Owner at tenant root, secrets scattered in pipelines, or “MFA optional” exceptions without expiry.

Phased rollout

• Day 0 baseline – Create admin groups, PIM assignments, CA policies, break-glass accounts, and Terraform modules to manage them.
• Day 30 hardening – Enable auditing policies, convert recurring identity recommendations into Azure Policy, federate major pipelines.
• Quarterly review – Use KQL to audit PIM activations, check for direct user role assignments, validate the break-glass accounts, and review exemptions.

Runbook: identity baseline for Azure landing zones

Guardrails via Azure Policy

Enforce identity hygiene with policy initiatives. Use this Bicep skeleton to stop critical roles being assigned to individuals rather than groups. There’s no built-in definition for this, so the ID below is a custom definition you write and own. Azure Policy can’t see whether an assignment is PIM-eligible, so check PIM coverage with the queries below and PIM’s own access reviews instead.

targetScope = 'managementGroup'

// Resolve real definition IDs first, e.g.:
//   az policy definition list --query "[?contains(displayName,'<search term>')].{name:displayName,id:id}" -o table
resource initiative 'Microsoft.Authorization/policySetDefinitions@2023-04-01' = {
  name: 'identity-guardrails'
  properties: {
    displayName: 'Identity Guardrails'
    description: 'Enforce group-based RBAC.'
    policyType: 'Custom'
    policyDefinitions: [
      {
        policyDefinitionReferenceId: 'deny-user-role-assignment'
        // Custom definition: deployed at the management group, so its ID
        // looks like /providers/Microsoft.Management/managementGroups/<mg>/providers/Microsoft.Authorization/policyDefinitions/<name>
        policyDefinitionId: '<deny-user-role-assignment-id>'
      }
    ]
  }
}

resource assignment 'Microsoft.Authorization/policyAssignments@2023-04-01' = {
  name: 'identity-guardrails'
  properties: {
    displayName: 'Identity Guardrails'
    policyDefinitionId: initiative.id
  }
}

Validation checks

Use KQL to spot risky patterns. This lists directory role assignments made in the last 7 days where the principal is a user rather than a group. It needs Entra ID audit logs streaming into the workspace via a diagnostic setting.

AuditLogs
| where TimeGenerated > ago(7d)
| where Category == "RoleManagement"
| where OperationName has "Add member to role"
| mv-expand target = TargetResources
| where tostring(target.type) == "User"
| project TimeGenerated,
          InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
          TargetUser  = tostring(target.userPrincipalName),
          Changed     = target.modifiedProperties
| order by TimeGenerated desc

For Azure RBAC, the control plane that actually governs subscriptions, query the resource layer instead. This lists who created or changed role assignments in the last 7 days. It doesn’t tell you whether the assignee was a user or a group:

AzureActivity
| where TimeGenerated > ago(7d)
| where OperationNameValue =~ 'MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE'
| where ActivityStatusValue =~ 'Success'
| project TimeGenerated, Caller, SubscriptionId, ResourceId = _ResourceId
| order by TimeGenerated desc

To find the assignments that currently go straight to users, ask Azure Resource Graph, which records the principal type on each assignment:

authorizationresources
| where type =~ 'microsoft.authorization/roleassignments'
| where tostring(properties.principalType) =~ 'User'
| project principalId = tostring(properties.principalId),
          roleDefinitionId = tostring(properties.roleDefinitionId),
          scope = tostring(properties.scope)
| order by scope asc

Common pitfalls

Rollback / back-out plan

• PIM misconfiguration – revert the Terraform module, redeploy previous settings, and communicate downtime for activations.
• Conditional Access outage – disable the offending policy via the emergency account, fix offline, reapply via source control.
• Policy guardrail issue – disable the assignment (not the definition), patch parameters, pilot in a test MG, then reapply.
• Workload identity rollback – keep legacy service principal credentials for a limited overlap while OIDC rollouts complete. Document the sunset date.

For every rollback, log who executed it, why, and when the change will be resubmitted. Identity hygiene is only real when it survives change windows.