Conditional Access Policies

Intune Commander provides comprehensive support for managing Entra ID Conditional Access policies and related identity governance features.

Overview

Conditional Access is Entra ID’s policy engine for controlling access to cloud apps based on signals including user, device, location, and risk. Graph Endpoint: /identity/conditionalAccess/policies
Service: ConditionalAccessPolicyService
Permissions:

Policy.ReadWrite.ConditionalAccess (read and write)
Policy.Read.All (read-only fallback)

Supported Operations

Operation	Method	Description
List	`ListAsync()`	Retrieve all Conditional Access policies
Get	`GetAsync(id)`	Retrieve a specific policy by ID

Conditional Access policy create, update, and delete operations are not currently implemented in ConditionalAccessPolicyService. The service supports read-only operations for viewing and exporting policies.

Policy Components

Each Conditional Access policy consists of:

Assignments

Define who and what the policy applies to: Users and Groups

Include/exclude users
Include/exclude groups
Include/exclude roles (directory roles)
All users, guest users, or specific identities

Cloud Apps or Actions

All cloud apps
Select specific apps (Microsoft 365, custom apps, etc.)
User actions (register security info, register or join devices)

Conditions

Sign-in risk (low, medium, high)
Device platforms (Windows, macOS, iOS, Android, Linux)
Locations (named locations, any location, trusted locations)
Client apps (browser, mobile apps and desktop clients, legacy auth)
Device state (compliant, domain-joined, hybrid joined)

Access Controls

Define what happens when policy conditions are met: Grant Controls

Block access
Grant access with requirements:
- Require multi-factor authentication
- Require device to be marked as compliant
- Require hybrid Azure AD joined device
- Require approved client app
- Require app protection policy
- Require password change
- Require authentication strength
Multiple controls (require all or require one)

Session Controls

App enforced restrictions
Conditional Access App Control
Sign-in frequency
Persistent browser session
Disable resilience defaults

Policy State

State	Description
Report-only	Policy is evaluated but not enforced; results logged for testing
Enabled	Policy is actively enforced
Disabled	Policy exists but is not evaluated

Graph API Details

GET https://graph.microsoft.com/beta/identity/conditionalAccess/policies
GET https://graph.microsoft.com/beta/identity/conditionalAccess/policies/{id}

Export/Import

Conditional Access policies export to:

ExportFolder/
└── ConditionalAccess/
    ├── Require_MFA_AllUsers.json
    ├── Block_Legacy_Auth.json
    └── Require_Compliant_Device.json

PowerPoint Export

Intune Commander can export Conditional Access policies to a comprehensive PowerPoint presentation: Usage:

Navigate to the Conditional Access category
Load CA policies
Click “Export PowerPoint” button
Choose save location
Open the generated .pptx file

Presentation Contents:

Cover slide with tenant name and export timestamp
Tenant summary with policy counts
Policy inventory table showing all policies
Detailed slides for each policy (conditions, grant controls, assignments)

Service: ConditionalAccessPptExportService
Library: Syncfusion.Presentation.Net.Core

Current Limitations (v1):

Commercial cloud only (GCC/GCC-High/DoD support planned for future release)
Basic policy details (advanced dependency lookups deferred)
Feature-level parity with idPowerToys CA decks (not pixel-perfect template matching)

Named Locations

Overview

Named locations define trusted IP address ranges or countries/regions for use in Conditional Access policies. Graph Endpoint: /identity/conditionalAccess/namedLocations
Service: NamedLocationService
Permission: Policy.ReadWrite.ConditionalAccess

Supported Operations

Operation	Method	Description
List	`ListAsync()`	Retrieve all named locations
Get	`GetAsync(id)`	Retrieve a specific location by ID
Create	`CreateAsync(location)`	Create a new named location
Update	`UpdateAsync(id, location)`	Update an existing location
Delete	`DeleteAsync(id)`	Delete a named location

Location Types

IP-Based Locations

Define trusted networks using IPv4 and IPv6 CIDR ranges:

{
  "@odata.type": "#microsoft.graph.ipNamedLocation",
  "displayName": "Corporate Network",
  "isTrusted": true,
  "ipRanges": [
    {
      "@odata.type": "#microsoft.graph.iPv4CidrRange",
      "cidrAddress": "192.168.1.0/24"
    },
    {
      "@odata.type": "#microsoft.graph.iPv6CidrRange",
      "cidrAddress": "2001:db8::/32"
    }
  ]
}

Country-Based Locations

Define locations using ISO 3166-1 alpha-2 country codes:

{
  "@odata.type": "#microsoft.graph.countryNamedLocation",
  "displayName": "Allowed Countries",
  "countriesAndRegions": ["US", "CA", "GB", "AU"],
  "includeUnknownCountriesAndRegions": false
}

