Microsoft Entra ID for Enterprise Zero Trust IAM: Conditional Access, PIM, and Cross-Cloud Federation

The Case for Zero Trust Identity with Microsoft Entra

Identity is the new perimeter. In a world where users access applications from unmanaged devices, home networks, and multiple cloud environments, the traditional network boundary has dissolved. Microsoft Entra ID sits at the center of the zero trust identity model, evaluating every authentication and authorization request against a rich set of signals: user identity, device health, location, application sensitivity, and real-time risk detection.

The zero trust principle of "never trust, always verify" requires an identity platform that can make granular access decisions in real time. Microsoft Entra ID achieves this through conditional access policies, which act as the policy engine for every authentication request. Combined with Privileged Identity Management for just-in-time elevated access, passwordless authentication via FIDO2, and cross-cloud federation to extend identity governance to AWS and GCP, Entra ID provides the comprehensive identity fabric that enterprise organizations need.

At Citadel Cloud Management, I architect identity solutions that span all three major clouds. The common pattern I see in enterprise environments is Microsoft Entra ID serving as the authoritative identity provider, with federation extending to AWS IAM Identity Center and GCP Workforce Identity Federation. This centralized model simplifies compliance, reduces credential sprawl, and creates a single audit trail for all cloud access across the organization.

This guide covers the complete implementation of a zero trust identity architecture using Microsoft Entra ID, managed through Terraform for repeatability and auditability. Every configuration change is version-controlled, peer-reviewed, and deployed through CI/CD pipelines, treating identity infrastructure with the same rigor as application code.

Entra ID vs AWS IAM Identity Center vs GCP Cloud Identity Comparison

Each major cloud provider offers its own identity and access management platform. Understanding their strengths and limitations is essential for designing a multi-cloud identity strategy. The following comparison evaluates the three platforms across key zero trust capabilities.

Microsoft Entra ID provides the most comprehensive zero trust identity capabilities across the three platforms. Its deep integration with conditional access, PIM, and Microsoft Defender creates a unified security posture that extends naturally to multi-cloud environments through federation. For organizations already invested in Microsoft 365, Entra ID is the natural choice as the authoritative identity provider for all cloud resources.

Conditional Access Policies with Terraform

Conditional access policies are the core enforcement mechanism of the zero trust identity model. Every authentication request to Entra ID is evaluated against the applicable conditional access policies, which examine signals such as user group membership, device compliance state, network location, application being accessed, and real-time risk level.

Policy Architecture for Enterprise Environments

A well-designed conditional access policy set follows a layered approach. The foundation layer blocks legacy authentication protocols that cannot enforce MFA. The baseline layer requires MFA for all users and applications. The elevated layer adds device compliance requirements for sensitive applications. The privileged layer enforces phishing-resistant authentication methods for administrative actions.

Each policy consists of assignments (who and what), conditions (when and where), and controls (grant or block). The key to manageable conditional access is using named locations for trusted networks, group-based targeting for policy scope, and report-only mode for testing before enforcement. The security infrastructure modules in my terraform-azure-security-center repository demonstrate this layered approach.

Understanding Sign-In Risk and User Risk

Entra ID Protection uses machine learning to evaluate two types of risk. Sign-in risk assesses the probability that a given authentication request was not initiated by the legitimate account owner, based on signals like impossible travel, anonymous IP addresses, and password spray patterns. User risk represents the probability that an account has been compromised, based on leaked credentials, threat intelligence, and anomalous activity patterns.

Conditional access policies can require different controls based on risk level. For medium sign-in risk, you might require MFA. For high sign-in risk, you might require a compliant device plus MFA. For high user risk, you should force a password reset and require re-registration of MFA methods. These risk-based policies create a dynamic security posture that adapts to the threat landscape without creating unnecessary friction for legitimate users.

Privileged Identity Management for Just-in-Time Access

