Skip to main content
Identity and Access resources enable you to implement zero-trust security policies, control authentication methods, and manage access to your Microsoft 365 resources.

​
Resource Categories

Conditional Access

Control access based on conditions

Authentication Strength

Define authentication requirements

Named Locations

Define trusted network locations

Custom Security Attributes

Extend directory with custom attributes

​
Zero Trust Security

Implement zero-trust principles with conditional access: 
# Require MFA for all users
resource "microsoft365_graph_beta_identity_and_access_conditional_access_policy" "require_mfa" {
  display_name = "Require MFA for All Users"
  state        = "enabled"
  
  conditions = {
    users = {
      include_users = ["All"]
      exclude_groups = [
        microsoft365_graph_beta_groups_group.breakglass.id
      ]
    }
    
    applications = {
      include_applications = ["All"]
    }
  }
  
  grant_controls = {
    operator          = "OR"
    built_in_controls = ["mfa"]
  }
}

​
Common Use Cases

Enforce multi-factor authentication for all users accessing any application.
Prevent sign-ins from countries or IP ranges that aren’t part of your organization.
Only allow access from devices that meet your compliance requirements.
Require phishing-resistant authentication for privileged roles.
Limit actions users can take in cloud apps (e.g., block downloads on unmanaged devices).

​
Policy Components

​
Conditions

Define when policies apply:
  • Users: All users, specific users, groups, or roles
  • Applications: All apps, Office 365, specific apps
  • Devices: Platforms, device state, filters
  • Locations: All locations, selected networks, countries
  • Client Apps: Browser, mobile apps, legacy clients
  • Risk: Sign-in risk, user risk levels

​
Access Controls

Define what happens when conditions are met:
  • Grant: Allow, block, or require controls (MFA, compliant device, etc.)
  • Session: Control app behavior (sign-in frequency, app restrictions)

​
Policy Example

resource "microsoft365_graph_beta_identity_and_access_conditional_access_policy" "block_legacy_auth" {
  display_name = "Block Legacy Authentication"
  state        = "enabled"
  
  conditions = {
    client_app_types = [
      "exchangeActiveSync",
      "other"  # Legacy authentication protocols
    ]
    
    users = {
      include_users = ["All"]
      exclude_groups = [
        microsoft365_graph_beta_groups_group.breakglass.id
      ]
    }
    
    applications = {
      include_applications = ["All"]
    }
  }
  
  grant_controls = {
    operator          = "OR"
    built_in_controls = ["block"]
  }
}

​
Authentication Context

Define granular authentication requirements: 
resource "microsoft365_graph_beta_identity_and_access_authentication_context" "high_security" {
  display_name = "High Security Operations"
  description  = "Require phishing-resistant MFA"
  
  is_available = true
}

# Use in conditional access policy
resource "microsoft365_graph_beta_identity_and_access_conditional_access_policy" "high_security_policy" {
  display_name = "High Security Policy"
  state        = "enabled"
  
  conditions = {
    users = {
      include_users = ["All"]
    }
    
    applications = {
      include_authentication_context_class_references = [
        microsoft365_graph_beta_identity_and_access_authentication_context.high_security.id
      ]
    }
  }
  
  grant_controls = {
    operator = "OR"
    authentication_strength = {
      id = "00000000-0000-0000-0000-000000000004"  # Phishing-resistant MFA
    }
  }
}

​
Report-Only Mode

Test policies before enforcement: 
resource "microsoft365_graph_beta_identity_and_access_conditional_access_policy" "test_policy" {
  display_name = "Test Policy - Report Only"
  state        = "enabledForReportingButNotEnforced"
  
  conditions = {
    # ... conditions
  }
  
  grant_controls = {
    # ... controls
  }
}

​
Best Practices

1

Start with report-only mode

Deploy new policies in report-only mode to understand impact before enforcement.
2

Always exclude break-glass accounts

Ensure emergency access accounts are excluded from all policies to prevent lockout.
3

Use named locations for trusted networks

Define corporate networks as named locations for more precise policies.
4

Implement layered security

Combine multiple policies for defense in depth (MFA + compliant device + trusted location).
5

Monitor sign-in logs

Regularly review sign-in logs and conditional access reports to identify issues.

​
Emergency Access

Always create break-glass accounts: 
# Break-glass account group
resource "microsoft365_graph_beta_groups_group" "breakglass" {
  display_name     = "Break Glass Accounts"
  description      = "Emergency access accounts - excluded from all CA policies"
  security_enabled = true
}

# Exclude from all policies
resource "microsoft365_graph_beta_identity_and_access_conditional_access_policy" "example" {
  display_name = "Example Policy"
  
  conditions = {
    users = {
      include_users = ["All"]
      exclude_groups = [
        microsoft365_graph_beta_groups_group.breakglass.id
      ]
    }
  }
}

​
Network Filtering

Control access based on network requirements: 
resource "microsoft365_graph_beta_identity_and_access_network_filtering_policy" "branch_offices" {
  name = "Branch Office Network Policy"
  
  # Configuration
}

​
Next Steps

Conditional Access

Create conditional access policies

Authentication Strength

Define authentication requirements

Named Locations

Configure trusted locations

Security Attributes

Extend directory schema

Build docs developers (and LLMs) love

Get started for freeTalk to us