Use Cases

Trusted networks - Mark office locations and VPN endpoints as trusted
Geographic restrictions - Block or allow access from specific countries
Risk-based policies - Require MFA for sign-ins from untrusted locations
Compliance requirements - Enforce regional access controls (e.g., GDPR, FedRAMP)

Graph API Details

GET https://graph.microsoft.com/beta/identity/conditionalAccess/namedLocations
GET https://graph.microsoft.com/beta/identity/conditionalAccess/namedLocations/{id}
POST https://graph.microsoft.com/beta/identity/conditionalAccess/namedLocations
PATCH https://graph.microsoft.com/beta/identity/conditionalAccess/namedLocations/{id}
DELETE https://graph.microsoft.com/beta/identity/conditionalAccess/namedLocations/{id}

Export/Import

Named locations export to:

ExportFolder/
└── NamedLocations/
    ├── Corporate_Offices.json
    └── Blocked_Countries.json

Authentication Strengths

Overview

Authentication strength policies define custom combinations of authentication methods that satisfy access requirements. Graph Endpoint: /identity/conditionalAccess/authenticationStrength/policies
Service: AuthenticationStrengthService
Permission: Policy.ReadWrite.ConditionalAccess

Supported Operations

Operation	Method	Description
List	`ListAsync()`	Retrieve all authentication strength policies
Get	`GetAsync(id)`	Retrieve a specific policy by ID
Create	`CreateAsync(policy)`	Create a new authentication strength
Update	`UpdateAsync(id, policy)`	Update an existing policy
Delete	`DeleteAsync(id)`	Delete an authentication strength

Built-In Strengths

Microsoft provides three built-in authentication strengths:

Strength	Allowed Methods	Use Case
Multifactor authentication	Any registered MFA method	General MFA requirement
Passwordless MFA	FIDO2, Windows Hello, Certificate, Microsoft Authenticator (passwordless)	High-security scenarios
Phishing-resistant MFA	FIDO2, Windows Hello, Certificate	Maximum protection against phishing

Custom Strengths

Create custom authentication strengths by selecting from available methods: Authentication Methods:

FIDO2 security key
Windows Hello for Business
Certificate-based authentication
Microsoft Authenticator (push notification)
Microsoft Authenticator (passwordless)
Temporary Access Pass
SMS (not recommended for high security)
Voice call (not recommended for high security)
Software OATH token
Hardware OATH token

Use Cases

Executive access - Require phishing-resistant MFA for privileged roles
Partner access - Define specific authentication requirements for external users
Application-specific - Different MFA requirements per app sensitivity level
Device-based - Require hardware-backed authentication on unmanaged devices
Compliance alignment - Meet specific regulatory authentication requirements

Graph API Details

GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies
GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies/{id}
POST https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies
PATCH https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies/{id}
DELETE https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies/{id}

Export/Import

Authentication strengths export to:

ExportFolder/
└── AuthenticationStrengths/
    ├── Executive_PhishResistant.json
    └── Partner_Custom_MFA.json

Authentication Contexts

Overview

Authentication context class references enable step-up authentication for accessing sensitive resources within an application. Graph Endpoint: /identity/conditionalAccess/authenticationContextClassReferences
Service: AuthenticationContextService
Permission: Policy.ReadWrite.ConditionalAccess

Supported Operations

Operation	Method	Description
List	`ListAsync()`	Retrieve all authentication contexts
Get	`GetAsync(id)`	Retrieve a specific context by ID
Create	`CreateAsync(context)`	Create a new authentication context
Update	`UpdateAsync(id, context)`	Update an existing context
Delete	`DeleteAsync(id)`	Delete an authentication context

Authentication Context Properties

ID - Unique identifier (c1-c25 for custom contexts)
Display Name - Friendly name shown to users
Description - Purpose and requirements of the context
Published - Whether the context is available for use

Application Integration

Applications tag sensitive operations with authentication context values:

App requests access to sensitive data or operation
App includes acrs claim with required authentication context ID
Entra ID evaluates Conditional Access policies tagged with that context
User completes step-up authentication if required
App grants access to sensitive operation

Use Cases

SharePoint sensitivity labels - Require MFA for highly confidential documents
Power BI datasets - Step-up auth for sensitive financial reports
Custom line-of-business apps - Different auth requirements per app function
Privileged operations - Additional verification for admin actions
Compliance workflows - Meet regulatory requirements for specific data access

Example Contexts