Privileged Identity Management eliminates standing privileged access, which is one of the most significant attack surface reductions in a zero trust architecture. Instead of permanently assigning the Global Administrator or Subscription Owner role, PIM enables eligible assignments where users must explicitly activate the role for a limited time period, with MFA verification and optional approval workflows.

PIM for Azure AD Roles vs Azure Resource Roles

PIM supports two categories of privileged access. Azure AD role PIM governs directory-level operations: managing users, configuring conditional access, administering applications. Azure resource role PIM governs subscription and resource group operations: deploying infrastructure, managing Key Vaults, configuring networking. Both categories support the same activation workflow but are configured independently.

For multi-cloud environments, PIM integrates with Azure Key Vault to protect the secrets and certificates used for cross-cloud federation. When an administrator activates a privileged role to manage Key Vault secrets, the activation is logged, time-bounded, and can require approval from a security team member. This creates an auditable chain of custody for every privileged action.

Access Reviews for Continuous Compliance

PIM access reviews automate the recertification of privileged access. Configure quarterly reviews where role assignees or their managers must confirm that the access is still required. Unreconfirmed assignments are automatically revoked after the review period expires. This prevents privilege accumulation over time, a common drift pattern in organizations without automated governance. Integrating these reviews with the security baselines defined in my terraform-aws-security-baseline repository ensures consistent governance across clouds.

Passwordless Authentication and FIDO2

Passwords remain the weakest link in authentication. They are phishable, reusable across services, and frequently leaked in data breaches. Microsoft Entra ID supports multiple passwordless authentication methods that eliminate passwords entirely while improving both security and user experience.

FIDO2 Security Keys for Phishing-Resistant Authentication

FIDO2 security keys provide the strongest form of phishing-resistant authentication. The authentication ceremony uses public key cryptography bound to the specific origin (domain), making it mathematically impossible for an attacker to intercept credentials on a phishing site. Hardware keys like YubiKey 5 series support FIDO2, and credentials never leave the device.

For enterprise deployments, I recommend FIDO2 security keys for all privileged accounts and shared workstation environments. Windows Hello for Business is ideal for dedicated devices where biometric sensors are available. The Microsoft Authenticator app with phone sign-in provides a good balance of security and convenience for general workforce accounts. According to the NIST 800-63 Digital Identity Guidelines, hardware-bound authenticators like FIDO2 keys meet AAL3 (Authentication Assurance Level 3), the highest assurance level.

Cross-Cloud Federation: AWS and GCP

Cross-cloud federation enables users authenticated by Microsoft Entra ID to access AWS and GCP resources without separate credentials. This is a foundational capability for multi-cloud enterprises because it centralizes identity governance, reduces the attack surface from credential sprawl, and simplifies the user experience with single sign-on across all cloud platforms.

Federation with AWS IAM Identity Center

The federation between Entra ID and AWS uses SAML 2.0. An enterprise application in Entra ID is configured as the SAML identity provider, with AWS IAM Identity Center as the service provider. SCIM provisioning automatically syncs users and groups from Entra ID to AWS, ensuring that group membership changes in Entra ID are reflected in AWS permission set assignments within minutes.

The key architectural decision is mapping Entra ID groups to AWS permission sets. I recommend creating purpose-specific groups like AWS-Production-ReadOnly, AWS-Production-Admin, and AWS-Development-PowerUser in Entra ID, then mapping each group to the corresponding permission set in IAM Identity Center. This approach enables conditional access policies to govern AWS access based on Entra ID signals.

Federation with GCP Workforce Identity Federation

GCP Workforce Identity Federation provides a more modern OIDC-based approach compared to the SAML flow used with AWS. Configure a workforce identity pool in GCP that trusts your Entra ID tenant, then map Entra ID groups to GCP IAM roles using attribute conditions. This eliminates the need for Google Cloud Identity licenses for users who only need GCP access. The multi-cloud identity patterns are documented in my multi-cloud-landing-zone repository.

Identity Governance and Lifecycle Management

