Microsoft Entra ID security

How to list authentication contexts in Microsoft Entra ID

List authentication contexts and the policies that target them with Microsoft Graph PowerShell, check them in the Entra admin centre, or use Altivane's Conditional Access report.

By the Altivane Team Published 7 November 2026

To list authentication contexts in Microsoft Entra ID, read the tenant's authentication context class references, each with its ID, such as c1, its name and whether it is published to apps, then match them to the Conditional Access policies that target them. A context does nothing on its own: an app, a SharePoint site or a PIM role asks for it, and a policy says what it requires. Conditional Access needs Microsoft Entra ID P1.

Choose the method that fits the job
Method	Best fit
PowerShell	A CSV of every context with the policies that target it.
Admin centre	Reading 1 context, or checking which context 1 policy targets.
Altivane	Recommended for recurring reviews, with the contexts beside every policy's settings.

Before you start

Use an account in the Security Reader, Global Reader, Security Administrator or Conditional Access Administrator role, in a tenant with Microsoft Entra ID P1 for Conditional Access. The PowerShell example requests AuthenticationContext.Read.All for the contexts and Policy.Read.All for the policies; your organisation may require administrator consent.

Know where the link between them is kept. A policy that applies to a context lists the context's ID under its target resources, a property of the beta version of Microsoft Graph, so the example reads the policies with the beta module. The examples read and export; they don't change any context or policy.

Option 1

List authentication contexts with PowerShell

Install the modules once, then connect and export each context with the policies that target it and their state.

# Install once, if the modules are not already installed.
$modules = 'Microsoft.Graph.Authentication', 'Microsoft.Graph.Identity.SignIns',
    'Microsoft.Graph.Beta.Identity.SignIns'
Install-Module $modules -Scope CurrentUser

$ErrorActionPreference = 'Stop'
Connect-MgGraph -Scopes 'AuthenticationContext.Read.All', 'Policy.Read.All' -NoWelcome
try {
    $contexts = @(Get-MgIdentityConditionalAccessAuthenticationContextClassReference -All)
    # The policies' context references are documented in the beta version of Microsoft Graph.
    $policies = @(Get-MgBetaIdentityConditionalAccessPolicy -All)
    $report = @(foreach ($context in $contexts | Sort-Object Id) {
        $targeting = @($policies | Where-Object {
            $refs = $_.Conditions.Applications.IncludeAuthenticationContextClassReferences
            $refs -contains $context.Id
        })
        $names = $targeting | ForEach-Object { "$($_.DisplayName) ($($_.State))" }
        [pscustomobject]@{
            Id          = $context.Id
            Name        = $context.DisplayName
            Published   = $context.IsAvailable
            Description = $context.Description
            Policies    = @($names) -join '; '
        }
    })
    if ($report.Count -eq 0) {
        Write-Output 'The tenant has no authentication contexts.'
    } else {
        $report | Export-Csv -Path './authentication-contexts.csv' -NoTypeInformation -Encoding utf8
        $unused = @($report | Where-Object { -not $_.Policies }).Count
        Write-Output "$($report.Count) authentication contexts; no policy targets $unused."
    }
} finally {
    Disconnect-MgGraph | Out-Null
}

Published is True when the context is published to apps and ready for them to use. Policies gives each policy with its state: enabled, disabled or enabledForReportingButNotEnforced. A published context that no enabled policy targets asks nothing of anyone, so the app or site that uses it is not protected the way its owner expects.

List the contexts published to apps

Reconnect with Connect-MgGraph, then filter on isAvailable. The filter runs in Microsoft Graph.

# Run while connected to Microsoft Graph.
$filter = 'isAvailable eq true'
Get-MgIdentityConditionalAccessAuthenticationContextClassReference -Filter $filter |
    Select-Object Id, DisplayName, Description

Option 2

Review authentication contexts in the admin centre

Sign in to the Microsoft Entra admin centre as at least a Security Reader.
Go to Entra ID > Conditional Access > Authentication contexts.
Select a context to see its name, description, ID and whether Publish to apps is selected. Close it without saving.
To see which context a policy targets, go to Entra ID > Conditional Access > Policies, open the policy and read Target resources: a policy for a context shows Authentication context there.
Leave each policy without saving.

This suits reading 1 context or 1 policy. Matching every context with every policy means opening each policy in turn, so for the whole tenant, use PowerShell or a report.

Option 3 · Recommended for recurring reviews

Report on authentication contexts with Altivane

Open Altivane and choose the tenant.
Build the tenant's documents with the Conditional Access scorecard report in full, so the contexts are listed.
Open the tenant's Excel workbook and find Authentication Contexts: each context with its ID, its name, whether it is available to apps and its description.
Read Policy Overview for the contexts each policy targets, in its Applications column, and Policy Details for each policy's Authentication Contexts setting.

Altivane names each context a policy targets with its ID beside it, such as Sensitive data (c1), so the 2 tables can be read together, and Policy Overview shows each policy's state, so a context targeted only by a report-only policy stands out. Where the contexts can't be read, the table says it was not collected rather than showing none. The table goes to the workbook only by default; you can put it in the Word report too. The report needs a tenant signed in with a certificate.

Common questions

What does Publish to apps change?

It advertises the context to apps and makes it available to be assigned, such as to a SharePoint site or a sensitivity label. A context that isn't published stays available when you write Conditional Access policies, but apps and resources shouldn't use it.

Can I delete a context nobody uses?

Only once no Conditional Access policy targets it and it isn't published to apps. Before that, check the sign-in logs for sign-ins where its policy applied, since an app still using it would lose that protection.

What should a context's policy require?

Often an authentication strength, such as phishing-resistant MFA, or a compliant device. To see the strengths the tenant has and the policies that require them, see how to list authentication strengths.

Microsoft references

Technical references checked on 7 November 2026. The example scripts have been reviewed and syntax checked; they have not been run against a live tenant.