Configure risk-based step-up consent using PowerShell
In this article, you'll learn how to configure risk-based step-up consent in Microsoft Entra ID. Risk-based step-up consent helps reduce user exposure to malicious apps that make illicit consent requests.
For example, consent requests for newly registered multitenant apps that are not publisher verified and require non-basic permissions are considered risky. If a risky user consent request is detected, the request requires a "step-up" to admin consent instead. This step-up capability is enabled by default, but it results in a behavior change only when user consent is enabled.
When a risky consent request is detected, the consent prompt displays a message that indicates that admin approval is needed. If the admin consent request workflow is enabled, the user can send the request to an admin for further review directly from the consent prompt. If the admin consent request workflow isn't enabled, the following message is displayed:
AADSTS90094: <clientAppDisplayName> needs permission to access resources in your organization that only an admin can grant. Request an admin to grant permission to this app before you can use it.
In this case, an audit event is also logged with a category of "ApplicationManagement," an activity type of "Consent to application," and a status reason of "Risky application detected."
Prerequisites
To configure risk-based step-up consent, you need:
- A user account. If you don't already have one, you can create an account for free.
- A Privileged Role Administrator.
Disable or re-enable risk-based step-up consent
You can use the Microsoft Graph PowerShell beta module to disable the step-up to admin consent that's required in cases where a risk is detected, or to enable it if it was previously disabled.
Important
Make sure you're using the Microsoft Graph PowerShell Beta cmdlets module.
Run the following command:
Install-Module Microsoft.Graph.Beta
Connect to Microsoft Graph PowerShell:
Connect-MgGraph -Scopes "Directory.ReadWrite.All"
Retrieve the current value for the Consent Policy Settings directory settings in your tenant. Doing so requires checking to see whether the directory settings for this feature have been created. If they haven't been created, use the values from the corresponding directory settings template.
$consentSettingsTemplateId = "dffd5d46-495d-40a9-8e21-954ff55e198a" # Consent Policy Settings $settings = Get-MgBetaDirectorySetting -All | Where-Object { $_.TemplateId -eq $consentSettingsTemplateId } if (-not $settings) { $params = @{ TemplateId = $consentSettingsTemplateId Values = @( @{ Name = "BlockUserConsentForRiskyApps" Value = "True" } @{ Name = "ConstrainGroupSpecificConsentToMembersOfGroupId" Value = "<groupId>" } @{ Name = "EnableAdminConsentRequests" Value = "True" } @{ Name = "EnableGroupSpecificConsent" Value = "True" } ) } $settings = New-MgBetaDirectorySetting -BodyParameter $params } $riskBasedConsentEnabledValue = $settings.Values | ? { $_.Name -eq "BlockUserConsentForRiskyApps" }
Check the value:
$riskBasedConsentEnabledValue
Understand the settings value:
Setting Type Description BlockUserConsentForRiskyApps Boolean A flag indicating whether user consent will be blocked when a risky request is detected. To change the value of
BlockUserConsentForRiskyApps
, use the Update-MgBetaDirectorySetting cmdlet.$params = @{ TemplateId = $consentSettingsTemplateId Values = @( @{ Name = "BlockUserConsentForRiskyApps" Value = "False" } @{ Name = "ConstrainGroupSpecificConsentToMembersOfGroupId" Value = "<groupId>" } @{ Name = "EnableAdminConsentRequests" Value = "True" } @{ Name = "EnableGroupSpecificConsent" Value = "True" } ) } Update-MgBetaDirectorySetting -DirectorySettingId $settings.Id -BodyParameter $params