Identity governance extends zero trust beyond authentication and authorization to the full lifecycle of identity: joiner, mover, leaver. Microsoft Entra Identity Governance provides entitlement management, access reviews, and lifecycle workflows that automate identity processes aligned with HR events.

Entitlement Management with Access Packages

Access packages bundle the resources a user needs for a specific role or project: group memberships, application assignments, SharePoint sites, and cross-cloud role assignments. When a new team member joins, they request the appropriate access package, which triggers an approval workflow and provisions all required access with an expiration date. When the package expires, access is automatically revoked unless renewed through a review process.

For multi-cloud environments, access packages can include AWS permission set assignments and GCP project roles through the federation layer. A "Cloud Platform Engineer" access package might grant Entra ID roles for Azure subscription management, AWS IAM Identity Center access to production accounts, and GCP project editor roles, all provisioned and revoked as a single unit.

Lifecycle Workflows for Automated Provisioning

Lifecycle workflows trigger automated actions based on HR events sourced from systems like Workday, SAP SuccessFactors, or on-premises Active Directory. When a new employee starts, a workflow can create their Entra ID account, assign license groups, provision access packages, and send a welcome email with setup instructions. When an employee transfers departments, workflows can revoke old access and provision new access aligned with their new role. When an employee leaves, workflows disable the account, revoke all sessions, remove from groups, and archive their data within the compliance retention period.

Terraform Configuration for Entra ID Zero Trust

The following Terraform configuration demonstrates conditional access policies and PIM-related configurations for a zero trust identity deployment. This code uses the azuread provider and follows patterns from my terraform-azure-security-center module and the Microsoft Entra documentation.

# providers.tf
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    azuread = {
      source  = "hashicorp/azuread"
      version = "~> 2.47"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.90"
    }
  }
  backend "azurerm" {
    resource_group_name  = "rg-terraform-state"
    storage_account_name = "stterraformstate"
    container_name       = "tfstate"
    key                  = "entra-zero-trust.tfstate"
  }
}

provider "azuread" {}
provider "azurerm" {
  features {}
}

# Data sources
data "azuread_client_config" "current" {}

data "azuread_groups" "all_users" {
  display_names = ["All-Users"]
}

data "azuread_groups" "privileged_admins" {
  display_names = ["Privileged-Administrators"]
}

data "azuread_groups" "break_glass" {
  display_names = ["Break-Glass-Accounts"]
}

# Named location: Corporate network
resource "azuread_named_location" "corporate" {
  display_name = "Corporate Network"
  ip {
    ip_ranges = [
      "203.0.113.0/24",
      "198.51.100.0/24"
    ]
    trusted = true
  }
}

# Named location: Blocked countries
resource "azuread_named_location" "blocked_countries" {
  display_name = "Blocked Countries"
  country {
    countries_and_regions = [
      "KP", "IR", "RU", "CN"
    ]
    include_unknown_countries_and_regions = true
  }
}

# ─── Conditional Access Policy 1: Block legacy authentication ───
resource "azuread_conditional_access_policy" "block_legacy_auth" {
  display_name = "CA001 - Block Legacy Authentication"
  state        = "enabled"

  conditions {
    users {
      include_groups = data.azuread_groups.all_users.object_ids
      exclude_groups = data.azuread_groups.break_glass.object_ids
    }
    applications {
      included_applications = ["All"]
    }
    client_app_types = ["exchangeActiveSync", "other"]
  }

  grant_controls {
    operator          = "OR"
    built_in_controls = ["block"]
  }
}

# ─── Conditional Access Policy 2: Require MFA for all users ───
resource "azuread_conditional_access_policy" "require_mfa_all" {
  display_name = "CA002 - Require MFA for All Users"
  state        = "enabled"

  conditions {
    users {
      include_groups = data.azuread_groups.all_users.object_ids
      exclude_groups = data.azuread_groups.break_glass.object_ids
    }
    applications {
      included_applications = ["All"]
    }
    client_app_types = ["browser", "mobileAppsAndDesktopClients"]
    locations {
      included_locations = ["All"]
      excluded_locations = [azuread_named_location.corporate.id]
    }
  }

  grant_controls {
    operator          = "OR"
    built_in_controls = ["mfa"]
  }

  session_controls {
    sign_in_frequency        = 12
    sign_in_frequency_period = "hours"
  }
}