Context	Display Name	Use Case
c1	Require MFA	General step-up to MFA
c2	Require compliant device	Device compliance for sensitive data
c3	Require trusted network	On-premises access only
c4	High-value transactions	Financial approval workflows
c5	Privileged operations	Administrative functions

Graph API Details

GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationContextClassReferences
GET https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationContextClassReferences/{id}
POST https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationContextClassReferences
PATCH https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationContextClassReferences/{id}
DELETE https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationContextClassReferences/{id}

Export/Import

Authentication contexts export to:

ExportFolder/
└── AuthenticationContexts/
    ├── c1_Require_MFA.json
    └── c2_Compliant_Device.json

Terms of Use

Overview

Terms of Use agreements require users to accept legal terms before accessing resources. Graph Endpoint: /identityGovernance/termsOfUse/agreements
Service: TermsOfUseService
Permission: Agreement.ReadWrite.All

Supported Operations

Operation	Method	Description
List	`ListAsync()`	Retrieve all terms of use agreements
Get	`GetAsync(id)`	Retrieve a specific agreement by ID
Create	`CreateAsync(agreement)`	Create a new agreement
Update	`UpdateAsync(id, agreement)`	Update an existing agreement
Delete	`DeleteAsync(id)`	Delete an agreement

Agreement Properties

Display Name - Name shown to administrators
User Display Name - Name shown to end users
PDF Document - The actual terms of use document
Require re-acceptance - Force users to re-accept periodically
Frequency - How often users must re-accept (days)
Expires - Optional expiration date for the agreement
Per-device acceptance - Require acceptance on each device

Use Cases

Acceptable use policy - Corporate usage guidelines for all users
BYOD enrollment - Terms for personal device enrollment
Partner access - Legal terms for external collaborators
Application-specific terms - Unique terms per app or service
Regulatory compliance - Meet legal requirements for data access
Contractor onboarding - Temporary worker agreements

Conditional Access Integration

Create a Terms of Use agreement
Create a Conditional Access policy with “Require terms of use” grant control
Assign the policy to users/groups and cloud apps
Users must accept terms before accessing resources

Graph API Details

GET https://graph.microsoft.com/beta/identityGovernance/termsOfUse/agreements
GET https://graph.microsoft.com/beta/identityGovernance/termsOfUse/agreements/{id}
POST https://graph.microsoft.com/beta/identityGovernance/termsOfUse/agreements
PATCH https://graph.microsoft.com/beta/identityGovernance/termsOfUse/agreements/{id}
DELETE https://graph.microsoft.com/beta/identityGovernance/termsOfUse/agreements/{id}

Export/Import

ExportFolder/
└── TermsOfUse/
    ├── Corporate_AUP.json
    └── BYOD_Enrollment_Terms.json

The PDF document content is not included in the export. When importing to a new tenant, you must manually re-upload the PDF file.

Multi-Cloud Support

All Conditional Access and identity features are supported across cloud environments:

Cloud	Graph Base URL	Authority Host
Commercial	`https://graph.microsoft.com/beta`	`login.microsoftonline.com`
GCC	`https://graph.microsoft.com/beta`	`login.microsoftonline.com`
GCC-High	`https://graph.microsoft.us/beta`	`login.microsoftonline.us`
DoD	`https://dod-graph.microsoft.us/beta`	`login.microsoftonline.us`

PowerPoint export is currently Commercial cloud only. GCC/GCC-High/DoD support is planned for a future release.

Each cloud environment requires a separate app registration. See the cloud configuration pages for setup details.

Required Permissions

The app registration must have the following Microsoft Graph permissions:

Permission	Scope	Required For
`Policy.ReadWrite.ConditionalAccess`	Application	All Conditional Access operations
`Policy.Read.All`	Application	Read-only Conditional Access fallback
`Agreement.ReadWrite.All`	Application	Terms of Use

Best Practices

Policy Design

Start with report-only mode - Test policies before enforcement
Exclude break-glass accounts - Always exclude emergency access accounts
Layer policies - Use multiple specific policies instead of complex monolithic policies
Use named locations - Centralize network definitions for reuse
Document policy intent - Use clear display names and descriptions

Authentication Requirements

Prefer authentication strengths - Use custom strengths over broad MFA requirements
Balance security and usability - Don’t require MFA for every app if not needed
Consider device context - Managed devices may need less stringent auth
Plan for passwordless - Design policies to support modern authentication

Testing and Rollout

Use What If tool - Test policy impact before deployment
Pilot with small groups - Start with IT or early adopters
Monitor sign-in logs - Review Conditional Access successes and failures
Have rollback plan - Be prepared to disable policies if issues arise
Communicate with users - Explain why new auth requirements are being enforced

Object Types

Cloud Environments