# ─── Conditional Access Policy 3: Block access from restricted countries ───
resource "azuread_conditional_access_policy" "block_countries" {
  display_name = "CA003 - Block Access from Restricted Countries"
  state        = "enabled"

  conditions {
    users {
      include_groups = data.azuread_groups.all_users.object_ids
      exclude_groups = data.azuread_groups.break_glass.object_ids
    }
    applications {
      included_applications = ["All"]
    }
    client_app_types = ["all"]
    locations {
      included_locations = [azuread_named_location.blocked_countries.id]
    }
  }

  grant_controls {
    operator          = "OR"
    built_in_controls = ["block"]
  }
}

# ─── Conditional Access Policy 4: Require compliant device for admin portals ───
resource "azuread_conditional_access_policy" "admin_compliant_device" {
  display_name = "CA004 - Require Compliant Device for Admin Portals"
  state        = "enabled"

  conditions {
    users {
      include_groups = data.azuread_groups.privileged_admins.object_ids
      exclude_groups = data.azuread_groups.break_glass.object_ids
    }
    applications {
      included_applications = [
        "797f4846-ba00-4fd7-ba43-dac1f8f63013", # Azure portal
        "0000000a-0000-0000-c000-000000000000"  # Entra admin center
      ]
    }
    client_app_types = ["browser", "mobileAppsAndDesktopClients"]
  }

  grant_controls {
    operator          = "AND"
    built_in_controls = ["mfa", "compliantDevice"]
  }

  session_controls {
    sign_in_frequency        = 1
    sign_in_frequency_period = "hours"
    persistent_browser_mode  = "never"
  }
}

# ─── Conditional Access Policy 5: Require phishing-resistant MFA for high risk ───
resource "azuread_conditional_access_policy" "high_risk_phishing_resistant" {
  display_name = "CA005 - Require Phishing-Resistant MFA for High Risk Sign-Ins"
  state        = "enabled"

  conditions {
    users {
      include_groups = data.azuread_groups.all_users.object_ids
      exclude_groups = data.azuread_groups.break_glass.object_ids
    }
    applications {
      included_applications = ["All"]
    }
    client_app_types = ["browser", "mobileAppsAndDesktopClients"]
    sign_in_risk_levels = ["high"]
  }

  grant_controls {
    operator = "OR"
    authentication_strength_policy_id = azuread_authentication_strength_policy.phishing_resistant.id
  }
}

# Authentication strength policy for phishing-resistant methods
resource "azuread_authentication_strength_policy" "phishing_resistant" {
  display_name = "Phishing-Resistant MFA"
  description  = "Requires FIDO2 or Windows Hello for Business"
  allowed_combinations = [
    "fido2",
    "windowsHelloForBusiness"
  ]
}

# ─── PIM Role Assignment: Global Administrator ───
resource "azurerm_role_management_policy" "global_admin" {
  scope              = "/providers/Microsoft.Management/managementGroups/root"
  role_definition_id = "62e90394-69f5-4237-9190-012177145e10" # Global Admin

  activation_rules {
    maximum_duration = "PT4H"
    require_approval = true
    require_justification = true
    require_multifactor_authentication = true
  }

  notification_rules {
    active_assignments {
      admin_notifications {
        notification_level    = "All"
        default_recipients    = true
        additional_recipients = ["security-team@company.com"]
      }
    }
    eligible_activations {
      admin_notifications {
        notification_level    = "All"
        default_recipients    = true
        additional_recipients = ["security-team@company.com"]
      }
    }
  }
}

# Outputs
output "conditional_access_policies" {
  value = {
    block_legacy    = azuread_conditional_access_policy.block_legacy_auth.id
    require_mfa     = azuread_conditional_access_policy.require_mfa_all.id
    block_countries = azuread_conditional_access_policy.block_countries.id
    admin_device    = azuread_conditional_access_policy.admin_compliant_device.id
    high_risk       = azuread_conditional_access_policy.high_risk_phishing_resistant.id
  }
}

This configuration implements a layered conditional access strategy. Policy CA001 blocks legacy protocols that cannot enforce MFA. CA002 requires MFA for all users outside the corporate network. CA003 blocks access from high-risk countries. CA004 requires both MFA and a compliant device for administrative portals. CA005 requires phishing-resistant authentication for high-risk sign-ins detected by Entra ID Protection.

The break-glass exclusion group is critical. Always exclude at least two emergency access accounts from all conditional access policies to prevent complete lockout. These accounts should use long random passwords stored in a physical safe, with monitoring alerts configured for any sign-in activity.

Best Practices for Enterprise Zero Trust IAM

Based on deploying zero trust identity architectures for organizations ranging from financial services to healthcare, these best practices consistently improve security posture while maintaining operational efficiency.

1. Start with conditional access in report-only mode. Deploy all new policies in report-only mode for at least two weeks before switching to enforcement. Analyze the sign-in logs and conditional access insights to identify legitimate users who would be blocked, then adjust policy conditions before enforcement.
2. Implement a phased passwordless rollout. Begin with privileged accounts and early adopters. Register FIDO2 security keys for all global and privileged role administrators first. Expand to IT staff and security teams. Finally, roll out passwordless to the general workforce with Microsoft Authenticator phone sign-in as the default method.
3. Enforce PIM for all privileged roles without exception. No account should have permanent assignment to Global Administrator, Privileged Role Administrator, or Security Administrator. Set maximum activation durations to 4 hours for the most sensitive roles and 8 hours for operational roles. Require approval from at least two approvers for Global Administrator activation.
4. Use named locations strategically. Define trusted corporate networks, VPN egress points, and CI/CD runner IP ranges as named locations. This allows you to create differentiated policies: require MFA everywhere but skip it on the corporate network, or require device compliance only when accessing from untrusted networks.
5. Automate access reviews on a quarterly cadence. Configure PIM access reviews for all privileged role assignments and conditional access policy exclusion groups. Set reviews to auto-remove access if the reviewer does not respond. This prevents privilege accumulation and ensures that exclusion groups do not become backdoors around security policies.
6. Deploy cross-cloud federation with attribute mapping. When federating Entra ID to AWS and GCP, use group-based attribute mapping rather than individual user claims. This scales better as the organization grows and simplifies lifecycle management since removing a user from an Entra ID group automatically revokes their cross-cloud access.
7. Monitor with Microsoft Entra audit logs and workbooks. Forward Entra ID sign-in and audit logs to a SIEM or Log Analytics workspace. Use the built-in Azure Monitor workbooks for conditional access insights, risky sign-in analysis, and PIM activation trends. Set alerts for high-risk sign-ins, PIM activations outside business hours, and conditional access policy changes.
8. Manage identity infrastructure as code with Terraform. Version control all conditional access policies, named locations, authentication strength policies, and PIM configurations in Terraform. This creates an auditable history of every identity policy change, enables peer review through pull requests, and allows rapid rollback if a policy causes unintended access issues.
9. Implement continuous access evaluation. Enable continuous access evaluation (CAE) to revoke access tokens in near real-time when critical events occur, such as user account disable, password change, or network location change. Without CAE, access tokens remain valid until their expiration time, which defaults to one hour.
10. Plan for break-glass scenarios meticulously. Maintain two cloud-only emergency access accounts excluded from all conditional access policies. Use 64+ character random passwords stored in separate physical safes. Configure Azure Monitor alerts for any sign-in to these accounts. Test the break-glass procedure quarterly to ensure it works when needed.

Frequently Asked Questions