Tell us about your PDF experience.

Azure AD Identity Protection

documentation
Learn how to use Identity Protection to identify and address identity risks in your
organization

About Identity Protection

ｅ OVERVIEW

What is Identity Protection?

Introducing the security overview

Investigate risk detections

ｃ HOW-TO GUIDE

Configure risk policies

Investigate risk

ｉ REFERENCE

Types of events

Identity Protection experience

ｐ CONCEPT

Sign-in experience

ｃ HOW-TO GUIDE

Simulate Risk Detections

What is Identity Protection?
Article • 03/10/2023 • 4 minutes to read

Identity Protection allows organizations to accomplish three key tasks:

Automate the detection and remediation of identity-based risks.

Investigate risks using data in the portal.
Export risk detection data to other tools.

Identity Protection uses the learnings Microsoft has acquired from their position in
organizations with Azure Active Directory, the consumer space with Microsoft Accounts,
and in gaming with Xbox to protect your users. Microsoft analyses trillions of signals per
day to identify and protect customers from threats.

The signals generated by and fed to Identity Protection, can be further fed into tools like
Conditional Access to make access decisions, or fed back to a security information and
event management (SIEM) tool for further investigation.

Why is automation important?

In the blog post Cyber Signals: Defending against cyber threats with the latest research,
insights, and trends dated February 3, 2022 we shared a threat intelligence brief
including the following statistics:

Analyzed ...24 trillion security signals combined with intelligence we track by

monitoring more than 40 nation-state groups and over 140 threat groups...
 ...From January 2021 through December 2021, we’ve blocked more than 25.6
billion Azure AD brute force authentication attacks...

The sheer scale of signals and attacks requires some level of automation to be able to
keep up.

Detect risk
Identity Protection detects risks of many types, including:

Anonymous IP address use

Atypical travel
Malware linked IP address
Unfamiliar sign-in properties
Leaked credentials
Password spray
and more...

The risk signals can trigger remediation efforts such as requiring: perform multifactor
authentication, reset their password using self-service password reset, or block access
until an administrator takes action.

More detail on these and other risks including how or when they're calculated can be
found in the article, What is risk.

Investigate risk
Administrators can review detections and take manual action on them if needed. There
are three key reports that administrators use for investigations in Identity Protection:

Risky users
Risky sign-ins
Risk detections

More information can be found in the article, How To: Investigate risk.

Risk levels
Identity Protection categorizes risk into tiers: low, medium, and high.

Microsoft doesn't provide specific details about how risk is calculated. Each level of risk
brings higher confidence that the user or sign-in is compromised. For example,
something like one instance of unfamiliar sign-in properties for a user might not be as
threatening as leaked credentials for another user.

Make further use of risk information

Data from Identity Protection can be exported to other tools for archive and further
investigation and correlation. The Microsoft Graph based APIs allow organizations to
collect this data for further processing in a tool such as their SIEM. Information about
how to access the Identity Protection API can be found in the article, Get started with
Azure Active Directory Identity Protection and Microsoft Graph

Information about integrating Identity Protection information with Microsoft Sentinel

can be found in the article, Connect data from Azure AD Identity Protection.

Organizations can choose to store data for longer periods by changing diagnostic
settings in Azure AD. They can choose to send data to a Log Analytics workspace,
archive data to a storage account, stream data to Event Hubs, or send data to a partner
solution. Detailed information about how to do so can be found in the article, How To:
Export risk data.

Required roles
Identity Protection requires users be a Security Reader, Security Operator, Security
Administrator, Global Reader, or Global Administrator in order to access.

Role Can do Can't do

Global Full access to Identity Protection

Administrator

Security Full access to Identity Protection Reset password for a

Administrator user

Security Operator View all Identity Protection reports and Overview

Configure or change
policies

Dismiss user risk, confirm safe sign-in, confirm

compromise Reset password for a
user

Configure alerts
 Role Can do Can't do

Security Reader View all Identity Protection reports and Overview Configure or change
policies

Reset password for a

user

Configure alerts

Give feedback on
detections

Global Reader Read-only access to Identity Protection

Currently, the Security Operator role can't access the Risky sign-ins report.

Conditional Access administrators can create policies that factor in user or sign-in risk as
a condition. Find more information in the article Conditional Access: Conditions.

License requirements
Using this feature requires Azure AD Premium P2 licenses. To find the right license for
your requirements, see Compare generally available features of Azure AD .

Capability Details Azure AD Free / Azure AD Premium P1 Azure

Microsoft 365 Apps AD
Premium
P2

Risk policies Sign-in and user No No Yes

risk policies (via
Identity
Protection or
Conditional
Access)

Security Overview No No Yes

reports

Security Risky users Limited Information. Limited Information. Full

reports Only users with Only users with access
medium and high risk medium and high risk
are shown. No details are shown. No details
drawer or risk history. drawer or risk history.
 Capability Details Azure AD Free / Azure AD Premium P1 Azure
Microsoft 365 Apps AD
Premium
P2

Security Risky sign-ins Limited Information. No Limited Information. No Full

reports risk detail or risk level is risk detail or risk level is access
shown. shown.

Security Risk detections No Limited Information. No Full

reports details drawer. access

Notifications Users at risk No No Yes

detected alerts

Notifications Weekly digest No No Yes

MFA No No Yes
registration
policy

More information on these rich reports can be found in the article, How To: Investigate
risk.

Next steps
Plan an Identity Protection deployment

Additional resources
 Documentation

Azure AD Identity Protection risk-based access policies - Microsoft Entra

Identifying risk-based Conditional Access policies

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

Risk policies - Azure Active Directory Identity Protection - Microsoft Entra

Enable and configure risk policies in Azure Active Directory Identity Protection

Azure Active Directory Identity Protection security overview - Microsoft Entra

Learn how the Security overview gives you an insight into your organization’s security posture.

Risk-based user sign-in protection in Azure Active Directory - Microsoft Entra

In this tutorial, you learn how to enable Azure Identity Protection to protect users when risky sign-in
behavior is detected on their account.

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

Sign-in risk-based multifactor authentication - Azure Active Directory - Microsoft

Entra
Create Conditional Access policies using Identity Protection sign-in risk

Show 5 more

 Training

Module
Understand Microsoft 365 risk management - Training
Learn how Microsoft 365 identifies, assesses, responds to, and manages risks to protect customers
and the Microsoft 365 environment.

Certification
Microsoft Certified: Identity and Access Administrator Associate - Certifications
The Microsoft identity and access administrator designs, implements, and operates an organization’s
identity and access management systems by using Microsoft Azure Active Directory (Azure AD), part
of Microsoft Entra. They configure and manage authentication and authorization of identities for…
Azure Active Directory Identity
Protection - Security overview
Article • 08/23/2022 • 2 minutes to read

The Security overview in the Azure portal gives you an insight into your organization’s
security posture. It helps identify potential attacks and understand the effectiveness of
your policies.

The ‘Security overview’ is broadly divided into two sections:

Trends, on the left, provide a timeline of risk in your organization.

Tiles, on the right, highlight the key ongoing issues in your organization and
suggest how to quickly take action.

You can find the security overview page in the Azure portal > Azure Active Directory >
Security > Identity Protection > Overview.

Trends

New risky users detected

This chart shows the number of new risky users that were detected over the chosen time
period. You can filter the view of this chart by user risk level (low, medium, high). Hover
over the UTC date increments to see the number of risky users detected for that day.
Selecting this chart will bring you to the ‘Risky users’ report. To remediate users that are
at risk, consider changing their password.

New risky sign-ins detected

This chart shows the number of risky sign-ins detected over the chosen time period. You
can filter the view of this chart by the sign-in risk type (real-time or aggregate) and the
sign-in risk level (low, medium, high). Unprotected sign-ins are successful real-time risk
sign-ins that weren't MFA challenged. (Note: Sign-ins that are risky because of offline
detections can't be protected in real-time by sign-in risk policies). Hover over the UTC
date increments to see the number of sign-ins detected at risk for that day. Selecting
this chart will bring you to the ‘Risky sign-ins’ report.

Tiles

High risk users

The ‘High risk users’ tile shows the latest count of users with high probability of identity
compromise. These users should be a top priority for investigation. Selecting the ‘High
risk users’ tile will redirect to a filtered view of the ‘Risky users’ report showing only users
with a risk level of high. Using this report, you can learn more and remediate these users
with a password reset.
Medium risk users
The ‘Medium risk users’ tile shows the latest count of users with medium probability of
identity compromise. Selecting the ‘Medium risk users’ tile will take you to a view of the
‘Risky users’ report showing only users with a risk level of medium. Using this report,
you can further investigate and remediate these users.

Unprotected risky sign-ins

The ‘Unprotected risky sign-ins' tile shows the last week’s count of successful, real-time
risky sign-ins that weren't blocked or MFA challenged by a Conditional Access policy,
Identity Protection risk policy, or per-user MFA. These successful sign-ins are potentially
compromised and not challenged for MFA. To protect such sign-ins in future, apply a
sign-in risk policy. Selecting the ‘Unprotected risky sign-ins' tile will take you to the sign-
in risk policy configuration blade where you can configure the sign-in risk policy.

Legacy authentication
The ‘Legacy authentication’ tile shows the last week’s count of legacy authentications
with risk present in your organization. Legacy authentication protocols don't support
modern security methods such as an MFA. To prevent legacy authentication, you can
apply a Conditional Access policy. Selecting the ‘Legacy authentication’ tile will redirect
you to the ‘Identity Secure Score’.
Identity Secure Score
The Identity Secure Score measures and compares your security posture to industry
patterns. If you select the Identity Secure Score tile, it will redirect to Identity Secure
Score where you can learn more about improving your security posture.

Next steps
What is risk
Policies available to mitigate risks

Additional resources
 Documentation

Azure AD Identity Protection risk-based access policies - Microsoft Entra

Identifying risk-based Conditional Access policies

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

What is Azure Active Directory Identity Protection? - Microsoft Entra

Automation to detect, remediate, investigate, and analyze risk data with Azure AD Identity Protection

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Export and use Azure Active Directory Identity Protection data - Microsoft Entra
Learn how to investigate using long-term data in Azure Active Directory Identity Protection

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

User experiences with Azure AD Identity Protection - Microsoft Entra

User experience of Azure AD Identity Protection

Show 5 more

 Training

Module
Manage Azure AD Identity Protection - Training
Protecting a user's identity by monitoring their usage and sign-in patterns will ensure a secure cloud
solution. Explore how to design and implement Azure AD Identity protection.
What is risk?
Article • 02/16/2023 • 11 minutes to read

Risk detections in Azure AD Identity Protection include any identified suspicious actions
related to user accounts in the directory. Risk detections (both user and sign-in linked)
contribute to the overall user risk score that is found in the Risky Users report.

Identity Protection provides organizations access to powerful resources to see and

respond quickly to these suspicious actions.

７ Note

Identity Protection generates risk detections only when the correct credentials are
used. If incorrect credentials are used on a sign-in, it does not represent risk of
credential compromise.

Risk types and detection

Risk can be detected at the User and Sign-in level and two types of detection or
calculation Real-time and Offline. Some risks are considered premium available to
Azure AD Premium P2 customers only, while others are available to Free and Azure AD
Premium P1 customers.

A sign-in risk represents the probability that a given authentication request isn't
authorized by the identity owner. Risky activity can be detected for a user that isn't
linked to a specific malicious sign-in but to the user itself.

Real-time detections may not show up in reporting for 5 to 10 minutes. Offline

detections may not show up in reporting for 48 hours.

７ Note

Our system may detect that the risk event that contributed to the risk user risk
score was either:

A false positive
The user risk was remediated by policy by either:
Completing multifactor authentication
Secure password change.

Our system will dismiss the risk state and a risk detail of “AI confirmed sign-in safe”
will show and no longer contribute to the user’s overall risk.

Premium detections
Premium detections are visible only to Azure AD Premium P2 customers. Customers
without Azure AD Premium P2 licenses still receive the premium detections but they'll
be titled "additional risk detected".

Sign-in risk

Premium sign-in risk detections

Risk Detection Description

detection type
Risk Detection Description
detection type

Atypical Offline This risk detection type identifies two sign-ins originating from
travel geographically distant locations, where at least one of the locations
may also be atypical for the user, given past behavior. The algorithm
takes into account multiple factors including the time between the
two sign-ins and the time it would have taken for the user to travel
from the first location to the second. This risk may indicate that a
different user is using the same credentials.

The algorithm ignores obvious "false positives" contributing to the

impossible travel conditions, such as VPNs and locations regularly
used by other users in the organization. The system has an initial
learning period of the earliest of 14 days or 10 logins, during which it
learns a new user's sign-in behavior.

Anomalous Offline This detection indicates that there are abnormal characteristics in the
Token token such as an unusual token lifetime or a token that is played
from an unfamiliar location. This detection covers Session Tokens
and Refresh Tokens.

NOTE: Anomalous token is tuned to incur more noise than other

detections at the same risk level. This tradeoff is chosen to increase
the likelihood of detecting replayed tokens that may otherwise go
unnoticed. Because this is a high noise detection, there's a higher
than normal chance that some of the sessions flagged by this
detection are false positives. We recommend investigating the
sessions flagged by this detection in the context of other sign-ins
from the user. If the location, application, IP address, User Agent, or
other characteristics are unexpected for the user, the tenant admin
should consider this risk as an indicator of potential token replay.

Token Issuer Offline This risk detection indicates the SAML token issuer for the associated
Anomaly SAML token is potentially compromised. The claims included in the
token are unusual or match known attacker patterns.

Malware Offline This risk detection type indicates sign-ins from IP addresses infected
linked IP with malware that is known to actively communicate with a bot
address server. This detection matches the IP addresses of the user's device
against IP addresses that were in contact with a bot server while the
bot server was active.

This detection has been deprecated. Identity Protection will no

longer generate new "Malware linked IP address" detections.
Customers who currently have "Malware linked IP address"
detections in their tenant will still be able to view, remediate, or
dismiss them until the 90-day detection retention time is reached.
Risk Detection Description
detection type

Suspicious Offline Suspicious browser detection indicates anomalous behavior based

browser on suspicious sign-in activity across multiple tenants from different
countries in the same browser.

Unfamiliar Real-time This risk detection type considers past sign-in history to look for
sign-in anomalous sign-ins. The system stores information about previous
properties sign-ins, and triggers a risk detection when a sign-in occurs with
properties that are unfamiliar to the user. These properties can
include IP, ASN, location, device, browser, and tenant IP subnet.
Newly created users will be in "learning mode" period where the
unfamiliar sign-in properties risk detection will be turned off while
our algorithms learn the user's behavior. The learning mode duration
is dynamic and depends on how much time it takes the algorithm to
gather enough information about the user's sign-in patterns. The
minimum duration is five days. A user can go back into learning
mode after a long period of inactivity.

We also run this detection for basic authentication (or legacy

protocols). Because these protocols don't have modern properties
such as client ID, there's limited telemetry to reduce false positives.
We recommend our customers to move to modern authentication.

Unfamiliar sign-in properties can be detected on both interactive

and non-interactive sign-ins. When this detection is detected on
non-interactive sign-ins, it deserves increased scrutiny due to the risk
of token replay attacks.

Malicious IP Offline This detection indicates sign-in from a malicious IP address. An IP

address address is considered malicious based on high failure rates because
of invalid credentials received from the IP address or other IP
reputation sources.

Suspicious Offline This detection is discovered by Microsoft Defender for Cloud Apps.
inbox This detection looks at your environment and triggers alerts when
manipulation suspicious rules that delete or move messages or folders are set on a
rules user's inbox. This detection may indicate: a user's account is
compromised, messages are being intentionally hidden, and the
mailbox is being used to distribute spam or malware in your
organization.

Password Offline A password spray attack is where multiple usernames are attacked
spray using common passwords in a unified brute force manner to gain
unauthorized access. This risk detection is triggered when a
password spray attack has been successfully performed. For example,
the attacker is successfully authenticated, in the detected instance.
Risk Detection Description
detection type

Impossible Offline This detection is discovered by Microsoft Defender for Cloud Apps.
travel This detection identifies user activities (is a single or multiple
sessions) originating from geographically distant locations within a
time period shorter than the time it takes to travel from the first
location to the second. This risk may indicate that a different user is
using the same credentials.

New country Offline This detection is discovered by Microsoft Defender for Cloud Apps.
This detection considers past activity locations to determine new and
infrequent locations. The anomaly detection engine stores
information about previous locations used by users in the
organization.

Activity from Offline This detection is discovered by Microsoft Defender for Cloud Apps.
anonymous This detection identifies that users were active from an IP address
IP address that has been identified as an anonymous proxy IP address.

Suspicious Offline This detection is discovered by Microsoft Defender for Cloud Apps.
inbox This detection looks for suspicious email forwarding rules, for
forwarding example, if a user created an inbox rule that forwards a copy of all
emails to an external address.

Mass Access Offline This detection is discovered by Microsoft Defender for Cloud Apps.
to Sensitive This detection looks at your environment and triggers alerts when
Files users access multiple files from Microsoft SharePoint or Microsoft
OneDrive. An alert is triggered only if the number of accessed files is
uncommon for the user and the files might contain sensitive
information

Nonpremium sign-in risk detections

Risk Detection Description

detection type

Additional Real-time This detection indicates that one of the premium detections was
risk detected or Offline detected. Since the premium detections are visible only to Azure AD
Premium P2 customers, they're titled "additional risk detected" for
customers without Azure AD Premium P2 licenses.

Anonymous Real-time This risk detection type indicates sign-ins from an anonymous IP
IP address address (for example, Tor browser or anonymous VPN). These IP
addresses are typically used by actors who want to hide their sign-in
information (IP address, location, device, and so on) for potentially
malicious intent.
Risk Detection Description
detection type

Admin Offline This detection indicates an admin has selected 'Confirm user
confirmed compromised' in the Risky users UI or using riskyUsers API. To see
user which admin has confirmed this user compromised, check the user's
compromised risk history (via UI or API).

Azure AD Offline This risk detection type indicates user activity that is unusual for the
threat user or consistent with known attack patterns. This detection is
intelligence based on Microsoft's internal and external threat intelligence
sources.

User-linked detections

Premium user risk detections

Risk Detection Description

detection type

Possible Offline This risk detection type is detected by Microsoft Defender for Endpoint
attempt to (MDE). A Primary Refresh Token (PRT) is a key artifact of Azure AD
access authentication on Windows 10, Windows Server 2016, and later
Primary versions, iOS, and Android devices. A PRT is a JSON Web Token (JWT)
Refresh that's specially issued to Microsoft first-party token brokers to enable
Token single sign-on (SSO) across the applications used on those devices.
(PRT) Attackers can attempt to access this resource to move laterally into an
organization or perform credential theft. This detection will move users
to high risk and will only fire in organizations that have deployed MDE.
This detection is low-volume and will be seen infrequently by most
organizations. However, when it does occur it's high risk and users
should be remediated.

Anomalous Offline This risk detection baselines normal administrative user behavior in
user Azure AD, and spots anomalous patterns of behavior like suspicious
activity changes to the directory. The detection is triggered against the
administrator making the change or the object that was changed.

User Offline This risk detection is reported by a user who denied a multifactor
reported authentication (MFA) prompt and reported it as suspicious activity. An
suspicious MFA prompt that wasn't initiated by the user may mean that the user’s
activity credentials have been compromised.

Nonpremium user risk detections

 Risk Detection Description
detection type

Additional Real-time This detection indicates that one of the premium detections was
risk or Offline detected. Since the premium detections are visible only to Azure AD
detected Premium P2 customers, they're titled "additional risk detected" for
customers without Azure AD Premium P2 licenses.

Leaked Offline This risk detection type indicates that the user's valid credentials have
credentials been leaked. When cybercriminals compromise valid passwords of
legitimate users, they often share those credentials. This sharing is
typically done by posting publicly on the dark web, paste sites, or by
trading and selling the credentials on the black market. When the
Microsoft leaked credentials service acquires user credentials from the
dark web, paste sites, or other sources, they're checked against Azure
AD users' current valid credentials to find valid matches. For more
information about leaked credentials, see Common questions.

Azure AD Offline This risk detection type indicates user activity that is unusual for the
threat user or consistent with known attack patterns. This detection is based
intelligence on Microsoft's internal and external threat intelligence sources.

Common questions

Risk levels
Identity Protection categorizes risk into three tiers: low, medium, and high. When
configuring Identity protection policies, you can also configure it to trigger upon No risk
level. No Risk means there's no active indication that the user's identity has been
compromised.

Microsoft doesn't provide specific details about how risk is calculated. Each level of risk
brings higher confidence that the user or sign-in is compromised. For example,
something like one instance of unfamiliar sign-in properties for a user might not be as
threatening as leaked credentials for another user.

Password hash synchronization

Risk detections like leaked credentials require the presence of password hashes for
detection to occur. For more information about password hash synchronization, see the
article, Implement password hash synchronization with Azure AD Connect sync.
Why are there risk detections generated for disabled user
accounts?
Disabled user accounts can be re-enabled. If the credentials of a disabled account are
compromised, and the account gets re-enabled, bad actors might use those credentials
to gain access. Identity Protection generates risk detections for suspicious activities
against disabled user accounts to alert customers about potential account compromise.
If an account is no longer in use and wont be re-enabled, customers should consider
deleting it to prevent compromise. No risk detections are generated for deleted
accounts.

Leaked credentials

Where does Microsoft find leaked credentials?

Microsoft finds leaked credentials in various places, including:

Public paste sites such as pastebin.com and paste.ca where bad actors typically
post such material. This location is most bad actors' first stop on their hunt to find
stolen credentials.
Law enforcement agencies.
Other groups at Microsoft doing dark web research.

Why am I not seeing any leaked credentials?

Leaked credentials are processed anytime Microsoft finds a new, publicly available
batch. Because of the sensitive nature, the leaked credentials are deleted shortly after
processing. Only new leaked credentials found after you enable password hash
synchronization (PHS) will be processed against your tenant. Verifying against previously
found credential pairs isn't done.

I haven't seen any leaked credential risk events for quite some
time?
If you haven't seen any leaked credential risk events, it is because of the following
reasons:

You don't have PHS enabled for your tenant.

Microsoft has not found any leaked credential pairs that match your users.
How often does Microsoft process new credentials?
Credentials are processed immediately after they have been found, normally in multiple
batches per day.

Locations
Location in risk detections is determined by IP address lookup.

Next steps
Policies available to mitigate risks
Investigate risk
Remediate and unblock users
Security overview

Additional resources
 Documentation

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

Azure AD Identity Protection risk-based access policies - Microsoft Entra

Identifying risk-based Conditional Access policies

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

Azure Active Directory Identity Protection security overview - Microsoft Entra

Learn how the Security overview gives you an insight into your organization’s security posture.

What is Azure Active Directory Identity Protection? - Microsoft Entra

Automation to detect, remediate, investigate, and analyze risk data with Azure AD Identity Protection

Export and use Azure Active Directory Identity Protection data - Microsoft Entra
Learn how to investigate using long-term data in Azure Active Directory Identity Protection
Show 5 more
Risk-based access policies
Article • 11/16/2022 • 3 minutes to read

Access control policies can be applied to protect organizations when a sign-in or user is
detected to be at risk. Such policies are called risk-based policies.

Azure AD Conditional Access offers two risk conditions: Sign-in risk and User risk.
Organizations can create risk-based Conditional Access policies by configuring these
two risk conditions and choosing an access control method. During each sign-in,
Identity Protection sends the detected risk levels to Conditional Access, and the risk-
based policies will apply if the policy conditions are satisfied.

For example, as shown in the diagram below, if organizations have a sign-in risk policy
that requires multifactor authentication when the sign-in risk level is medium or high,
their users must complete multifactor authentication when their sign-in risk is medium
or high.
The example above also demonstrates a main benefit of a risk-based policy: automatic
risk remediation. When a user successfully completes the required access control, like a
secure password change, their risk is remediated. That sign-in session and user account
won't be at risk, and no action is needed from the administrator.

Allowing users to self-remediate using this process will significantly reduce the risk
investigation and remediation burden on the administrators while protecting your
organizations from security compromises. More information about risk remediation can
be found in the article, Remediate risks and unblock users.

Sign-in risk-based Conditional Access policy

During each sign-in, Identity Protection analyzes hundreds of signals in real-time and
calculates a sign-in risk level that represents the probability that the given
authentication request isn't authorized. This risk level then gets sent to Conditional
Access, where the organization's configured policies are evaluated. Administrators can
configure sign-in risk-based Conditional Access policies to enforce access controls
based on sign-in risk, including requirements such as:

Block access
Allow access
Require multifactor authentication

If risks are detected on a sign-in, users can perform the required access control such as
multifactor authentication to self-remediate and close the risky sign-in event to prevent
unnecessary noise for administrators.

７ Note

Users must have previously registered for Azure AD multifactor authentication

before triggering the sign-in risk policy.

User risk-based Conditional Access policy

Identity Protection analyzes signals about user accounts and calculates a risk score
based on the probability that the user has been compromised. If a user has risky sign-in
behavior, or their credentials have been leaked, Identity Protection will use these signals
to calculate the user risk level. Administrators can configure user risk-based Conditional
Access policies to enforce access controls based on user risk, including requirements
such as:

Block access
Allow access but require a secure password change.

A secure password change will remediate the user risk and close the risky user event to
prevent unnecessary noise for administrators.

Identity Protection policies

While Identity Protection also offers a user interface for creating user risk policy and
sign-in risk policy, we highly recommend that you use Azure AD Conditional Access to
create risk-based policies for the following benefits:

Rich set of conditions to control access: Conditional Access offers a rich set of
conditions such as applications and locations for configuration. The risk conditions
can be used in combination with other conditions to create policies that best
enforce your organizational requirements.
Multiple risk-based policies can be put in place to target different user groups or
apply different access control for different risk levels.
Conditional Access policies can be created through Microsoft Graph API and can
be tested first in report-only mode.
Manage all access policies in one place in Conditional Access.

If you already have Identity Protection risk policies set up, we encourage you to migrate
them to Conditional Access.

Azure AD MFA registration policy

Identity Protection can help organizations roll out Azure AD multifactor authentication
(MFA) using a policy requiring registration at sign-in. Enabling this policy is a great way
to ensure new users in your organization have registered for MFA on their first day.
Multifactor authentication is one of the self-remediation methods for risk events within
Identity Protection. Self-remediation allows your users to take action on their own to
reduce helpdesk call volume.

More information about Azure AD multifactor authentication can be found in the article,
How it works: Azure AD multifactor authentication.

Next steps
Enable Azure AD self-service password reset
Enable Azure AD multifactor authentication
Enable Azure AD multifactor authentication registration policy
Enable sign-in and user risk policies

Additional resources
 Documentation
What is risk? Azure AD Identity Protection - Microsoft Entra
Explaining risk in Azure AD Identity Protection

Azure Active Directory Identity Protection security overview - Microsoft Entra

Learn how the Security overview gives you an insight into your organization’s security posture.

What is Azure Active Directory Identity Protection? - Microsoft Entra

Automation to detect, remediate, investigate, and analyze risk data with Azure AD Identity Protection

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

User experiences with Azure AD Identity Protection - Microsoft Entra

User experience of Azure AD Identity Protection

Show 5 more

 Training

Module
Manage Azure AD Identity Protection - Training
Protecting a user's identity by monitoring their usage and sign-in patterns will ensure a secure cloud
solution. Explore how to design and implement Azure AD Identity protection.
User experiences with Azure AD Identity
Protection
Article • 02/28/2023 • 3 minutes to read

With Azure Active Directory Identity Protection, you can:

Require users to register for Azure AD multifactor authentication (MFA)

Automate remediation of risky sign-ins and compromised users

All of the Identity Protection policies have an impact on the sign in experience for users.
Allowing users to register for and use tools like Azure AD MFA and self-service password
reset can lessen the impact. These tools along with the appropriate policy choices gives
users a self-remediation option when they need it.

Multi-factor authentication registration

Enabling the Identity Protection policy requiring Azure AD Multifactor Authentication
registration and targeting all of your users, will make sure that they can use Azure AD
MFA to self-remediate in the future. Configuring this policy gives your users a 14-day
period where they can choose to register and at the end are forced to register.

Registration interrupt
1. At sign-in to any Azure AD-integrated application, the user gets a notification
about the requirement to set up the account for multifactor authentication. This
policy is also triggered in the Windows 10 Out of Box Experience for new users
with a new device.
 2. Complete the guided steps to register for Azure AD multifactor authentication and
complete your sign-in.

Risky sign-in remediation

When an administrator has configured a policy for sign-in risks, affected users are
interrupted when they hit the configured risk level.

Risky sign-in self-remediation

1. The user is informed that something unusual was detected about their sign-in. This
behavior could be something like, such as signing in from a new location, device,
or app.
 2. The user is required to prove their identity by completing Azure AD MFA with one
of their previously registered methods.

Risky sign-in administrator unblock

Administrators can choose to block users upon sign-in depending on their risk level. To
get unblocked, end users must contact their IT staff, or they can try signing in from a
familiar location or device. Self-remediation by performing multi-factor authentication
isn't an option in this case.
IT staff can follow the instructions in the section Unblocking users to allow users to sign
back in.

Risky user remediation

When a user risk policy has been configured, users who meet the user risk level
probability of compromise must go through the user compromise recovery flow before
they can sign in.

Risky user self-remediation

1. The user is informed that their account security is at risk because of suspicious
activity or leaked credentials.

2. The user is required to prove their identity by completing Azure AD MFA with one
of their previously registered methods.

3. Finally, the user is forced to change their password using self-service password
reset since someone else may have had access to their account.

Risky sign-in administrator unblock

Administrators can choose to block users upon sign-in depending on their risk level. To
get unblocked, end users must contact their IT staff. Self-remediation by performing
multifactor authentication and self-service password reset isn't an option in this case.

IT staff can follow the instructions in the section Unblocking users to allow users to sign
back in.

High risk technician

If your organization has users who are delegated access to another tenant and they
trigger high risk they may be blocked from signing into those other tenants. For
example:

1. An organization has a managed service provider (MSP) or cloud solution provider

(CSP) who takes care of configuring their cloud environment.
2. One of the MSPs technicians credentials are leaked and triggers high risk. That
technician is blocked from signing in to other tenants.
3. The technician can self-remediate and sign in if the home tenant has enabled the
appropriate policies requiring password change for high risk users or MFA for risky
users.
a. If the home tenant hasn't enabled self-remediation policies, an administrator in
the technician's home tenant will have to remediate the risk.
See also
Remediate risks and unblock users

Azure Active Directory Identity Protection

Additional resources
 Documentation

Sign-in risk-based multifactor authentication - Azure Active Directory - Microsoft

Entra
Create Conditional Access policies using Identity Protection sign-in risk

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

User risk-based password change - Azure Active Directory - Microsoft Entra

Create Conditional Access policies using Identity Protection user risk

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

Risk-based user sign-in protection in Azure Active Directory - Microsoft Entra

In this tutorial, you learn how to enable Azure Identity Protection to protect users when risky sign-in
behavior is detected on their account.

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

Show 5 more

 Training

Learning paths and modules

Manage Azure AD Identity Protection - Training
Protecting a user's identity by monitoring their usage and sign-in patterns will ensure a secure cloud
solution. Explore how to design and implement Azure AD Identity protection.
Securing workload identities
Article • 03/16/2023 • 5 minutes to read

Azure AD Identity Protection has historically protected users in detecting, investigating,

and remediating identity-based risks. We're now extending these capabilities to
workload identities to protect applications and service principals.

A workload identity is an identity that allows an application or service principal access to

resources, sometimes in the context of a user. These workload identities differ from
traditional user accounts as they:

Can’t perform multifactor authentication.

Often have no formal lifecycle process.
Need to store their credentials or secrets somewhere.

These differences make workload identities harder to manage and put them at higher
risk for compromise.

） Important

Detections are visible only to Workload Identities Premium customers.

Customers without Workload Identities Premium licenses still receive all detections
but the reporting of details is limited.

７ Note

Identity Protection detects risk on single tenant, third party SaaS, and multi-tenant
apps. Managed Identities are not currently in scope.

Prerequisites
To make use of workload identity risk, including the new Risky workload identities
blade and the Workload identity detections tab in the Risk detections blade in the
portal, you must have the following.

Workload Identities Premium licensing: You can view and acquire licenses on the
Workload Identities blade in the Azure portal.
One of the following administrator roles assigned
Global Administrator
Security Administrator
 Security Operator
Security Reader

Users assigned the Conditional Access administrator role can create policies that use risk
as a condition.

Workload identity risk detections

We detect risk on workload identities across sign-in behavior and offline indicators of
compromise.

Detection Detection Description

name type

Azure AD Offline This risk detection indicates some activity that is consistent with
threat known attack patterns based on Microsoft's internal and external
intelligence threat intelligence sources.

Suspicious Offline This risk detection indicates sign-in properties or patterns that are
Sign-ins unusual for this service principal.

The detection learns the baselines sign-in behavior for workload

identities in your tenant in between 2 and 60 days, and fires if one or
more of the following unfamiliar properties appear during a later
sign-in: IP address / ASN, target resource, user agent, hosting/non-
hosting IP change, IP country, credential type.

Because of the programmatic nature of workload identity sign-ins,

we provide a timestamp for the suspicious activity instead of
flagging a specific sign-in event.

Sign-ins that are initiated after an authorized configuration change

may trigger this detection.

Admin Offline This detection indicates an admin has selected 'Confirm

confirmed compromised' in the Risky Workload Identities UI or using
account riskyServicePrincipals API. To see which admin has confirmed this
compromised account compromised, check the account’s risk history (via UI or
API).
 Detection Detection Description
name type

Leaked Offline This risk detection indicates that the account's valid credentials have
Credentials been leaked. This leak can occur when someone checks in the
credentials in public code artifact on GitHub, or when the credentials
are leaked through a data breach.

When the Microsoft leaked credentials service acquires credentials

from GitHub, the dark web, paste sites, or other sources, they're
checked against current valid credentials in Azure AD to find valid
matches.

Malicious Offline This detection indicates that Microsoft has disabled an application
application for violating our terms of service. We recommend conducting an
investigation of the application. Note: These applications will
show DisabledDueToViolationOfServicesAgreement on the
disabledByMicrosoftStatus property on the related application and
service principal resource types in Microsoft Graph. To prevent them
from being instantiated in your organization again in the future, you
cannot delete these objects.

Suspicious Offline This detection indicates that Microsoft has identified an application
application that may be violating our terms of service, but hasn't disabled it. We
recommend conducting an investigation of the application.

Anomalous Offline This risk detection baselines normal administrative service principal
service behavior in Azure AD, and spots anomalous patterns of behavior like
principal suspicious changes to the directory. The detection is triggered
activity against the administrative service principal making the change or
the object that was changed.

Identify risky workload identities

Organizations can find workload identities that have been flagged for risk in one of two
locations:

1. Navigate to the Azure portal .

2. Browse to Azure Active Directory > Security > Risky workload identities.
3. Or browse to Azure Active Directory > Security > Risk detections.
a. Select the Workload identity detections tab.'
 

Microsoft Graph APIs

You can also query risky workload identities using the Microsoft Graph API. There are
two new collections in the Identity Protection APIs.

riskyServicePrincipals
servicePrincipalRiskDetections

Export risk data

Organizations can export data by configurating diagnostic settings in Azure AD to send
risk data to a Log Analytics workspace, archive it to a storage account, stream it to an
event hub, or send it to a SIEM solution.

Enforce access controls with risk-based

Conditional Access
Using Conditional Access for workload identities, you can block access for specific
accounts you choose when Identity Protection marks them "at risk." Policy can be
applied to single-tenant service principals that have been registered in your tenant.
Third-party SaaS, multi-tenanted apps, and managed identities are out of scope.

For improved security and resilience of your workload identities, Continuous Access
Evaluation (CAE) for workload identities is a powerful tool that offers instant
enforcement of your Conditional Access policies and any detected risk signals. CAE-
enabled third party workload identities accessing CAE-capable first party resources are
equipped with 24 hour Long Lived Tokens (LLT's) that are subject to continuous security
checks. Refer to the CAE for workload identities documentation for information on
configuring workload identity clients for CAE and up to date feature scope.

Investigate risky workload identities

Identity Protection provides organizations with two reports they can use to investigate
workload identity risk. These reports are the risky workload identities, and risk
detections for workload identities. All reports allow for downloading of events in .CSV
format for further analysis outside of the Azure portal.

Some of the key questions to answer during your investigation include:

Do accounts show suspicious sign-in activity?

Have there been unauthorized changes to the credentials?
Have there been suspicious configuration changes to accounts?
Did the account acquire unauthorized application roles?

The Azure Active Directory security operations guide for Applications provides detailed
guidance on the above investigation areas.

Once you determine if the workload identity was compromised, dismiss the account’s
risk, or confirm the account as compromised in the Risky workload identities report. You
can also select “Disable service principal” if you want to block the account from further
sign-ins.


Remediate risky workload identities
1. Inventory credentials assigned to the risky workload identity, whether for the
service principal or application objects.
2. Add a new credential. Microsoft recommends using x509 certificates.
3. Remove the compromised credentials. If you believe the account is at risk, we
recommend removing all existing credentials.
4. Remediate any Azure KeyVault secrets that the Service Principal has access to by
rotating them.

The Azure AD Toolkit is a PowerShell module that can help you perform some of these
actions.

Next steps
Conditional Access for workload identities
Microsoft Graph API
Azure AD audit logs
Azure AD sign-in logs
Simulate risk detections

Additional resources
 Documentation

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Azure Active Directory Conditional Access for workload identities - Microsoft Entra
Protecting workload identities with Conditional Access policies

What are Azure Active Directory recommendations? - Microsoft Entra

Provides a general overview of Azure Active Directory recommendations.

Azure Active Directory security operations guide - Microsoft Entra

Learn to monitor, identify, and alert on security issues with accounts, applications, devices, and
infrastructure in Azure Active Directory.
Build resilience by using Continuous Access Evaluation in Azure Active Directory -
Microsoft Entra
A guide for architects and IT administrators on using CAE

Conditional Access framework and policies - Azure Architecture Center

Get a detailed description of a recommended Conditional Access framework and a starting point for
policies.

Show 5 more

 Training

Module
Authenticate your Azure deployment workflow by using workload identities - Training
Learn how to create, manage, and grant permissions to workload identities, which enable your
deployment workflows to securely authenticate to Azure.

Certification
Microsoft Certified: Identity and Access Administrator Associate - Certifications
The Microsoft identity and access administrator designs, implements, and operates an organization’s
identity and access management systems by using Microsoft Azure Active Directory (Azure AD), part
of Microsoft Entra. They configure and manage authentication and authorization of identities for…
Identity Protection and B2B users
Article • 03/10/2023 • 5 minutes to read

Identity Protection detects compromised credentials for Azure AD users. If your

credential is detected as compromised, it means that someone else may have your
password and be using it illegitimately. To prevent further risk to your account, it's
important to securely reset your password so that the bad actor can no longer use your
compromised password. Identity Protection marks accounts that may be compromised
as "at risk."

You can use your organizational credentials to sign-in to another organization as a

guest. This process is referred to business-to-business or B2B collaboration.
Organizations can configure policies to block users from signing-in if their credentials
are considered at risk. If your account is at risk and you're blocked from signing-in to
another organization as a guest, you may be able to self-remediate your account using
the following steps. If your organization hasn't enabled self-service password reset, your
administrator will need to manually remediate your account.

How to unblock your account

If you're attempting to sign-in to another organization as a guest and are blocked due
to risk, you'll see the following block message: "Your account is blocked. We've detected
suspicious activity on your account."
If your organization enables it, you can use self-service password reset unblock your
account and get your credentials back to a safe state.

1. Go to the Password reset portal and initiate the password reset. If self-service
password reset isn't enabled for your account and you can't proceed, reach out to
your IT administrator with the information below.
2. If self-service password reset is enabled for your account, you'll be prompted to
verify your identity using security methods prior to changing your password. For
assistance, see the Reset your work or school password article.
3. Once you have successfully and securely reset your password, your user risk will be
remediated. You can now try again to sign-in as a guest user.

If after resetting your password you're still blocked as a guest due to risk, reach out to
your organization's IT administrator.

How to remediate a user's risk as an

administrator
Identity Protection automatically detects risky users for Azure AD tenants. If you haven't
previously checked the Identity Protection reports, there may be a large number of users
with risk. Since resource tenants can apply user risk policies to guest users, your users
can be blocked due to risk even if they were previously unaware of their risky state. If
your user reports they've been blocked as a guest user in another tenant due to risk, it's
important to remediate the user to protect their account and enable collaboration.

Reset the user's password

From the Risky users report in the Azure AD Security menu, search for the impacted
user using the 'User' filter. Select the impacted user in the report and select "Reset
password" in the top toolbar. The user will be assigned a temporary password that must
be changed on the next sign-in. This process will remediate their user risk and bring
their credentials back to a safe state.

Manually dismiss user's risk

If password reset isn't an option for you from the Azure portal, you can choose to
manually dismiss user risk. Dismissing user risk doesn't have any impact on the user's
existing password, but this process will change the user's Risk State from At Risk to
Dismissed. It's important that you change the user's password using whatever means are
available to you in order to bring the identity back to a safe state.

To dismiss user risk, go to the Risky users report in the Azure AD Security menu.
Search for the impacted user using the 'User' filter and select the user. Select the
"dismiss user risk" option from the top toolbar. This action may take a few minutes to
complete and update the user risk state in the report.

To learn more about Identity Protection, see What is Identity Protection.

How does Identity Protection work for B2B

users?
The user risk for B2B collaboration users is evaluated at their home directory. The real-
time sign-in risk for these users is evaluated at the resource directory when they try to
access the resource. With Azure AD B2B collaboration, organizations can enforce risk-
based policies for B2B users using Identity Protection. These policies be configured in
two ways:

Administrators can configure the built-in Identity Protection risk-based policies,

that apply to all apps, and include guest users.
 Administrators can configure their Conditional Access policies, using sign-in risk as
a condition, and includes guest users.

Limitations of Identity Protection for B2B

collaboration users
There are limitations in the implementation of Identity Protection for B2B collaboration
users in a resource directory, due to their identity existing in their home directory. The
main limitations are as follows:

If a guest user triggers the Identity Protection user risk policy to force password
reset, they will be blocked. This block is due to the inability to reset passwords in
the resource directory.
Guest users do not appear in the risky users report. This limitation is due to the
risk evaluation occurring in the B2B user's home directory.
Administrators cannot dismiss or remediate a risky B2B collaboration user in their
resource directory. This limitation is due to administrators in the resource directory
not having access to the B2B user's home directory.

Why can't I remediate risky B2B collaboration users in my

directory?
The risk evaluation and remediation for B2B users occurs in their home directory. Due to
this fact, the guest users don't appear in the risky users report in the resource directory
and admins in the resource directory can't force a secure password reset for these users.

What do I do if a B2B collaboration user was blocked due

to a risk-based policy in my organization?
If a risky B2B user in your directory is blocked by your risk-based policy, the user will
need to remediate that risk in their home directory. Users can remediate their risk by
performing a secure password reset in their home directory as outlined above. If they
don't have self-service password reset enabled in their home directory, they'll need to
contact their own organization's IT Staff to have an administrator manually dismiss their
risk or reset their password.

How do I prevent B2B collaboration users from being

impacted by risk-based policies?
Excluding B2B users from your organization's risk-based Conditional Access policies will
prevent B2B users from being impacted or blocked by their risk evaluation. To exclude
these B2B users, create a group in Azure AD that contains all of your organization's
guest users. Then, add this group as an exclusion for your built-in Identity Protection
user risk and sign-in risk policies, and any Conditional Access policies that use sign-in
risk as a condition.

Next steps
See the following articles on Azure AD B2B collaboration:

What is Azure AD B2B collaboration?

Additional resources
 Documentation

Remediate risks and unblock users in Azure AD Identity Protection - Microsoft Entra
Learn about the options you have close active risk detections.

Configure the MFA registration policy - Azure Active Directory Identity Protection -
Microsoft Entra
Learn how to configure the Azure AD Identity Protection multifactor authentication registration
policy.

Risk-based user sign-in protection in Azure Active Directory - Microsoft Entra

In this tutorial, you learn how to enable Azure Identity Protection to protect users when risky sign-in
behavior is detected on their account.

Protecting authentication methods in Azure Active Directory - Microsoft Entra

Learn about authentication features that may be enabled by default in Azure Active Directory

Combined registration for SSPR and Azure AD Multi-Factor Authentication - Azure

Active Directory - Microsoft Entra
Learn about the combined registration experience for Azure Active Directory to let users register for
both Azure AD Multi-Factor Authentication and self-service password reset

Require MFA for guest users with Conditional Access - Azure Active Directory -
Microsoft Entra
Create a custom Conditional Access policy requiring guest users perform multifactor authentication

Nudge users to set up Microsoft Authenticator - Azure Active Directory - Microsoft

Entra
Learn how to move your organization away from less secure authentication methods to Microsoft
Authenticator
Investigate risk Azure Active Directory Identity Protection - Microsoft Entra
Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

Show 5 more
Plan an Identity Protection deployment
Article • 03/10/2023 • 5 minutes to read

Azure Active Directory (Azure AD) Identity Protection detects identity-based risks,
reports them, and allows administrators to investigate and remediate these risks to keep
organizations safe and secure. The risks can be further fed into tools like Conditional
Access to make access decisions or fed back to a security information and event
management (SIEM) tool for further investigation.

This deployment plan extends concepts introduced in the Conditional Access

deployment plan.

Prerequisites
A working Azure AD tenant with Azure AD Premium P2, or trial license enabled. If
needed, create one for free .
Azure AD Premium P2 is required to include Identity Protection risk in
Conditional Access policies.
Administrators who interact with Identity Protection must have one or more of the
following role assignments depending on the tasks they're performing. To follow
 the Zero Trust principle of least privilege, consider using Privileged Identity
Management (PIM) to just-in-time activate privileged role assignments.
Read Identity Protection and Conditional Access policies and configurations
Security Reader
Global Reader
Manage Identity Protection
Security Operator
Security Administrator
Create or modify Conditional Access policies
Conditional Access Administrator
Security Administrator
A test user (non-administrator) that allows you to verify policies work as expected
before deploying to real users. If you need to create a user, see Quickstart: Add
new users to Azure Active Directory.
A group that the non-administrator user is a member of. If you need to create a
group, see Create a group and add members in Azure Active Directory.

Engage the right stakeholders

When technology projects fail, they typically do so due to mismatched expectations on
affect, outcomes, and responsibilities. To avoid these pitfalls, ensure that you’re
engaging the right stakeholders and that stakeholder roles in the project are well
understood by documenting the stakeholders, their project input, and accountability.

Communicating change
Communication is critical to the success of any new functionality. You should proactively
communicate with your users how their experience changes, when it changes, and how
to get support if they experience issues.

Step 1: Review existing reports

It's important to review the Identity Protection reports before deploying risk-based
Conditional Access policies. This review gives an opportunity to investigate existing
suspicious behavior you may have missed and to dismiss or confirm these users as safe
if you've determined they aren't at risk.

Investigate risk detections

Remediate risks and unblock users
Make bulk changes using Microsoft Graph PowerShell
For efficiency, we recommend allowing users to self-remediate through policies that are
discussed in Step 3.

Step 2: Plan for Conditional Access risk policies

Identity Protection sends risk signals to Conditional Access, to make decisions and
enforce organizational policies like requiring multifactor authentication or password
change. There are several items organizations should plan for prior to creating their
policies.

Policy exclusions
Conditional Access policies are powerful tools, we recommend excluding the following
accounts from your policies:

Emergency access or break-glass accounts to prevent tenant-wide account

lockout. In the unlikely scenario all administrators are locked out of your tenant,
your emergency-access administrative account can be used to log into the tenant
to take steps to recover access.
More information can be found in the article, Manage emergency access
accounts in Azure AD.
Service accounts and service principals, such as the Azure AD Connect Sync
Account. Service accounts are non-interactive accounts that aren't tied to any
particular user. They're normally used by back-end services allowing programmatic
access to applications, but are also used to sign in to systems for administrative
purposes. Service accounts like these should be excluded since MFA can't be
completed programmatically. Calls made by service principals aren't blocked by
Conditional Access.
If your organization has these accounts in use in scripts or code, consider
replacing them with managed identities. As a temporary workaround, you can
exclude these specific accounts from the baseline policy.

Multifactor authentication
For users to self-remediate risk though, they must register for Azure AD Multifactor
Authentication before they become risky. For more information, see the article Plan an
Azure Active Directory Multi-Factor Authentication deployment.

Known network locations

It's important to configure named locations in Conditional Access and add your VPN
ranges to Defender for Cloud Apps. Sign-ins from named locations, marked as trusted
or known, improve the accuracy of Azure AD Identity Protection risk calculations. These
sign-ins lower a user's risk when they authenticate from a location marked as trusted or
known. This practice reduces false positives for some detections in your environment.

Report only mode

Report-only mode is a Conditional Access policy state that allows administrators to
evaluate the effect of Conditional Access policies before enforcing them in their
environment.

Step 3: Configure your policies

Identity Protection MFA registration policy

Use the Identity Protection multifactor authentication registration policy to help get
your users registered for Azure AD Multifactor Authentication before they need to use it.
Follow the steps in the article How To: Configure the Azure AD multifactor
authentication registration policy to enable this policy.

Conditional Access policies

Sign-in risk - Most users have a normal behavior that can be tracked, when they fall
outside of this norm it could be risky to allow them to just sign in. You may want to
block that user or maybe just ask them to perform multi-factor authentication to prove
that they're really who they say they are. You may want to start by scoping these policies
to admins only.

User risk - Microsoft works with researchers, law enforcement, various security teams at
Microsoft, and other trusted sources to find leaked username and password pairs. When
these vulnerable users are detected, we recommend requiring users perform multifactor
authentication then reset their password.

The article Configure and enable risk policies provides guidance to create Conditional
Access policies to address these risks.

Step 4: Monitoring and continuous operational

needs
Email notifications
Enable notifications so you can respond when a user is flagged as at risk so you can
start investigating immediately. You can also set up weekly digest emails giving you an
overview of risk for that week.

Monitor and investigate

The Identity Protection workbook can help monitor and look for patterns in your tenant.
Monitor this workbook for trends and also Conditional Access Report Only mode results
to see if there are any changes that need to be made, for example, additions to named
locations.

Microsoft Defender for Cloud Apps provides an investigation framework organizations

can use as a starting point. For more information, see the article How to investigate
anomaly detection alerts.

You can also use the Identity Protection APIs to export risk information to other tools, so
your security team can monitor and alert on risk events.

During testing, you might want to simulate some threats to test your investigation
processes.

Next steps
What is risk?
Azure Active Directory Identity
Protection notifications
Article • 02/23/2023 • 4 minutes to read

Azure AD Identity Protection sends two types of automated notification emails to help
you manage user risk and risk detections:

Users at risk detected email

Weekly digest email

This article provides you with an overview of both notification emails.

７ Note

We don't support sending emails to users in group-assigned roles.

Users at risk detected email

In response to a detected account at risk, Azure AD Identity Protection generates an
email alert with Users at risk detected as subject. The email includes a link to the Users
flagged for risk report. As a best practice, you should immediately investigate the users
at risk.

The configuration for this alert allows you to specify at what user risk level you want the
alert to be generated. The email will be generated when the user's risk level reaches
what you have specified. For example, if you set the policy to alert on medium user risk
and your user John's user risk score moves to medium risk because of a real-time sign-
in risk, you'll receive the users at risk detected email. If the user has subsequent risk
detections that cause the user risk level calculation to be the specified risk level (or
higher), you'll receive more user at risk detected emails when the user risk score is
recalculated. For example, if a user moves to medium risk on January 1, you'll receive an
email notification if your settings are set to alert on medium risk. If that same user then
has another risk detection on January 5 that's also medium risk, and the user risk score
is recalculated and is still medium, you'll receive another email notification.

However, an extra email notification will only be sent if the time the risk detection
occurred (that caused the change in user risk level) is more recent than when the last
email was sent. For example, a user signs in on January 1 at 5 AM and there's no real-
time risk (meaning no email would be generated because of that sign-in). 10 minutes
later, at 5:10 AM, the same user signs-in again and has high real-time risk, causing the
user risk level to move to high and an email to be sent. Then, at 5:15 AM, the offline risk
score for the original sign-in at 5 AM changes to high risk because of offline risk
processing. Another user flagged for risk e-mail wouldn't be sent, since the time of the
first sign-in was before the second sign-in that already triggered an email notification.

To prevent an overload of e-mails, you'll only receive one email within a 5-second time
period. This delay means that if multiple users move to the specified risk level during the
same 5-second time period, we'll aggregate and send one e-mail to represent the
change in risk level for all of them.

If your organization has enabled self-remediation as described in the article, User

experiences with Azure AD Identity Protection there's a chance that the user may
remediate their risk before you have the opportunity to investigate. You can see risky
users and risky sign-ins that have been remediated by adding "Remediated" to the Risk
state filter in either the Risky users or Risky sign-ins reports.

Configure users at risk detected alerts

As an administrator, you can set:

The user risk level that triggers the generation of this email - By default, the risk
level is set to “High” risk.
The recipients of this email - Users in the Global Administrator, Security
Administrator, or Security Reader roles are automatically added to this list. We
 attempt to send emails to the first 20 members of each role. If a user is enrolled in
PIM to elevate to one of these roles on demand, then they will only receive emails
if they are elevated at the time the email is sent.
Optionally you can Add custom email here users defined must have the
appropriate permissions to view the linked reports in the Azure portal.

Configure the users at risk email in the Azure portal under Azure Active Directory >
Security > Identity Protection > Users at risk detected alerts.

Weekly digest email

The weekly digest email contains a summary of new risk detections.

It includes:

New risky users detected

New risky sign-ins detected (in real time)
Links to the related reports in Identity Protection

Users in the Global Administrator, Security Administrator, or Security Reader roles are
automatically added to this list. We attempt to send emails to the first 20 members of
each role. If a user is enrolled in PIM to elevate to one of these roles on demand, then
they will only receive emails if they are elevated at the time the email is sent

Configure weekly digest email

As an administrator, you can switch sending a weekly digest email on or off and choose
the users assigned to receive the email.

Configure the weekly digest email in the Azure portal under Azure Active Directory >
Security > Identity Protection > Weekly digest.

See also
Azure Active Directory Identity Protection

Additional resources
 Documentation

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Azure AD Identity Protection risk-based access policies - Microsoft Entra

Identifying risk-based Conditional Access policies

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

Risk-based user sign-in protection in Azure Active Directory - Microsoft Entra

In this tutorial, you learn how to enable Azure Identity Protection to protect users when risky sign-in
behavior is detected on their account.

Provide risk feedback in Azure Active Directory Identity Protection - Microsoft Entra
How and why should you provide feedback on Identity Protection risk detections.

Sign-in risk-based multifactor authentication - Azure Active Directory - Microsoft

Entra
Create Conditional Access policies using Identity Protection sign-in risk

Show 5 more

 Training

Learning paths and modules

Understand Microsoft 365 risk management - Training
Learn how Microsoft 365 identifies, assesses, responds to, and manages risks to protect customers
and the Microsoft 365 environment.
How To: Configure the Azure AD
multifactor authentication registration
policy
Article • 03/10/2023 • 2 minutes to read

Azure Active Directory (Azure AD) Identity Protection helps you manage the roll-out of
Azure AD multifactor authentication (MFA) registration by configuring a Conditional
Access policy to require MFA registration no matter what modern authentication app
you're signing in to.

What is the Azure AD multifactor

authentication registration policy?
Azure AD multifactor authentication provides a means to verify who you are using more
than just a username and password. It provides a second layer of security to user sign-
ins. In order for users to be able to respond to MFA prompts, they must first register for
Azure AD multifactor authentication.

We recommend that you require Azure AD multifactor authentication for user sign-ins
because it:

Delivers strong authentication through a range of verification options.

Plays a key role in preparing your organization to self-remediate from risk
detections in Identity Protection.

For more information on Azure AD multifactor authentication, see What is Azure AD

multifactor authentication?

Policy configuration
1. Navigate to the Azure portal .
2. Browse to Azure Active Directory > Security > Identity Protection > MFA
registration policy.
a. Under Assignments > Users
i. Under Include, select All users or Select individuals and groups if limiting
your rollout.
ii. Under Exclude, select Users and groups and choose your organization's
emergency access or break-glass accounts.
 3. Enforce Policy - On
4. Save

User experience
Azure AD Identity Protection will prompt your users to register the next time they sign in
interactively and they'll have 14 days to complete registration. During this 14-day
period, they can bypass registration if MFA isn't required as a condition, but at the end
of the period they'll be required to register before they can complete the sign-in
process.

For an overview of the related user experience, see:

Sign-in experiences with Azure AD Identity Protection.

Next steps
Enable sign-in and user risk policies
Enable Azure AD self-service password reset
Enable Azure AD multifactor authentication

Additional resources
 Documentation

Risk-based user sign-in protection in Azure Active Directory - Microsoft Entra

In this tutorial, you learn how to enable Azure Identity Protection to protect users when risky sign-in
behavior is detected on their account.

User experiences with Azure AD Identity Protection - Microsoft Entra

User experience of Azure AD Identity Protection

Sign-in risk-based multifactor authentication - Azure Active Directory - Microsoft

Entra
Create Conditional Access policies using Identity Protection sign-in risk

Control security information registration with Conditional Access - Azure Active

Directory - Microsoft Entra
Create a custom Conditional Access policy for security info registration

Overview of Azure Active Directory authentication strength (preview) - Microsoft

Entra
Learn how admins can use Azure AD Conditional Access to distinguish which authentication methods
can be used based on relevant security factors.

Require MFA for administrators with Conditional Access - Azure Active Directory -
Microsoft Entra
Create a custom Conditional Access policy to require administrators to perform multifactor
authentication

User risk-based password change - Azure Active Directory - Microsoft Entra

Create Conditional Access policies using Identity Protection user risk

How to migrate to the Authentication methods policy - Azure Active Directory

(preview) - Microsoft Entra
Learn about how to centrally manage multifactor authentication (MFA) and self-service password
reset (SSPR) settings in the Authentication methods policy.

Show 5 more

 Training

Module
Improve sign-in security with Microsoft Authenticator - Training
Improve Azure AD sign-in security by running a registration campaign to nudge users to set up
Microsoft Authenticator push notifications as their default sign-in method.

Certification
Microsoft Certified: Identity and Access Administrator Associate - Certifications
The Microsoft identity and access administrator designs, implements, and operates an organization’s
identity and access management systems by using Microsoft Azure Active Directory (Azure AD), part
of Microsoft Entra. They configure and manage authentication and authorization of identities for…
Configure and enable risk policies
Article • 02/23/2023 • 5 minutes to read

As we learned in the previous article, Risk-based access policies, there are two types of
risk policies in Azure Active Directory (Azure AD) Conditional Access you can set up to
automate the response to risks and allow users to self-remediate when risk is detected:

Sign-in risk policy

User risk policy

Choosing acceptable risk levels

Organizations must decide the level of risk they want to require access control on
balancing user experience and security posture.
Choosing to apply access control on a High risk level reduces the number of times a
policy is triggered and minimizes the impact to users. However, it excludes Low and
Medium risks from the policy, which may not block an attacker from exploiting a
compromised identity. Selecting a Low risk level to require access control introduces
more user interrupts.

Configured trusted network locations are used by Identity Protection in some risk
detections to reduce false positives.

Risk remediation
Organizations can choose to block access when risk is detected. Blocking sometimes
stops legitimate users from doing what they need to. A better solution is to allow self-
remediation using Azure AD multifactor authentication (MFA) and secure password
change.

２ Warning

Users must register for Azure AD MFA before they face a situation requiring
remediation. For hybrid users that are synced from on-premises to cloud, password
writeback must have been enabled on them. Users not registered are blocked and
require administrator intervention.

Password change (I know my password and want to change it to something new)

outside of the risky user policy remediation flow does not meet the requirement for
secure password change.

Microsoft's recommendation
Microsoft recommends the below risk policy configurations to protect your
organization:

User risk policy

Require a secure password change when user risk level is High. Azure AD MFA is
required before the user can create a new password with password writeback to
remediate their risk.
Sign-in risk policy
Require Azure AD MFA when sign-in risk level is Medium or High, allowing
users to prove it's them by using one of their registered authentication
methods, remediating the sign-in risk.
Requiring access control when risk level is low will introduce more user interrupts.
Choosing to block access rather than allowing self-remediation options, like secure
password change and multifactor authentication, will impact your users and
administrators. Weigh these choices when configuring your policies.

Exclusions
Policies allow for excluding users such as your emergency access or break-glass
administrator accounts. Organizations may need to exclude other accounts from specific
policies based on the way the accounts are used. Exclusions should be reviewed
regularly to see if they're still applicable.

Enable policies
Organizations can choose to deploy risk-based policies in Conditional Access using the
steps outlined below or using the Conditional Access templates (Preview).

Before organizations enable remediation policies, they may want to investigate and
remediate any active risks.

User risk policy in Conditional Access

1. Sign in to the Azure portal as a Conditional Access Administrator, Security
Administrator, or Global Administrator.
2. Browse to Azure Active Directory > Security > Conditional Access.
3. Select New policy.
4. Give your policy a name. We recommend that organizations create a meaningful
standard for the names of their policies.
5. Under Assignments, select Users or workload identities.
a. Under Include, select All users.
b. Under Exclude, select Users and groups and choose your organization's
emergency access or break-glass accounts.
c. Select Done.
6. Under Cloud apps or actions > Include, select All cloud apps.
7. Under Conditions > User risk, set Configure to Yes.
a. Under Configure user risk levels needed for policy to be enforced, select High.
(This guidance is based on Microsoft recommendations and may be different
for each organization)
b. Select Done.
8. Under Access controls > Grant.
 a. Select Grant access, Require multifactor authentication and Require password
change.
b. Select Select.
9. Under Session.
a. Select Sign-in frequency.
b. Ensure Every time is selected.
c. Select Select.
10. Confirm your settings and set Enable policy to Report-only.
11. Select Create to create to enable your policy.

After confirming your settings using report-only mode, an administrator can move the
Enable policy toggle from Report-only to On.

Sign-in risk policy in Conditional Access

1. Sign in to the Azure portal as a Conditional Access Administrator, Security
Administrator, or Global Administrator.
2. Browse to Azure Active Directory > Security > Conditional Access.
3. Select New policy.
4. Give your policy a name. We recommend that organizations create a meaningful
standard for the names of their policies.
5. Under Assignments, select Users or workload identities.
a. Under Include, select All users.
b. Under Exclude, select Users and groups and choose your organization's
emergency access or break-glass accounts.
c. Select Done.
6. Under Cloud apps or actions > Include, select All cloud apps.
7. Under Conditions > Sign-in risk, set Configure to Yes. Under Select the sign-in
risk level this policy will apply to. (This guidance is based on Microsoft
recommendations and may be different for each organization)
a. Select High and Medium.
b. Select Done.
8. Under Access controls > Grant.
a. Select Grant access, Require multifactor authentication.
b. Select Select.
9. Under Session.
a. Select Sign-in frequency.
b. Ensure Every time is selected.
c. Select Select.
10. Confirm your settings and set Enable policy to Report-only.
11. Select Create to create to enable your policy.
After confirming your settings using report-only mode, an administrator can move the
Enable policy toggle from Report-only to On.

Migrate risk policies from Identity Protection to

Conditional Access
While Identity Protection also provides two risk policies with limited conditions, we
highly recommend setting up risk-based policies in Conditional Access for the following
benefits:

Enhanced diagnostic data

Report-only mode integration
Graph API support
Use more Conditional Access attributes like sign-in frequency in the policy

If you already have risk policies enabled in Identity Protection, we highly recommend
that you migrate them to Conditional Access:

Migrating to Conditional Access

1. Create an equivalent user risk-based and sign-in risk-based policy in Conditional
Access in report-only mode. You can create a policy with the steps above or using
Conditional Access templates based on Microsoft's recommendations and your
organizational requirements.
a. Ensure that the new Conditional Access risk policy works as expected by testing
it in report-only mode.
 2. Enable the new Conditional Access risk policy. You can choose to have both
policies running side-by-side to confirm the new policies are working as expected
before turning off the Identity Protection risk policies.
a. Browse back to Azure Active Directory > Security > Conditional Access.
b. Select this new policy to edit it.
c. Set Enable policy to On to enable the policy
3. Disable the old risk policies in Identity Protection.
a. Browse to Azure Active Directory > Identity Protection > Select the User risk
or Sign-in risk policy.
b. Set Enforce policy to Off
4. Create other risk policies if needed in Conditional Access.

Next steps
Enable Azure AD multifactor authentication registration policy
What is risk
Investigate risk detections
Simulate risk detections
Require reauthentication every time

Additional resources
 Documentation

Risk-based user sign-in protection in Azure Active Directory - Microsoft Entra

In this tutorial, you learn how to enable Azure Identity Protection to protect users when risky sign-in
behavior is detected on their account.

What is Azure Active Directory Identity Protection? - Microsoft Entra

Automation to detect, remediate, investigate, and analyze risk data with Azure AD Identity Protection

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

Azure AD Identity Protection risk-based access policies - Microsoft Entra

Identifying risk-based Conditional Access policies

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection
Sign-in risk-based multifactor authentication - Azure Active Directory - Microsoft
Entra
Create Conditional Access policies using Identity Protection sign-in risk

What is identity secure score? - Azure Active Directory - Microsoft Entra

Learn how to use the identity secure score to improve the security posture of your directory.

Show 5 more

 Training

Learning paths and modules

Manage Azure AD Identity Protection - Training
Protecting a user's identity by monitoring their usage and sign-in patterns will ensure a secure cloud
solution. Explore how to design and implement Azure AD Identity protection.
Simulating risk detections in Identity
Protection
Article • 03/09/2023 • 5 minutes to read

Administrators may want to simulate risk in their environment in order to accomplish

the following items:

Populate data in the Identity Protection environment by simulating risk detections

and vulnerabilities.
Set up risk-based Conditional Access policies and test the impact of these policies.

This article provides you with steps for simulating the following risk detection types:

Anonymous IP address (easy)

Unfamiliar sign-in properties (moderate)
Atypical travel (difficult)
Leaked credentials in GitHub for workload identities (moderate)

Other risk detections can't be simulated in a secure manner.

More information about each risk detection can be found in the article, What is risk for
user and workload identity.

Anonymous IP address
Completing the following procedure requires you to use:

The Tor Browser to simulate anonymous IP addresses. You might need to use a
virtual machine if your organization restricts using the Tor browser.
A test account that isn't yet registered for Azure AD multifactor authentication.

To simulate a sign-in from an anonymous IP, perform the following steps:

1. Using the Tor Browser , navigate to https://myapps.microsoft.com .

2. Enter the credentials of the account you want to appear in the Sign-ins from
anonymous IP addresses report.

The sign-in shows up on the Identity Protection dashboard within 10 - 15 minutes.

Unfamiliar sign-in properties

To simulate unfamiliar locations, you have to sign in from a location and device your test
account hasn't signed in from before.

The procedure below uses a newly created:

VPN connection, to simulate new location.

Virtual machine, to simulate a new device.

Completing the following procedure requires you to use a user account that has:

At least a 30-day sign-in history.

Azure AD multifactor authentication enabled.

To simulate a sign-in from an unfamiliar location, perform the following steps:

1. When signing in with your test account, fail the multifactor authentication (MFA)
challenge by not passing the MFA challenge.
2. Using your new VPN, navigate to https://myapps.microsoft.com and enter the
credentials of your test account.

The sign-in shows up on the Identity Protection dashboard within 10 - 15 minutes.

Atypical travel
Simulating the atypical travel condition is difficult because the algorithm uses machine
learning to weed out false-positives such as atypical travel from familiar devices, or sign-
ins from VPNs that are used by other users in the directory. Additionally, the algorithm
requires a sign-in history of 14 days and 10 logins of the user before it begins
generating risk detections. Because of the complex machine learning models and above
rules, there's a chance that the following steps won't lead to a risk detection. You might
want to replicate these steps for multiple Azure AD accounts to simulate this detection.

To simulate an atypical travel risk detection, perform the following steps:

1. Using your standard browser, navigate to https://myapps.microsoft.com .

2. Enter the credentials of the account you want to generate an atypical travel risk
detection for.
3. Change your user agent. You can change user agent in Microsoft Edge from
Developer Tools (F12).
4. Change your IP address. You can change your IP address by using a VPN, a Tor
add-on, or creating a new virtual machine in Azure in a different data center.
5. Sign-in to https://myapps.microsoft.com using the same credentials as before
and within a few minutes after the previous sign-in.
The sign-in shows up in the Identity Protection dashboard within 2-4 hours.

Leaked Credentials for Workload Identities

This risk detection indicates that the application's valid credentials have been leaked.
This leak can occur when someone checks in the credentials in a public code artifact on
GitHub. Therefore, to simulate this detection, you need a GitHub account and can sign
up a GitHub account if you don't have one already.

To simulate Leaked Credentials in GitHub for Workload Identities, perform the

following steps:

1. Navigate to the Azure portal .

2. Browse to Azure Active Directory > App registrations.

3. Select New registration to register a new application or reuse an existing stale

application.

4. Select Certificates & Secrets > New client Secret , add a description of your client
secret and set an expiration for the secret or specify a custom lifetime and select
Add. Record the secret's value for later use for your GitHub Commit.

７ Note

You can not retrieve the secret again after you leave this page.

5. Get the TenantID and Application(Client)ID in the Overview page.

6. Ensure you disable the application via Azure Active Directory > Enterprise
Application > Properties > Set Enabled for users to sign-in to No.

7. Create a public GitHub Repository, add the following config and commit the
change as a file with the .txt extension.

GitHub

"AadClientId": "XXXX-2dd4-4645-98c2-960cf76a4357",

"AadSecret": "p3n7Q~XXXX",

"AadTenantDomain": "XXXX.onmicrosoft.com",

"AadTenantId": "99d4947b-XXX-XXXX-9ace-abceab54bcd4",

8. In about 8 hours, you'll be able to view a leaked credential detection under Azure
Active Directory > Security > Risk Detection > Workload identity detections
 where the additional info will contain the URL of your GitHub commit.

Testing risk policies

This section provides you with steps for testing the user and the sign-in risk policies
created in the article, How To: Configure and enable risk policies.

User risk policy

To test a user risk security policy, perform the following steps:

1. Navigate to the Azure portal .

2. Browse to Azure Active Directory > Security > Identity Protection > Overview.
3. Select Configure user risk policy.
a. Under Assignments
i. Users - Choose All users or Select individuals and groups if limiting your
rollout.
i. Optionally you can choose to exclude users from the policy.
ii. Conditions - User risk Microsoft's recommendation is to set this option to
High.
b. Under Controls
i. Access - Microsoft's recommendation is to Allow access and Require
password change.
c. Enforce Policy - Off
d. Save - This action will return you to the Overview page.
4. Elevate the user risk of a test account by, for example, simulating one of the risk
detections a few times.
5. Wait a few minutes, and then verify that risk has elevated for your user. If not,
simulate more risk detections for the user.
6. Return to your risk policy and set Enforce Policy to On and Save your policy
change.
7. You can now test user risk-based Conditional Access by signing in using a user
with an elevated risk level.

Sign-in risk security policy

To test a sign-in risk policy, perform the following steps:

1. Navigate to the Azure portal .

2. Browse to Azure Active Directory > Security > Identity Protection > Overview.
3. Select Configure sign-in risk policy.
 a. Under Assignments
i. Users - Choose All users or Select individuals and groups if limiting your
rollout.
i. Optionally you can choose to exclude users from the policy.
ii. Conditions - Sign-in risk Microsoft's recommendation is to set this option to
Medium and above.
b. Under Controls
i. Access - Microsoft's recommendation is to Allow access and Require
multifactor authentication.
c. Enforce Policy - On
d. Save - This action will return you to the Overview page.
4. You can now test Sign-in Risk-based Conditional Access by signing in using a risky
session (for example, by using the Tor browser).

Next steps
What is risk?

Securing workload identities with Identity

How To: Configure and enable risk policies

Azure Active Directory Identity Protection

Additional resources
 Documentation

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

Provide risk feedback in Azure Active Directory Identity Protection - Microsoft Entra
How and why should you provide feedback on Identity Protection risk detections.

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection
Export and use Azure Active Directory Identity Protection data - Microsoft Entra
Learn how to investigate using long-term data in Azure Active Directory Identity Protection

Azure AD Identity Protection risk-based access policies - Microsoft Entra

Identifying risk-based Conditional Access policies

User experiences with Azure AD Identity Protection - Microsoft Entra

User experience of Azure AD Identity Protection

Show 5 more
How To: Investigate risk
Article • 11/16/2022 • 4 minutes to read

Identity Protection provides organizations with three reports they can use to investigate
identity risks in their environment. These reports are the risky users, risky sign-ins, and
risk detections. Investigation of events is key to better understanding and identifying
any weak points in your security strategy.

All three reports allow for downloading of events in .CSV format for further analysis
outside of the Azure portal. The risky users and risky sign-ins reports allow for
downloading the most recent 2500 entries, while the risk detections report allows for
downloading the most recent 5000 records.

Organizations can take advantage of the Microsoft Graph API integrations to aggregate
data with other sources they may have access to as an organization.

The three reports are found in the Azure portal > Azure Active Directory > Security.

Navigating the reports

Each report launches with a list of all detections for the period shown at the top of the
report. Each report allows for the addition or removal of columns based on
administrator preference. Administrators can choose to download the data in .CSV or
.JSON format. Reports can be filtered using the filters across the top of the report.

Selecting individual entries may enable more entries at the top of the report such as the
ability to confirm a sign-in as compromised or safe, confirm a user as compromised, or
dismiss user risk.

Selecting individual entries expands a details window below the detections. The details
view allows administrators to investigate and take action on each detection.

Risky users
 

With the information provided by the risky users report, administrators can find:

Which users are at risk, have had risk remediated, or have had risk dismissed?
Details about detections
History of all risky sign-ins
Risk history

Administrators can then choose to take action on these events. Administrators can
choose to:

Reset the user password

Confirm user compromise
Dismiss user risk
Block user from signing in
Investigate further using Azure ATP

Risky sign-ins
 

The risky sign-ins report contains filterable data for up to the past 30 days (one month).

With the information provided by the risky sign-ins report, administrators can find:

Which sign-ins are classified as at risk, confirmed compromised, confirmed safe,

dismissed, or remediated.
Real-time and aggregate risk levels associated with sign-in attempts.
Detection types triggered
Conditional Access policies applied
MFA details
Device information
Application information
Location information

Administrators can then choose to take action on these events. Administrators can
choose to:

Confirm sign-in compromise

Confirm sign-in safe

７ Note

Identity Protection evaluates risk for all authentication flows, whether it be

interactive or non-interactive. The risky sign-in report now shows both interactive
and non-interactive sign-ins. Use the "sign-in type" filter to modify this view.
Risk detections

The risk detections report contains filterable data for up to the past 90 days (three
months).

With the information provided by the risk detections report, administrators can find:

Information about each risk detection including type.

Other risks triggered at the same time
Sign-in attempt location
Link out to more detail from Microsoft Defender for Cloud Apps.

Administrators can then choose to return to the user's risk or sign-ins report to take
actions based on information gathered.

７ Note

Our system may detect that the risk event that contributed to the risk user risk
score was a false positives or the user risk was remediated with policy enforcement
such as completing an MFA prompt or secure password change. Therefore our
system will dismiss the risk state and a risk detail of “AI confirmed sign-in safe” will
surface and it will no longer contribute to the user’s risk.

Investigation framework
Organizations may use the following frameworks to begin their investigation into any
suspicious activity. Investigations may require having a conversation with the user in
question, review of the sign-in logs, or review of the audit logs to name a few.

1. Check the logs and validate whether the suspicious activity is normal for the given
user.
a. Look at the user’s past activities including at least the following properties to
see if they're normal for the given user.
i. Application
ii. Device - Is the device registered or compliant?
iii. Location - Is the user traveling to a different location or accessing devices
from multiple locations?
iv. IP address
v. User agent string
b. If you have access to other security tools like Microsoft Sentinel, check for
corresponding alerts that might indicate a larger issue.
2. Reach out to the user to confirm if they recognize the sign-in. Methods such as
email or Teams may be compromised.
a. Confirm the information you have such as:
i. Application
ii. Device
iii. Location
iv. IP address

Investigate Azure AD threat intelligence detections

To investigate an Azure AD Threat Intelligence risk detection, follow these steps:

If more information is shown for the detection:

1. Sign-in was from a suspicious IP Address:

a. Confirm if the IP address shows suspicious behavior in your environment.
b. Does the IP generate a high number of failures for a user or set of users in your
directory?
c. Is the traffic of the IP coming from an unexpected protocol or application, for
example Exchange legacy protocols?
d. If the IP address corresponds to a cloud service provider, rule out that there are
no legitimate enterprise applications running from the same IP.
2. This account was attacked by a Password spray:
a. Validate that no other users in your directory are targets of the same attack.
b. Do other users have sign-ins with similar atypical patterns seen in the detected
sign-in within the same time frame? Password spray attacks may display unusual
 patterns in:
i. User agent string
ii. Application
iii. Protocol
iv. Ranges of IPs/ASNs
v. Time and frequency of sign-ins

Next steps
Remediate and unblock users

Policies available to mitigate risks

Enable sign-in and user risk policies

Additional resources
 Documentation

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Risk-based user sign-in protection in Azure Active Directory - Microsoft Entra

In this tutorial, you learn how to enable Azure Identity Protection to protect users when risky sign-in
behavior is detected on their account.

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

Provide risk feedback in Azure Active Directory Identity Protection - Microsoft Entra
How and why should you provide feedback on Identity Protection risk detections.

Risk policies - Azure Active Directory Identity Protection - Microsoft Entra

Enable and configure risk policies in Azure Active Directory Identity Protection

Azure AD Identity Protection risk-based access policies - Microsoft Entra

Identifying risk-based Conditional Access policies

Show 5 more
Remediate risks and unblock users
Article • 02/28/2023 • 6 minutes to read

After completing your investigation, you need to take action to remediate the risky users
or unblock them. Organizations can enable automated remediation by setting up risk-
based policies. Organizations should try to investigate and remediate all risky users in a
time period that your organization is comfortable with. Microsoft recommends acting
quickly, because time matters when working with risks.

Risk remediation
All active risk detections contribute to the calculation of the user's risk level. The user
risk level is an indicator (low, medium, high) of the probability that the user's account
has been compromised. As an administrator, after thorough investigation on the risky
users and the corresponding risky sign-ins and detections, you want to remediate the
risky users so that they're no longer at risk and won't be blocked.

Some risk detections and the corresponding risky sign-ins may be marked by Identity
Protection as dismissed with risk state "Dismissed" and risk detail "Azure AD Identity
Protection assessed sign-in safe" because those events were no longer determined to
be risky.

Administrators have the following options to remediate:

Set up risk-based policies to allow users to self-remediate their risks

Manual password reset
Dismiss user risk

Self-remediation with risk-based policy

You can allow users to self-remediate their sign-in risks and user risks by setting up risk-
based policies. If users pass the required access control, such as Azure AD multifactor
authentication (MFA) or secure password change, then their risks are automatically
remediated. The corresponding risk detections, risky sign-ins, and risky users will be
reported with the risk state "Remediated" instead of "At risk".

Here are the prerequisites on users before risk-based policies can be applied to them to
allow self-remediation of risks:

To perform MFA to self-remediate a sign-in risk:

The user must have registered for Azure AD MFA.
 To perform secure password change to self-remediate a user risk:
The user must have registered for Azure AD MFA.
For hybrid users that are synced from on-premises to cloud, password writeback
must have been enabled on them.

If a risk-based policy is applied to a user during sign-in before the above prerequisites
are met, then the user will be blocked because they aren't able to perform the required
access control, and admin intervention will be required to unblock the user.

Risk-based policies are configured based on risk levels and will only apply if the risk
level of the sign-in or user matches the configured level. Some detections may not raise
risk to the level where the policy will apply, and administrators will need to handle those
risky users manually. Administrators may determine that extra measures are necessary
like blocking access from locations or lowering the acceptable risk in their policies.

Self-remediation with self-service password reset

If a user has registered for self-service password reset (SSPR), then they can also
remediate their own user risk by performing a self-service password reset.

Manual password reset

If requiring a password reset using a user risk policy isn't an option, administrators can
remediate a risky user by requiring a password reset.

Administrators are given two options when resetting a password for their users:

Generate a temporary password - By generating a temporary password, you can

immediately bring an identity back into a safe state. This method requires
contacting the affected users because they need to know what the temporary
password is. Because the password is temporary, the user is prompted to change
the password to something new during the next sign-in.

Require the user to reset password - Requiring the users to reset passwords
enables self-recovery without contacting help desk or an administrator. This
method only applies to users that are registered for Azure AD MFA and SSPR. For
users that haven't been registered, this option isn't available.

Dismiss user risk

If after investigation and confirming that the user account isn't at risk of being
compromised, then you can choose to dismiss the risky user.
To Dismiss user risk, search for and select Azure AD Risky users in the Azure portal or
the Entra portal, select the affected user, and select Dismiss user(s) risk.

When you select Dismiss user risk, the user will no longer be at risk, and all the risky
sign-ins of this user and corresponding risk detections will be dismissed as well.

Because this method doesn't have an impact on the user's existing password, it doesn't
bring their identity back into a safe state.

Risk state and detail based on dismissal of risk

Risky user:
Risk state: "At risk" -> "Dismissed"
Risk detail (the risk remediation detail): "-" -> "Admin dismissed all risk for user"
All the risky sign-ins of this user and the corresponding risk detections:
Risk state: "At risk" -> "Dismissed"
Risk detail (the risk remediation detail): "-" -> "Admin dismissed all risk for user"

Confirm a user to be compromised

If after investigation, an account is confirmed compromised:

1. Select the event or user in the Risky sign-ins or Risky users reports and choose
"Confirm compromised".
2. If a risk-based policy wasn't triggered, and the risk wasn't self-remediated, then do
one or more of the followings:
a. Request a password reset.
b. Block the user if you suspect the attacker can reset the password or do
multifactor authentication for the user.
c. Revoke refresh tokens.
d. Disable any devices that are considered compromised.
e. If using continuous access evaluation, revoke all access tokens.

For more information about what happens when confirming compromise, see the
section How should I give risk feedback and what happens under the hood?.

Deleted users
It isn't possible for administrators to dismiss risk for users who have been deleted from
the directory. To remove deleted users, open a Microsoft support case.
Unblocking users
An administrator may choose to block a sign-in based on their risk policy or
investigations. A block may occur based on either sign-in or user risk.

Unblocking based on user risk

To unblock an account blocked because of user risk, administrators have the following
options:

1. Reset password - You can reset the user's password. If a user has been
compromised or is at risk of being compromised, the user's password should be
reset to protect their account and your organization.
2. Dismiss user risk - The user risk policy blocks a user if the configured user risk level
for blocking access has been reached. If after investigation you're confident that
the user isn't at risk of being compromised, and it's safe to allow their access, then
you can reduce a user's risk level by dismissing their user risk.
3. Exclude the user from policy - If you think that the current configuration of your
sign-in policy is causing issues for specific users, and it's safe to grant access to
these users without applying this policy to them, then you can exclude them from
this policy. For more information, see the section Exclusions in the article How To:
Configure and enable risk policies.
4. Disable policy - If you think that your policy configuration is causing issues for all
your users, you can disable the policy. For more information, see the article How
To: Configure and enable risk policies.

Unblocking based on sign-in risk

To unblock an account based on sign-in risk, administrators have the following options:

1. Sign in from a familiar location or device - A common reason for blocked

suspicious sign-ins are sign-in attempts from unfamiliar locations or devices. Your
users can quickly determine whether this reason is the blocking reason by trying to
sign-in from a familiar location or device.
2. Exclude the user from policy - If you think that the current configuration of your
sign-in policy is causing issues for specific users, you can exclude the users from it.
For more information, see the section Exclusions in the article How To: Configure
and enable risk policies.
3. Disable policy - If you think that your policy configuration is causing issues for all
your users, you can disable the policy. For more information, see the article How
To: Configure and enable risk policies.
PowerShell preview
Using the Microsoft Graph PowerShell SDK Preview module, organizations can manage
risk using PowerShell. The preview modules and sample code can be found in the Azure
AD GitHub repo .

The Invoke-AzureADIPDismissRiskyUser.ps1 script included in the repo allows

organizations to dismiss all risky users in their directory.

Next steps
To get an overview of Azure AD Identity Protection, see the Azure AD Identity Protection
overview.

Additional resources
 Documentation

Sign-in event details for Azure AD Multi-Factor Authentication - Azure Active

Directory - Microsoft Entra
Learn how to view sign-in activity for Azure AD Multi-Factor Authentication events and status
messages.

Troubleshoot combined registration - Azure Active Directory - Microsoft Entra

Troubleshoot Azure AD Multi-Factor Authentication and self-service password reset combined
registration

Risk-based user sign-in protection in Azure Active Directory - Microsoft Entra

In this tutorial, you learn how to enable Azure Identity Protection to protect users when risky sign-in
behavior is detected on their account.

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

View and manage risky users in Microsoft 365 Lighthouse - Microsoft 365 Lighthouse
For Managed Service Providers (MSPs) using Microsoft 365 Lighthouse, learn how to view and
manage risky users.

Self-service password reset reports - Azure Active Directory - Microsoft Entra

Reporting on Azure AD self-service password reset events

Configure the MFA registration policy - Azure Active Directory Identity Protection -
Microsoft Entra
Learn how to configure the Azure AD Identity Protection multifactor authentication registration
policy.

Block legacy authentication with Conditional Access - Azure Active Directory -

Microsoft Entra
Create a custom Conditional Access policy to block legacy authentication protocols

Show 5 more

 Training

Learning paths and modules

Understand Microsoft 365 risk management - Training
Learn how Microsoft 365 identifies, assesses, responds to, and manages risks to protect customers
and the Microsoft 365 environment.
How To: Export risk data
Article • 03/08/2023 • 2 minutes to read

Azure AD stores reports and security signals for a defined period of time. When it comes
to risk information that period may not be long enough.

Report / Signal Azure AD Free Azure AD Premium P1 Azure AD Premium P2

Audit logs 7 days 30 days 30 days

Sign-ins 7 days 30 days 30 days

Azure AD MFA usage 30 days 30 days 30 days

Risky sign-ins 7 days 30 days 30 days

Organizations can choose to store data for longer periods by changing diagnostic
settings in Azure AD to send RiskyUsers, UserRiskEvents, RiskyServicePrincipals, and
ServicePrincipalRiskEvents data to a Log Analytics workspace, archive data to a storage
account, stream data to an event hub, or send data to a partner solution. Find these
options in the Azure portal > Azure Active Directory, Diagnostic settings > Edit
setting. If you don't have a diagnostic setting, follow the instructions in the article
Create diagnostic settings to send platform logs and metrics to different destinations to
create one.


Log Analytics
Log Analytics allows organizations to query data using built in queries or custom
created Kusto queries, for more information, see Get started with log queries in Azure
Monitor.

Once enabled you'll find access to Log Analytics in the Azure portal > Azure AD > Log
Analytics. The following tables are of most interest to Identity Protection administrators:

AADRiskyUsers - Provides data like the Risky users report in Identity Protection.
AADUserRiskEvents - Provides data like the Risk detections report in Identity
Protection.
RiskyServicePrincipals - Provides data like the Risky workload identities report in
Identity Protection.
ServicePrincipalRiskEvents - Provides data like the Workload identity detections
report in Identity Protection.

In the previous image, the following query was run to show the most recent five risk
detections triggered.

Kusto

AADUserRiskEvents

| take 5

Another option is to query the AADRiskyUsers table to see all risky users.
 Kusto

AADRiskyUsers

７ Note

Log Analytics only has visibility into data as it is streamed. Events prior to enabling
the sending of events from Azure AD do not appear.

Storage account
By routing logs to an Azure storage account, you can keep it for longer than the default
retention period. For more information, see the article Tutorial: Archive Azure AD logs to
an Azure storage account.

Azure Event Hubs

Azure Event Hubs can look at incoming data from sources like Azure AD Identity
Protection and provide real-time analysis and correlation. For more information, see the
article Tutorial: Stream Azure Active Directory logs to an Azure event hub

Other options
Organizations can choose to connect Azure AD data to Microsoft Sentinel as well for
further processing.

Organizations can use the Microsoft Graph API to programatically interact with risk
events.

Next steps
What is Azure Active Directory monitoring?
Install and use the log analytics views for Azure Active Directory
Connect data from Azure Active Directory (Azure AD) Identity Protection
Azure Active Directory Identity Protection and the Microsoft Graph PowerShell SDK
Tutorial: Stream Azure Active Directory logs to an Azure event hub

Additional resources
 Documentation

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

Azure Active Directory security operations for Privileged Identity Management -

Microsoft Entra
Establish baselines and use Azure AD Privileged Identity Management (PIM) to monitor and alert on
issues with accounts governed by PIM.

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

Azure Active Directory security operations for user accounts - Microsoft Entra
Guidance to establish baselines and how to monitor and alert on potential security issues with user
accounts.

Security operations for privileged accounts in Azure Active Directory - Microsoft Entra
Learn about baselines, and how to monitor and alert on potential security issues with privileged
accounts in Azure Active Directory.

Identity protection risk analysis workbook in Azure AD - Microsoft Entra

Learn how to use the identity protection risk analysis workbook.

Show 5 more

 Training

Module
Protect your identities with Azure AD Identity Protection - Training
Use the advanced detection and remediation of identity-based threats to protect your Azure Active
Directory identities and applications from compromise.

Certification
Microsoft Certified: Identity and Access Administrator Associate - Certifications
The Microsoft identity and access administrator designs, implements, and operates an organization’s
identity and access management systems by using Microsoft Azure Active Directory (Azure AD), part
of Microsoft Entra. They configure and manage authentication and authorization of identities for…
Azure Active Directory Identity
Protection and the Microsoft Graph
PowerShell
Article • 09/14/2022 • 2 minutes to read

Microsoft Graph is the Microsoft unified API endpoint and the home of Azure Active
Directory Identity Protection APIs. This article will show you how to use the Microsoft
Graph PowerShell SDK to manage risky users using PowerShell. Organizations that want
to query the Microsoft Graph APIs directly can use the article, Tutorial: Identify and
remediate risks using Microsoft Graph APIs to begin that journey.

To successfully complete this tutorial, make sure you have the required prerequisites:

Microsoft Graph PowerShell SDK is installed. For more information, see the article
Install the Microsoft Graph PowerShell SDK.

Identity Protection is available in the beta version of Microsoft Graph PowerShell.

Run the following command to set your profile to beta.

PowerShell

# Connect to Graph beta Endpoint

Select-MgProfile -Name 'beta'

Microsoft Graph PowerShell using a global administrator role and the appropriate
permissions. The IdentityRiskEvent.Read.All, IdentityRiskyUser.ReadWrite.All Or
IdentityRiskyUser.ReadWrite.All delegated permissions are required. To set the
permissions to IdentityRiskEvent.Read.All and IdentityRiskyUser.ReadWrite.All, run:

PowerShell

Connect-MgGraph -Scopes
"IdentityRiskEvent.Read.All","IdentityRiskyUser.ReadWrite.All"

If you use app-only authentication, see the article Use app-only authentication with the
Microsoft Graph PowerShell SDK. To register an application with the required application
permissions, prepare a certificate and run:

PowerShell
 Connect-MgGraph -ClientID YOUR_APP_ID -TenantId YOUR_TENANT_ID -
CertificateName YOUR_CERT_SUBJECT ## Or -CertificateThumbprint instead of -
CertificateName

List risky detections using PowerShell

You can retrieve the risk detections by the properties of a risk detection in Identity
Protection.

PowerShell

# List all anonymizedIPAddress risk detections

Get-MgRiskDetection -Filter "RiskType eq 'anonymizedIPAddress'" | Format-

Table UserDisplayName, RiskType, RiskLevel, DetectedDateTime

# List all high risk detections for the user 'User01'

Get-MgRiskDetection -Filter "UserDisplayName eq 'User01' and Risklevel eq

'high'" | Format-Table UserDisplayName, RiskType, RiskLevel,
DetectedDateTime

List risky users using PowerShell

You can retrieve the risky users and their risky histories in Identity Protection.

PowerShell

# List all high risk users

Get-MgRiskyUser -Filter "RiskLevel eq 'high'" | Format-Table

UserDisplayName, RiskDetail, RiskLevel, RiskLastUpdatedDateTime

# List history of a specific user with detailed risk detection

Get-MgRiskyUserHistory -RiskyUserId 375844b0-2026-4265-b9f1-ee1708491e05|

Format-Table RiskDetail, RiskLastUpdatedDateTime, @{N="RiskDetection";E=
{($_). Activity.RiskEventTypes}}, RiskState, UserDisplayName

Confirm users compromised using PowerShell

You can confirm users compromised and flag them as high risky users in Identity
Protection.

PowerShell
 # Confirm Compromised on two users

Confirm-MgRiskyUserCompromised -UserIds "577e09c1-5f26-4870-81ab-

6d18194cbb51","bf8ba085-af24-418a-b5b2-3fc71f969bf3"

Dismiss risky users using PowerShell

You can bulk dismiss risky users in Identity Protection.

PowerShell

# Get a list of high risky users which are more than 90 days old

$riskyUsers= Get-MgRiskyUser -Filter "RiskLevel eq 'high'" | where

RiskLastUpdatedDateTime -LT (Get-Date).AddDays(-90)

# bulk dimmiss the risky users

Invoke-MgDismissRiskyUser -UserIds $riskyUsers.Id

Next steps
Get started with the Microsoft Graph PowerShell SDK
Tutorial: Identify and remediate risks using Microsoft Graph APIs
Overview of Microsoft Graph
Azure Active Directory Identity Protection

Additional resources
 Documentation

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

What are Azure Active Directory recommendations? - Microsoft Entra

Provides a general overview of Azure Active Directory recommendations.

Export and use Azure Active Directory Identity Protection data - Microsoft Entra
Learn how to investigate using long-term data in Azure Active Directory Identity Protection

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

Securing workload identities with Azure AD Identity Protection - Microsoft Entra

Workload identity risk in Azure Active Directory Identity Protection

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

Show 5 more

 Training

Module
Introduction to Microsoft Graph PowerShell - Training
Evaluate whether Microsoft Graph PowerShell is appropriate to automate your business processes
How To: Give risk feedback in Azure AD
Identity Protection
Article • 08/23/2022 • 4 minutes to read

Azure AD Identity Protection allows you to give feedback on its risk assessment. The
following document lists the scenarios where you would like to give feedback on Azure
AD Identity Protection’s risk assessment and how we incorporate it.

What is a detection?
An Identity Protection detection is an indicator of suspicious activity from an identity risk
perspective. These suspicious activities are called risk detections. These identity-based
detections can be based on heuristics, machine learning or can come from partner
products. These detections are used to determine sign-in risk and user risk,

User risk represents the probability an identity is compromised.

Sign-in risk represents the probability a sign-in is compromised (for example, the
sign-in isn't authorized by the identity owner).

Why should I give risk feedback to Azure AD’s

risk assessments?
There are several reasons why you should give Azure AD risk feedback:

You found Azure AD’s user or sign-in risk assessment incorrect. For example, a
sign-in shown in ‘Risky sign-ins’ report was benign and all the detections on that
sign-in were false positives.
You validated that Azure AD’s user or sign-in risk assessment was correct. For
example, a sign-in shown in ‘Risky sign-ins’ report was indeed malicious and you
want Azure AD to know that all the detections on that sign-in were true positives.
You remediated the risk on that user outside of Azure AD Identity Protection and
you want the user’s risk level to be updated.

How does Azure AD use my risk feedback?

Azure AD uses your feedback to update the risk of the underlying user and/or sign-in
and the accuracy of these events. This feedback helps secure the end user. For example,
once you confirm a sign-in is compromised, Azure AD immediately increases the user’s
risk and sign-in’s aggregate risk (not real-time risk) to High. If this user is included in
your user risk policy to force High risk users to securely reset their passwords, the user
will automatically remediate itself the next time they sign-in.

How should I give risk feedback and what

happens under the hood?
Here are the scenarios and mechanisms to give risk feedback to Azure AD.

Scenario How to give What happens Notes

feedback? under the hood?

Sign-in not Select the sign-in Azure AD will move Currently, the ‘Confirm sign-in
compromised and then the sign-in’s safe’ option is only available in
(False positive)
‘Confirm sign-in aggregate risk to ‘Risky sign-ins’ report.
‘Risky sign-ins’ safe’. none [Risk state =
report shows an at- Confirmed safe; Risk
risk sign-in [Risk level (Aggregate) = -]
state = At risk] but and will reverse its
that sign-in wasn't impact on the user
compromised. risk.

Sign-in Select the sign-in Azure AD will move Currently, the ‘Confirm sign-in
compromised and then the sign-in’s compromised’ option is only
(True positive)
‘Confirm sign-in aggregate risk and available in ‘Risky sign-ins’
‘Risky sign-ins’ compromised’. the user risk to High report.
report shows an at- [Risk state =
risk sign-in [Risk Confirmed
state = At risk] with compromised; Risk
low risk [Risk level level = High].
(Aggregate) = Low]
and that sign-in
was indeed
compromised.

User compromised Select the user Azure AD will move Currently, the ‘Confirm user
(True positive)
and then the user risk to High compromised’ option is only
‘Risky users’ report ‘Confirm user [Risk state = available in ‘Risky users’ report.

shows an at-risk compromised’. Confirmed The detection ‘Admin

user [Risk state = compromised; Risk confirmed user compromised’
At risk] with low level = High] and will is shown in the tab ‘Risk
risk [Risk level = add a new detection detections not linked to a sign-
Low] and that user ‘Admin confirmed in’ in the ‘Risky users’ report.
was indeed user compromised’.
compromised.
Scenario How to give What happens Notes
feedback? under the hood?

User remediated 1. Select the user Azure AD moves the Clicking ‘Dismiss user risk’ will
outside of Azure and then user risk to none close all risk on the user and
AD Identity ‘Confirm user [Risk state = past sign-ins. This action can't
Protection (True compromised’. Dismissed; Risk level be undone.
positive + (This process = -] and closes the
Remediated)
confirms to risk on all existing
‘Risky users’ report Azure AD that sign-ins having
shows an at-risk the user was active risk.
user and I've then indeed
remediated the compromised.)

user outside of 2. Wait for the

Azure AD Identity user’s ‘Risk level’
Protection. to go to High.
(This time gives
Azure AD the
needed time to
take the above
feedback to the
risk engine.)

3. Select the user

and then
‘Dismiss user
risk’. (This
process confirms
to Azure AD that
the user is no
longer
compromised.)

User not Select the user Azure AD moves the Clicking ‘Dismiss user risk’ will
compromised and then user risk to none close all risk on the user and
(False positive)
‘Dismiss user [Risk state = past sign-ins. This action can't
‘Risky users’ report risk’. (This Dismissed; Risk level be undone.
shows at at-risk process confirms = -].
user but the user to Azure AD that
isn't compromised. the user isn't
compromised.)
 Scenario How to give What happens Notes
feedback? under the hood?

I want to close the Select the user Azure AD moves the Clicking ‘Dismiss user risk’ will
user risk but I'm and then user risk to none close all risk on the user and
not sure whether ‘Dismiss user [Risk state = past sign-ins. This action can't
the user is risk’. (This Dismissed; Risk level be undone. We recommend
compromised / process confirms = -]. you remediate the user by
safe. to Azure AD that clicking on ‘Reset password’ or
the user is no request the user to securely
longer reset/change their credentials.
compromised.)

Feedback on user risk detections in Identity Protection is processed offline and may take
some time to update. The risk processing state column will provide the current state of
feedback processing.

Next steps
Azure Active Directory Identity Protection risk detections reference

Additional resources
 Documentation

Investigate risk Azure Active Directory Identity Protection - Microsoft Entra

Learn how to investigate risky users, detections, and sign-ins in Azure Active Directory Identity
Protection

Simulating risk detections in Azure AD Identity Protection - Microsoft Entra

Learn how to simulate risk detections in Identity Protection

FAQs for Identity Protection in Azure Active Directory - Microsoft Entra

Frequently asked questions Azure AD Identity Protection

Azure Active Directory Identity Protection notifications - Microsoft Entra

Learn how notifications support your investigation activities.

What is risk? Azure AD Identity Protection - Microsoft Entra

Explaining risk in Azure AD Identity Protection

User risk-based password change - Azure Active Directory - Microsoft Entra

Create Conditional Access policies using Identity Protection user risk

Risk policies - Azure Active Directory Identity Protection - Microsoft Entra

Enable and configure risk policies in Azure Active Directory Identity Protection

Azure AD Identity Protection risk-based access policies - Microsoft Entra

Identifying risk-based Conditional Access policies

Show 5 more

 Training

Module
Understand Microsoft 365 risk management - Training
Learn how Microsoft 365 identifies, assesses, responds to, and manages risks to protect customers
and the Microsoft 365 environment.
Frequently asked questions
Identity Protection in Azure Active
Directory
FAQ

Dismiss user risk known issues

Dismiss user risk in classic Identity Protection sets the actor in the user’s risk history in
Identity Protection to Azure AD.

Dismiss user risk in Identity Protection sets the actor in the user’s risk history in Identity
Protection to <Admin’s name with a hyperlink pointing to user’s blade>.

There's a current known issue causing latency in the user risk dismissal flow. If you have
a "User risk policy", this policy will stop applying to dismissed users within minutes of
clicking on "Dismiss user risk". However, there are known delays with the UX refreshing
the "Risk state" of dismissed users. As a workaround, refresh the page on the browser
level to see the latest user "Risk state".

Frequently asked questions

Why is a user at risk?

If you're an Azure AD Identity Protection customer, go to the risky users view and select
an at-risk user. In the drawer at the bottom, tab ‘Risk history’ will show all the events
that led to a user risk change. To see all risky sign-ins for the user, select ‘User’s risky
sign-ins’. To see all risk detections for this user, select ‘User’s risk detections’.

Why was my sign-in blocked but Identity Protection

didn't generate a risk detection?
Sign-ins can be blocked for several reasons. It's important to note that Identity
Protection only generates risk detections when correct credentials are used in the
authentication request. If a user uses incorrect credentials, it will not be flagged by
Identity Protection since there isn't of risk of credential compromise unless a bad actor
uses the correct credentials. Some reasons a user can be blocked from signing that
won't generate an Identity Protection detection include:
 The IP can be blocked due to malicious activity from the IP address. The IP blocked
message doesn't differentiate whether the credentials were correct or not. If the IP
is blocked and correct credentials aren't used, it will not generate an Identity
Protection detection
Smart Lockout can block the account from signing-in after multiple failed
attempts
A Conditional Access policy can be enforced that uses conditions other than risk
level to block an authentication request

How can I get a report of detections of a specific type?

Go to the risk detections view and filter by ‘Detection type’. You can then download this
report in .CSV or .JSON format using the Download button at the top. For more
information, see the article How To: Investigate risk.

Why can’t I set my own risk levels for each risk detection?
Risk levels in Identity Protection are based on the precision of the detection and
powered by our supervised machine learning. To customize what experience users are
presented, administrator can include/exclude certain users/groups from the User Risk
and Sign-In Risk Policies.

Why does the location of a sign-in not match where the

user truly signed in from?
IP geolocation mapping is an industry-wide challenge. If you feel that the location listed
in the sign-ins report doesn't match the actual location, reach out to Microsoft support.

How can I close specific risk detections like I did in the

old UI?
You can give feedback on risk detections by confirming the linked sign-in as
compromised or safe. The feedback given on the sign-in trickles down to all the
detections made on that sign-in. If you want to close detections that aren't linked to a
sign-in, you can provide that feedback on the user level. For more information, see the
article How to: Give risk feedback in Azure AD Identity Protection.

How far can I go back in time to understand what’s going

on with my user?
 The risky users view shows a user’s risk standing based on all past sign-ins.
The risky sign-ins view shows at-risk signs in the last 30 days.
The risk detections view shows risk detections made in the last 90 days.

How can I learn more about a specific detection?

All risk detections are documented in the article What is risk. You can hover over the (i)
symbol next to the detection on the Azure portal to learn more about a detection.

How do the feedback mechanisms in Identity Protection

work?
Confirm compromised (on a sign-in) – Informs Azure AD Identity Protection that the
sign-in wasn't performed by the identity owner and indicates a compromise.

Upon receiving this feedback, we move the sign-in and user risk state to
Confirmed compromised and risk level to High.

In addition, we provide the information to our machine learning systems for future
improvements in risk assessment.

７ Note

If the user is already remediated, don't select Confirm compromised because

it moves the sign-in and user risk state to Confirmed compromised and risk
level to High.

Confirm safe (on a sign-in) – Informs Azure AD Identity Protection that the sign-in was
performed by the identity owner and doesn't indicate a compromise.

Upon receiving this feedback, we move the sign-in (not the user) risk state to
Confirmed safe and the risk level to None.

In addition, we provide the information to our machine learning systems for future
improvements in risk assessment.

７ Note

Today, selecting confirm safe on a sign-in doesn't by itself prevent future sign-
ins with the same properties from being flagged as risky. The best way to train
the system to learn a user's properties is to use the risky sign-in policy with
 MFA. When a risky sign-in is prompted for MFA and the user successfully
responds to the request, the sign-in can succeed, and help to train the system
on the legitimate user's behavior.

If you believe the user isn't compromised, use Dismiss user risk on the user
level instead of using Confirmed safe on the sign-in level. A Dismiss user risk
on the user level closes the user risk and all past risky sign-ins and risk
detections.

Why am I seeing a user with a low (or above) risk score,

even if no risky sign-ins or risk detections are shown in
Identity Protection?
Given the user risk is cumulative in nature and doesn't expire, a user may have a user
risk of low or above even if there are no recent risky sign-ins or risk detections shown in
Identity Protection. This situation could happen if the only malicious activity on a user
took place beyond the timeframe for which we store the details of risky sign-ins and risk
detections. We don't expire user risk because bad actors have been known to stay in
customers' environment over 140 days behind a compromised identity before ramping
up their attack. Customers can review the user's risk timeline to understand why a user is
at risk by going to: Azure portal > Azure Active Directory > Risky users report >
select an at-risk user > details drawer > Risk history tab . If you believe the user
isn't compromised, use Dismiss user risk through Graph API.

Why does a sign-in have a “sign-in risk (aggregate)” score

of High when the detections associated with it are of low
or medium risk?
The high aggregate risk score could be based on other features of the sign-in, or the
fact that more than one detection fired for that sign-in. And conversely, a sign-in may
have a sign-in risk (aggregate) of Medium even if the detections associated with the
sign-in are of High risk.

What is the difference between the "Activity from

anonymous IP address" and "Anonymous IP address"
detections?
The "Anonymous IP address" detection's source is Azure AD Identity Protection, while
the "Activity from anonymous IP address" detection is integrated from Microsoft
Defender for Cloud Apps). While they have similar names and you might see overlap in
these signals, they have distinct back-end detections.
riskDetection resource type
Article • 10/12/2022 • 6 minutes to read

Namespace: microsoft.graph

Represents information about a detected risk in an Azure AD tenant.

Azure AD continually evaluates user risks and app or user sign-in risks based on various
signals and machine learning. This API provides programmatic access to all risk
detections in your Azure AD environment.

For more information about risk events, see Azure Active Directory Identity Protection.

７ Note

1. You must have an Azure AD Premium P1 or P2 license to use the risk

detection API.
2. The availability of risk detection data is governed by the Azure AD data
retention policies.

Methods
Method Return type Description

List riskDetection Get a list of the riskDetection objects and their

riskDetections collection properties.

Get riskDetection Read the properties and relationships of a riskDetection

riskDetection object.

Properties
Property Type Description

activity activityType Indicates the activity type the detected risk is

linked to. Possible values are: signin , user ,
unknownFutureValue .
Property Type Description

activityDateTime DateTimeOffset Date and time that the risky activity occurred. The
DateTimeOffset type represents date and time
information using ISO 8601 format and is always
in UTC time. For example, midnight UTC on Jan 1,
2014 is look like this: 2014-01-01T00:00:00Z

additionalInfo String Additional information associated with the risk

detection in JSON format. For example, "
[{\"Key\":\"userAgent\",\"Value\":\"Mozilla/5.0
(Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/68.0.3440.106 Safari/537.36\"}]" .
Possible keys in the additionalInfo JSON string
are: userAgent , alertUrl , relatedEventTimeInUtc ,
relatedUserAgent , deviceInformation ,
relatedLocation , requestId , correlationId ,
lastActivityTimeInUtc , malwareName ,
clientLocation , clientIp , riskReasons .

For more information about riskReasons and

possible values, see riskReasons values.

correlationId String Correlation ID of the sign-in associated with the

risk detection. This property is null if the risk
detection is not associated with a sign-in.

detectedDateTime DateTimeOffset Date and time that the risk was detected. The
DateTimeOffset type represents date and time
information using ISO 8601 format and is always
in UTC time. For example, midnight UTC on Jan 1,
2014 looks like this: 2014-01-01T00:00:00Z

detectionTimingType riskDetectionTimingType Timing of the detected risk (real-time/offline).

Possible values are: notDefined , realtime ,
nearRealtime , offline , unknownFutureValue .

id String Unique ID of the risk detection. Inherited from

entity

ipAddress String Provides the IP address of the client from where

the risk occurred.

lastUpdatedDateTime DateTimeOffset Date and time that the risk detection was last
updated. The DateTimeOffset type represents
date and time information using ISO 8601 format
and is always in UTC time. For example, midnight
UTC on Jan 1, 2014 is look like this: 2014-01-
01T00:00:00Z
Property Type Description

location signInLocation Location of the sign-in.

requestId String Request ID of the sign-in associated with the risk

detection. This property is null if the risk
detection is not associated with a sign-in.

riskDetail riskDetail Details of the detected risk. The possible values

are: none , adminGeneratedTemporaryPassword ,
userPerformedSecuredPasswordChange ,
userPerformedSecuredPasswordReset ,
adminConfirmedSigninSafe ,
aiConfirmedSigninSafe ,
userPassedMFADrivenByRiskBasedPolicy ,
adminDismissedAllRiskForUser ,
adminConfirmedSigninCompromised , hidden ,
adminConfirmedUserCompromised ,
unknownFutureValue ,
m365DAdminDismissedDetection . Note that you
must use the Prefer: include - unknown -enum-
members request header to get the following
value(s) in this evolvable enum:
m365DAdminDismissedDetection .

riskEventType String The type of risk event detected. The possible

values are unlikelyTravel , anonymizedIPAddress ,
maliciousIPAddress , unfamiliarFeatures ,
malwareInfectedIPAddress , suspiciousIPAddress ,
leakedCredentials ,
investigationsThreatIntelligence ,
generic , adminConfirmedUserCompromised ,
passwordSpray , impossibleTravel , newCountry ,
anomalousToken ,
tokenIssuerAnomaly , suspiciousBrowser ,
riskyIPAddress ,
mcasSuspiciousInboxManipulationRules ,
suspiciousInboxForwarding , and
anomalousUserActivity . If the risk detection is a
premium detection, will show generic .

For more information about each value, see

riskEventType values.

riskLevel riskLevel Level of the detected risk. Possible values are:

low , medium , high , hidden , none ,
unknownFutureValue .
Property Type Description

riskState riskState The state of a detected risky user or sign-in.

Possible values are: none , confirmedSafe ,
remediated , dismissed , atRisk ,
confirmedCompromised , unknownFutureValue .

source String Source of the risk detection. For example,

activeDirectory .

tokenIssuerType tokenIssuerType Indicates the type of token issuer for the detected
sign-in risk. Possible values are: AzureAD ,
ADFederationServices , UnknownFutureValue .

userDisplayName String The user principal name (UPN) of the user.

userId String Unique ID of the user.

userPrincipalName String The user principal name (UPN) of the user.

riskEventType values

Name UI Display Name Description

unlikelyTravel Atypical travel Identifies two sign-ins

originating from geographically
distant locations, where at least
one of the locations may also be
atypical for the user, given past
behavior.

anonymizedIPAddress Anonymous IP Indicates sign-ins from an

address anonymous IP address, for
example, using an anonymous
browser or VPN.

maliciousIPAddress Malicious IP address Indicates sign-ins from a

malicious IP address. An IP
address is considered malicious
based on high failure rates
because of invalid credentials
received from the IP address or
other IP reputation sources.

unfamiliarFeatures Unfamiliar sign-in Indicates sign-ins with

properties characteristics that deviate from
past sign-in properties.
Name UI Display Name Description

malwareInfectedIPAddress Malware linked IP Indicates sign-ins from IP

address addresses infected with
malware. Deprecated and no
longer generated for new
detections.

suspiciousIPAddress Malicious IP address Identifies logins from IP

addresses that are known to be
malicious at the time of the sign
in.

leakedCredentials Leaked credentials Indicates that the user's valid

credentials have been leaked.
This sharing is typically done by
posting publicly on the dark
web, paste sites, or by trading
and selling the credentials on
the black market. When the
Microsoft leaked credentials
service acquires user credentials
from the dark web, paste sites,
or other sources, they are
checked against Azure AD users'
current valid credentials to find
valid matches.

investigationsThreatIntelligence Azure AD threat Indicates a sign-in activity that is

intelligence unusual for the given user or is
consistent with known attack
patterns based on Microsoft's
internal and external threat
intelligence sources.

generic Additional risk Indicates that the user was not

detected enabled for Identity Protection.

adminConfirmedUserCompromised Admin confirmed Indicates that an administrator

user compromised has confirmed the user is
compromised.

passwordSpray Password spray Indicates that multiple

usernames are attacked using
common passwords in a unified
brute force manner to gain
unauthorized access.
Name UI Display Name Description

anomalousToken Anomalous Token Indicates that there are

abnormal characteristics in the
token such as an unusual token
lifetime or a token that is played
from an unfamiliar location.

tokenIssuerAnomaly Token Issuer Indicates that The SAML token

Anomaly issuer for the associated SAML
token is potentially
compromised. The claims
included in the token are
unusual or match known
attacker patterns.

suspiciousBrowser Suspicious browser Suspicious sign-in activity across

multiple tenants from different
countries in the same browser.

impossibleTravel Impossible travel Discovered by Microsoft

Defender for Cloud Apps
(MDCA). Identifies two user
activities (a single or multiple
sessions) originating from
geographically distant locations
within a time period shorter
than the time it would have
taken the user to travel from the
first location to the second,
indicating that a different user is
using the same credentials.

newCountry New country This detection is discovered by

Microsoft Cloud App Security
(MCAS). The sign-in occurred
from a location that wasn't
recently or never visited by the
given user.

riskyIPAddress Activity from This detection is discovered by

anonymous IP Microsoft Cloud App Security
address (MCAS). Users were active from
an IP address that has been
identified as an anonymous
proxy IP address.
 Name UI Display Name Description

mcasSuspiciousInboxManipulationRules Suspicious inbox Discovered by Microsoft

manipulation rules Defender for Cloud Apps
(MDCA). Identifies suspicious
email forwarding rules, for
example, if a user created an
inbox rule that forwards a copy
of all emails to an external
address.

suspiciousInboxForwarding Suspicious inbox This detection is discovered by

forwarding Microsoft Cloud App Security
(MCAS). It looks for suspicious
email forwarding rules, for
example, if a user created an
inbox rule that forwards a copy
of all emails to an external
address.

anomalousUserActivity Indicates a
suspicious pattern
of behavior for a
user that is
anomalous to past
behavioral patterns.

riskReasons values

riskEventType Value UI display string

investigationsThreatIntelligence suspiciousIP This sign-in was from a suspicious IP

address

investigationsThreatIntelligence passwordSpray This user account was attacked by a

password spray.

Relationships
None.

JSON representation
The following is a JSON representation of the resource.
JSON

"@odata.type": "#microsoft.graph.riskDetection",

"id": "String (identifier)",

"requestId": "String",

"correlationId": "String",

"riskEventType": "String",

"riskState": "String",

"riskLevel": "String",

"riskDetail": "String",

"source": "String",

"detectionTimingType": "String",

"activity": "String",

"tokenIssuerType": "String",

"ipAddress": "String",

"location": {

"@odata.type": "microsoft.graph.signInLocation"

},

"activityDateTime": "String (timestamp)",

"detectedDateTime": "String (timestamp)",

"lastUpdatedDateTime": "String (timestamp)",

"userId": "String",

"userDisplayName": "String",

"userPrincipalName": "String",

"additionalInfo": "String"

riskyUser resource type

Article • 12/14/2022 • 2 minutes to read

Namespace: microsoft.graph

Represents Azure AD users who are at risk. Azure AD continually evaluates user risk
based on various signals and machine learning. This API provides programmatic access
to all at-risk users in your Azure AD.

For more information about risk events, see Azure Active Directory Identity Protection.

７ Note

1. Using the riskyUsers API requires an Azure AD Premium P2 license.

2. The availability of risky user data is governed by the Azure AD data retention
policies.

Methods
Method Return type Description

List riskyUsers riskyUser collection Get a list of the riskyUser objects and their
properties.

Get riskyUser riskyUser Read the properties and relationships of a

riskyUser object.

Dismiss a riskyUser None Dismiss the risk of one or more riskyUser

objects.

Confirm a riskyUser as None Confirm one or more riskyUser objects as

compromised compromised.

List history riskyUserHistoryItem Get the riskyUserHistoryItems from the history

collection navigation property.

Get history riskyUserHistoryItem Read the properties and relationships of a

riskyUserHistoryItem object.

Properties
Property Type Description
Property Type Description

id String Unique ID of the user at risk.

isDeleted Boolean Indicates whether the user is deleted. Possible

values are: true , false .

isProcessing Boolean Indicates whether a user's risky state is being

processed by the backend.

riskDetail riskDetail Details of the detected risk. Possible values are:

none , adminGeneratedTemporaryPassword ,
userPerformedSecuredPasswordChange ,
userPerformedSecuredPasswordReset ,
adminConfirmedSigninSafe , aiConfirmedSigninSafe ,
userPassedMFADrivenByRiskBasedPolicy ,
adminDismissedAllRiskForUser ,
adminConfirmedSigninCompromised , hidden ,
adminConfirmedUserCompromised ,
unknownFutureValue .

riskLastUpdatedDateTime DateTimeOffset The date and time that the risky user was last
updated. The DateTimeOffset type represents date
and time information using ISO 8601 format and is
always in UTC time. For example, midnight UTC on
Jan 1, 2014 is 2014-01-01T00:00:00Z .

riskLevel riskLevel Level of the detected risky user. Possible values are:
low , medium , high , hidden , none ,
unknownFutureValue .

riskState riskState State of the user's risk. Possible values are: none ,
confirmedSafe , remediated , dismissed , atRisk ,
confirmedCompromised , unknownFutureValue .

userDisplayName String Risky user display name.

userPrincipalName String Risky user principal name.

Relationships
Relationship Type Description

history riskyUserHistoryItem collection The activity related to user risk level change

JSON representation
The following is a JSON representation of the resource.

JSON

"@odata.type": "#microsoft.graph.riskyUser",

"id": "String (identifier)",

"isDeleted": "Boolean",

"isProcessing": "Boolean",

"riskLastUpdatedDateTime": "String (timestamp)",

"riskLevel": "String",

"riskState": "String",

"riskDetail": "String",

"userDisplayName": "String",

"userPrincipalName": "String"

signIn resource type

Article • 01/24/2023 • 3 minutes to read

Namespace: microsoft.graph

Details user and application sign-in activity for a tenant (directory). You must have an Azure
AD Premium P1 or P2 license to download sign-in logs using the Microsoft Graph API.

The availability of sign-in logs is governed by the Azure AD data retention policies.

Methods
Method Return Type Description

List signIn signIn Read properties and relationships of signIn objects.

Get signIn signIn Read properties and relationships of signIn object.

Properties
Property Type Description

appDisplayName String App name displayed in the Azure

Portal. Supports $filter ( eq and
startsWith operators only).

appId String Unique GUID representing the app ID

in the Azure Active Directory. Supports
$filter ( eq operator only).

appliedConditionalAccessPolicies appliedConditionalAccessPolicy Provides a list of conditional access

collection policies that are triggered by the
corresponding sign-in activity.

clientAppUsed String Identifies the client used for the sign-in

activity. Modern authentication clients
include Browser and modern clients .
Legacy authentication clients include
Exchange ActiveSync , IMAP , MAPI ,
SMTP , POP , and other clients .
Supports $filter ( eq operator only).
Property Type Description

conditionalAccessStatus conditionalAccessStatus Reports status of an activated

conditional access policy. Possible
values are: success , failure ,
notApplied , and unknownFutureValue .
Supports $filter ( eq operator only).

correlationId String The request ID sent from the client

when the sign-in is initiated; used to
troubleshoot sign-in activity. Supports
$filter ( eq operator only).

createdDateTime DateTimeOffset Date and time (UTC) the sign-in was

initiated. Example: midnight on Jan 1,
2014 is reported as 2014-01-
01T00:00:00Z . Supports $orderby and
$filter ( eq , le , and ge operators
only).

deviceDetail deviceDetail Device information from where the

sign-in occurred; includes device ID,
operating system, and browser.
Supports $filter ( eq and startsWith
operators only) on browser and
operatingSytem properties.

id String Unique ID representing the sign-in

activity. Supports $filter ( eq operator
only).

ipAddress String IP address of the client used to sign in.

Supports $filter ( eq and startsWith
operators only).

isInteractive Boolean Indicates if a sign-in is interactive or

not.

location signInLocation Provides the city, state, and country

code where the sign-in originated.
Supports $filter ( eq and startsWith
operators only) on city, state, and
countryOrRegion properties.

resourceDisplayName String Name of the resource the user signed

into. Supports $filter ( eq operator
only).

resourceId String ID of the resource that the user signed

into. Supports $filter ( eq operator
only).
Property Type Description

riskDetail riskDetail Provides the 'reason' behind a specific

state of a risky user, sign-in or a risk
event. The possible values are: none ,
adminGeneratedTemporaryPassword ,
userPerformedSecuredPasswordChange ,
userPerformedSecuredPasswordReset ,
adminConfirmedSigninSafe ,
aiConfirmedSigninSafe ,
userPassedMFADrivenByRiskBasedPolicy ,
adminDismissedAllRiskForUser ,
adminConfirmedSigninCompromised ,
unknownFutureValue . The value none
means that no action has been
performed on the user or sign-in so far.
Supports $filter ( eq operator only).

Note: Details for this property require

an Azure AD Premium P2 license. Other
licenses return the value hidden .

riskEventTypes riskEventType collection Risk event types associated with the

sign-in. The possible values are:
unlikelyTravel , anonymizedIPAddress ,
maliciousIPAddress ,
unfamiliarFeatures ,
malwareInfectedIPAddress ,
suspiciousIPAddress ,
leakedCredentials ,
investigationsThreatIntelligence ,
generic , and unknownFutureValue .
Supports $filter ( eq operator only).

riskEventTypes_v2 String collection The list of risk event types associated

with the sign-in. Possible values:
unlikelyTravel , anonymizedIPAddress ,
maliciousIPAddress ,
unfamiliarFeatures ,
malwareInfectedIPAddress ,
suspiciousIPAddress ,
leakedCredentials ,
investigationsThreatIntelligence ,
generic , or unknownFutureValue .
Supports $filter ( eq and startsWith
operators only).
Property Type Description

riskLevelAggregated riskLevel Aggregated risk level. The possible

values are: none , low , medium , high ,
hidden , and unknownFutureValue . The
value hidden means the user or sign-in
was not enabled for Azure AD Identity
Protection. Supports $filter ( eq
operator only).

Note: Details for this property are only

available for Azure AD Premium P2
customers. All other customers will be
returned hidden .

riskLevelDuringSignIn riskLevel Risk level during sign-in. The possible

values are: none , low , medium , high ,
hidden , and unknownFutureValue . The
value hidden means the user or sign-in
was not enabled for Azure AD Identity
Protection. Supports $filter ( eq
operator only).

Note: Details for this property are only

available for Azure AD Premium P2
customers. All other customers will be
returned hidden .

riskState riskState Reports status of the risky user, sign-in,

or a risk event. The possible values are:
none , confirmedSafe , remediated ,
dismissed , atRisk ,
confirmedCompromised ,
unknownFutureValue . Supports $filter
( eq operator only).

status signInStatus Sign-in status. Includes the error code

and description of the error (in case of
a sign-in failure). Supports $filter ( eq
operator only) on errorCode property.

userDisplayName String Display name of the user that initiated

the sign-in. Supports $filter ( eq and
startsWith operators only).

userId String ID of the user that initiated the sign-in.

Supports $filter ( eq operator only).

userPrincipalName String User principal name of the user that

initiated the sign-in. Supports $filter
( eq and startsWith operators only).
Relationships
None

JSON representation
Here is a JSON representation of the resource.

JSON

"id": "String (identifier)",

"createdDateTime": "String (timestamp)",

"appDisplayName": "String",

"appId": "String",

"ipAddress": "String",

"clientAppUsed": "String",

"correlationId": "String",

"conditionalAccessStatus": "string",

"appliedConditionalAccessPolicy": [{"@odata.type":
"microsoft.graph.appliedConditionalAccessPolicy"}],

"isInteractive": true,

"deviceDetail": {"@odata.type": "microsoft.graph.deviceDetail"},

"location": {"@odata.type": "microsoft.graph.signInLocation"},

"riskDetail": "string",

"riskLevelAggregated": "string",

"riskLevelDuringSignIn": "string",

"riskState": "string",

"riskEventTypes": ["string"],

"riskEventTypes_v2": ["String"],

"resourceDisplayName": "string",

"resourceId": "string",

"status": {"@odata.type": "microsoft.graph.signInStatus"},

"userDisplayName": "string",

"userId": "string",

"userPrincipalName": "string"

servicePrincipalRiskDetection resource
type
Article • 12/06/2022 • 3 minutes to read

Namespace: microsoft.graph

Represents information about detected at-risk service principals in an Azure AD tenant.

Azure AD continually evaluates risks based on various signals and machine learning. This
API provides programmatic access to all service principal risk detections in your Azure
AD environment.

Inherits from entity.

For more information about risk events, see Azure Active Directory Identity Protection.

Note: You must have an Entra Workload Identity Premium license to use the
servicePrincipalRiskDetection API.

Methods
Method Return type Description

List servicePrincipalRiskDetection List service principal risk

servicePrincipalRiskDetections collection detections and their properties.

Get servicePrincipalRiskDetection Get a specific service principal

servicePrincipalRiskDetection risk detection and its properties.

Properties
Property Type Description

activity activityType Indicates the activity type the detected risk is

linked to. The possible values are: signin ,
servicePrincipal . Note that you must use
the Prefer: include-unknown-enum-members
request header to get the following value(s)
in this evolvable enum: servicePrincipal .
Property Type Description

activityDateTime DateTimeOffset Date and time when the risky activity

occurred. The DateTimeOffset type
represents date and time information using
ISO 8601 format and is always in UTC time.
For example, midnight UTC on Jan 1, 2014 is
2014-01-01T00:00:00Z

additionalInfo String Additional information associated with the

risk detection. This string value is
represented as a JSON object with the
quotations escaped.

appId String The unique identifier for the associated

application.

correlationId String Correlation ID of the sign-in activity

associated with the risk detection. This
property is null if the risk detection is not
associated with a sign-in activity.

detectedDateTime DateTimeOffset Date and time when the risk was detected.
The DateTimeOffset type represents date
and time information using ISO 8601 format
and is always in UTC time. For example,
midnight UTC on Jan 1, 2014 is 2014-01-
01T00:00:00Z .

detectionTimingType riskDetectionTimingType Timing of the detected risk , whether real-

time or offline. The possible values are:
notDefined , realtime , nearRealtime ,
offline , unknownFutureValue .

id String Unique identifier of the risk detection.

Inherited from entity.

ipAddress String Provides the IP address of the client from

where the risk occurred.

keyIds String collection The unique identifier for the key credential
associated with the risk detection.

lastUpdatedDateTime DateTimeOffset Date and time when the risk detection was
last updated.

location signInLocation Location from where the sign-in was

initiated.
Property Type Description

requestId String Request identifier of the sign-in activity

associated with the risk detection. This
property is null if the risk detection is not
associated with a sign-in activity. Supports
$filter ( eq ).

riskDetail riskDetail Details of the detected risk.

Note: Details for this property are only

available for Workload Identities Premium
customers. Events in tenants without this
license will be returned hidden .

The possible values are: none , hidden ,

adminConfirmedServicePrincipalCompromised ,
adminDismissedAllRiskForServicePrincipal .
Note that you must use the Prefer:
include-unknown-enum-members request
header to get the following value(s) in this
evolvable enum:
adminConfirmedServicePrincipalCompromised
, adminDismissedAllRiskForServicePrincipal .

riskEventType String The type of risk event detected. The possible

values are:
investigationsThreatIntelligence , generic ,
adminConfirmedServicePrincipalCompromised ,
suspiciousSignins , leakedCredentials ,
anomalousServicePrincipalActivity ,
maliciousApplication ,
suspiciousApplication .

riskLevel riskLevel Level of the detected risk.

Note: Details for this property are only

available for Workload Identities Premium
customers. Events in tenants without this
license will be returned hidden . The possible
values are: low , medium , high , hidden , none .

riskState riskState The state of a detected risky service principal

or sign-in activity. The possible values are:
none , dismissed , atRisk ,
confirmedCompromised .

servicePrincipalDisplayName String The display name for the service principal.

servicePrincipalId String The unique identifier for the service

principal. Supports $filter ( eq ).
 Property Type Description

source String Source of the risk detection. For example,

identityProtection .

tokenIssuerType tokenIssuerType Indicates the type of token issuer for the

detected sign-in risk. The possible values
are: AzureAD .

Relationships
None.

JSON representation
The following is a JSON representation of the resource.

JSON

"@odata.type": "#microsoft.graph.servicePrincipalRiskDetection",
"id": "String (identifier)",

"requestId": "String",

"correlationId": "String",

"riskEventType": "String",

"riskState": "String",

"riskLevel": "String",

"riskDetail": "String",

"source": "String",

"detectionTimingType": "String",

"activity": "String",

"tokenIssuerType": "String",

"ipAddress": "String",

"location": {

"@odata.type": "microsoft.graph.signInLocation"

},

"activityDateTime": "String (timestamp)",

"detectedDateTime": "String (timestamp)",

"lastUpdatedDateTime": "String (timestamp)",

"servicePrincipalId": "String",

"servicePrincipalDisplayName": "String",

"appId": "String",

"keyIds": [

"String"

],

"additionalInfo": "String"

riskyServicePrincipal resource type

Article • 01/06/2023 • 2 minutes to read

Namespace: microsoft.graph

Represents Azure AD service principals that are at-risk. Azure AD continually evaluates
service principal risk based on various signals and machine learning. This API provides
programmatic access to all at-risk service principals in your Azure AD tenant.

Inherits from entity.

Note: Using the riskyServicePrincipal API requires a Workload Identities Premium

license.

Methods
Method Return type Description

List riskyServicePrincipal collection List risky service principals and their

riskyServicePrincipals risk properties.

Get riskyServicePrincipal Get a specific risky service principal

riskyServicePrincipal and its risk properties.

dismiss None Dismiss the risk of a risky service

principal.

confirmCompromised None Confirm a risky service principal as

compromised.

List history riskyServicePrincipalHistoryItem Get the risk history of an Azure AD

collection service principal.

Properties
Property Type Description

appId String The globally unique identifier for the associated

application (its appId property), if any.

displayName String The display name for the service principal.

id String The unique identifier assigned to the service

principal at risk. Inherited from entity.
Property Type Description

isEnabled Boolean true if the service principal account is enabled;

otherwise, false .

isProcessing Boolean Indicates whether Azure AD is currently processing

the service principal's risky state.

riskDetail riskDetail Details of the detected risk.

Note: Details for this property are only available for

Workload Identities Premium customers. Events in
tenants without this license will be returned
hidden .

The possible values are: none , hidden ,

unknownFutureValue ,
adminConfirmedServicePrincipalCompromised ,
adminDismissedAllRiskForServicePrincipal . Note
that you must use the Prefer: include-unknown-
enum-members request header to get the following
value(s) in this evolvable enum:
adminConfirmedServicePrincipalCompromised ,
adminDismissedAllRiskForServicePrincipal .

riskLastUpdatedDateTime DateTimeOffset The date and time that the risk state was last
updated. The DateTimeOffset type represents date
and time information using ISO 8601 format and is
always in UTC time. For example, midnight UTC on
Jan 1, 2021 is 2021-01-01T00:00:00Z . Supports
$filter ( eq ).

riskLevel riskLevel Level of the detected risky workload identity. The

possible values are: low , medium , high , hidden ,
none , unknownFutureValue . Supports $filter ( eq ).

riskState riskState State of the service principal's risk. The possible

values are: none , confirmedSafe , remediated ,
dismissed , atRisk , confirmedCompromised ,
unknownFutureValue .

servicePrincipalType String Identifies whether the service principal represents

an Application , a ManagedIdentity , or a legacy
application ( socialIdp ). This is set by Azure AD
internally and is inherited from servicePrincipal.

Relationships
Relationship Type Description
 Relationship Type Description

history riskyServicePrincipalHistoryItem Represents the risk history of Azure AD

collection service principals.

JSON representation
The following is a JSON representation of the resource.

JSON

"@odata.type": "#microsoft.graph.riskyServicePrincipal",

"id": "String (identifier)",

"isEnabled": "Boolean",

"isProcessing": "Boolean",

"riskLastUpdatedDateTime": "String (timestamp)",

"riskLevel": "String",

"riskState": "String",

"riskDetail": "String",

"displayName": "String",

"appId": "String",

"servicePrincipalType": "String"

Azure Active Directory Identity

Protection Glossary
Article • 02/28/2023 • 6 minutes to read

At risk (User)
A user with one or more active risk detections.

Atypical sign-in location

A sign-in from a geographic location that is not typical for the specific user, similar
users, or the tenant.

Azure AD Identity Protection

A security module of Azure Active Directory that provides a consolidated view into risk
detections and potential vulnerabilities affecting an organization’s identities.

Conditional Access
A policy for securing access to resources. Conditional Access rules are stored in the
Azure Active Directory and are evaluated by Azure AD before granting access to the
resource. Example rules include restricting access based on user location, device health,
or user authentication method.

Credentials
Information that includes identification and proof of identification that is used to gain
access to local and network resources. Examples of credentials are user names and
passwords, smart cards, and certificates.

Event
A record of an activity in Azure Active Directory.

False-positive (risk detection)

A risk detection status set manually by an Identity Protection user, indicating that the
risk detection was investigated and was incorrectly flagged as a risk detection.

Identity
A person or entity that must be verified by means of authentication, based on criteria
such as password or a certificate.

Identity risk detection

Azure AD event that was flagged as anomalous by Identity Protection, and may indicate
that an identity has been compromised.

Ignored (risk detection)

A risk detection status set manually by an Identity Protection user, indicating that the
risk detection is closed without taking a remediation action.

Impossible travel from atypical locations

A risk detection triggered when two sign-ins for the same user are detected, where at
least one of them is from an atypical sign-in location, and where the time between the
sign-ins is shorter than the minimum time it would take to physically travel between
these locations.

Investigation
The process of reviewing the activities, logs, and other relevant information related to a
risk detection to decide whether remediation or mitigation steps are necessary,
understand if and how the identity was compromised, and understand how the
compromised identity was used.

Leaked credentials
A risk detection triggered when current user credentials (user name and password) are
found posted publicly in the Dark web by our researchers.

Mitigation
An action to limit or eliminate the ability of an attacker to exploit a compromised
identity or device without restoring the identity or device to a safe state. A mitigation
does not resolve previous risk detections associated with the identity or device.

Multifactor authentication
An authentication method that requires two or more authentication methods, which
may include something the user has, such a certificate; something the user knows, such
as user names, passwords, or pass phrases; physical attributes, such as a thumbprint;
and personal attributes, such as a personal signature.

Offline detection
The detection of anomalies and evaluation of the risk of an event such as sign-in
attempt after the fact, for an event that has already happened.

Policy condition
A part of a security policy, which defines the entities (groups, users, apps, device
platforms, Device states, IP ranges, client types) included in the policy or excluded from
it.

Policy rule
The part of a security policy that describes the circumstances that would trigger the
policy, and the actions taken when the policy is triggered.

Prevention
An action to prevent damage to the organization through abuse of an identity or device
suspected or know to be compromised. A prevention action does not secure the device
or identity, and does not resolve previous risk detections.

Privileged (user)
A user that at the time of a risk detection, had permanent or temporary admin
permissions to one or more resources in Azure Active Directory, such as a Global
Administrator, Billing Administrator, Service Administrator, User administrator, and
Password Administrator.
Real-time
See Real-time detection.

Real-time detection
The detection of anomalies and evaluation of the risk of an event such as sign-in
attempt before the event is allowed to proceed.

Remediated (risk detection)

A risk detection status set automatically by Identity Protection, indicating that the risk
detection was remediated using the standard remediation action for this type of risk
detection. For example, when the user password is reset, many risk detections that
indicate that the previous password was compromised are automatically remediated.

Remediation
An action to secure an identity or a device that were previously suspected or known to
be compromised. A remediation action restores the identity or device to a safe state,
and resolves previous risk detections associated with the identity or device.

Resolved (risk detection)

A risk detection status set manually by an Identity Protection user, indicating that the
user took an appropriate remediation action outside Identity Protection, and that the
risk detection should be considered closed.

Risk detection status

A property of a risk detection, indicating whether the event is active, and if closed, the
reason for closing it.

Risk detection type

A category for the risk detection, indicating the type of anomaly that caused the event
to be considered risky.

Risk level (risk detection)

An indication (High, Medium, or Low) of the severity of the risk detection to help
Identity Protection users prioritize the actions they take to reduce the risk to their
organization.

Risk level (sign-in)

An indication (High, Medium, or Low) of the likelihood that for a specific sign-in,
someone else is attempting to use the user’s identity.

Risk level (user compromise)

An indication (High, Medium, or Low) of the likelihood that an identity has been
compromised.

Risk level (vulnerability)

An indication (High, Medium, or Low) of the severity of the vulnerability to help Identity
Protection users prioritize the actions they take to reduce the risk to their organization.

Secure (identity)
Take remediation action such as a password change or machine reimaging to restore a
potentially compromised identity to an uncompromised state.

Security policy
A collection of policy rules and condition. A policy can be applied to entities such as
users, groups, apps, devices, device platforms, device states, IP ranges, and Auth2.0
client types. When a policy is enabled, it is evaluated whenever an entity included in the
policy is issued a token for a resource.

Sign in (v)
To authenticate to an identity in Azure Active Directory.

Sign-in (n)
The process or action of authenticating an identity in Azure Active Directory, and the
event that captures this operation.
Sign in from anonymous IP address
A risk detection triggered after a successful sign-in from IP address that has been
identified as an anonymous proxy IP address.

Sign in from infected device

A risk detection triggered when a sign-in originates from an IP address, which is known
to be used by one or more compromised devices, which are actively attempting to
communicate with a bot server.

Sign in from IP address with suspicious activity

A risk detection triggered after a successful sign-in from an IP address with a high
number of failed login attempts across multiple user accounts over a short period of
time.

Sign in from unfamiliar location

A risk detection triggered when a user successfully signs in from a new location (IP,
Latitude/Longitude, and ASN).

Sign-in risk
See Risk level (sign-in)

Sign-in risk policy

A Conditional Access policy that evaluates the risk to a specific sign-in and applies
mitigations based on predefined conditions and rules.

User compromise risk

See Risk level (user compromise)

User risk
See Risk level (user compromise).

User risk policy

A Conditional Access policy that considers the sign-in and applies mitigations based on
predefined conditions and rules.

Users flagged for risk

Users that have risk detections, which are either active or remediated

Vulnerability
A configuration or condition in Azure Active Directory, which makes the directory
susceptible to exploits or threats.

See also
Azure Active Directory Identity Protection

Additional resources
 Documentation

Microsoft 365 Defender integration with Microsoft Sentinel

Learn how using Microsoft 365 Defender together with Microsoft Sentinel lets you use Microsoft
Sentinel as your universal incidents queue while seamlessly applying Microsoft 365 Defender's
strengths to help investigate Microsoft 365 security incidents. Also, learn how to ingest Defender…

Microsoft Sentinel integration - Microsoft Defender for Cloud Apps

This article provides information integrating Microsoft Sentinel with Defender for Cloud Apps.

Quickstart: Accessing the Microsoft Defender Threat Intelligence (Defender TI) Portal
In this quickstart, learn how to configure your profile and preferences and access Defender TI’s help
resources using Microsoft Defender Threat Intelligence (Defender TI).

Azure Active Directory Identity Protection integration - Microsoft Defender for Cloud
Apps
This article provides information about how to leverage Identity Protection alerts in Defender for
Cloud Apps for hybrid risk detection.

Connect Microsoft 365 Defender data to Microsoft Sentinel

Learn how to ingest incidents, alerts, and raw event data from Microsoft 365 Defender into Microsoft
Sentinel.

Step 1. Plan for Microsoft 365 Defender operations readiness

The basics of planning for Microsoft 365 Defender operations readiness when integrating Microsoft
365 Defender into your security operations.
Azure security baseline for Microsoft Defender for Identity
The Microsoft Defender for Identity security baseline provides procedural guidance and resources for
implementing the security recommendations specified in the Azure Security Benchmark.

What is Microsoft Defender Threat Intelligence (Defender TI)?

In this overview article, learn about the main features that come with Microsoft Defender Threat
Intelligence (Defender TI).

Show 5 more

 Training

Learning paths and modules

Understand Microsoft 365 risk management - Training
Learn how Microsoft 365 identifies, assesses, responds to, and manages risks to protect customers
and the Microsoft 365 environment.

Learning certificate
Microsoft Certified: Identity and Access Administrator Associate - Certifications
The Microsoft identity and access administrator designs, implements, and operates an organization’s
identity and access management systems by using Microsoft Azure Active Directory (Azure AD), part
of Microsoft Entra. They configure and manage authentication and authorization of identities for…
What's new in Azure Active Directory?
Article • 03/30/2023 • 36 minutes to read

Get notified about when to revisit this page for updates by copying and pasting this
URL: https://learn.microsoft.com/api/search/rss?search=%22Release+notes+-
+Azure+Active+Directory%22&locale=en-us into your feed reader.

Azure AD receives improvements on an ongoing basis. To stay up to date with the most
recent developments, this article provides you with information about:

The latest releases

Known issues
Bug fixes
Deprecated functionality
Plans for changes

This page updates monthly, so revisit it regularly. If you're looking for items older than
six months, you can find them in Archive for What's new in Azure Active Directory.

March 2023

Public Preview - New provisioning connectors in the

Azure AD Application Gallery - March 2023
Type: New feature

Service category: App Provisioning

Product capability: 3rd Party Integration

We've added the following new applications in our App gallery with Provisioning
support. You can now automate creating, updating, and deleting of user accounts for
these newly integrated apps:

Acunetix 360
Akamai Enterprise Application Access
Ardoq
Torii

For more information about how to better secure your organization by using automated
user account provisioning, see: Automate user provisioning to SaaS applications with
Azure AD.
General Availability - Workload identity Federation for
Managed Identities
Type: New feature

Service category: Managed identities for Azure resources

Product capability: Developer Experience

Workload Identity Federation enables developers to use managed identities for their
software workloads running anywhere and access Azure resources without needing
secrets. Key scenarios include:

Accessing Azure resources from Kubernetes pods running in any cloud or on-
premises
GitHub workflows to deploy to Azure, no secrets necessary
Accessing Azure resources from other cloud platforms that support OIDC, such as
Google Cloud Platform.

For more information, see:

Workload identity federation.

Configure a user-assigned managed identity to trust an external identity provider
(preview)
Use Azure AD workload identity (preview) with Azure Kubernetes Service (AKS)

Public Preview - New My Groups Experience

Type: Changed feature

Service category: Group Management

Product capability: End User Experiences

A new and improved My Groups experience is now available at

https://www.myaccount.microsoft.com/groups . My Groups enables end users to easily
manage groups, such as finding groups to join, managing groups they own, and
managing existing group memberships. Based on customer feedback, the new My
Groups support sorting and filtering on lists of groups and group members, a full list of
group members in large groups, and an actionable overview page for membership
requests.
This experience replaces the existing My Groups experience at
https://www.mygroups.microsoft.com in May.

For more information, see: Update your Groups info in the My Apps portal .
Public preview - Customize tokens with Custom Claims
Providers
Type: New feature

Service category: Authentications (Logins)

Product capability: Extensibility

A custom claims provider lets you call an API and map custom claims into the token
during the authentication flow. The API call is made after the user has completed all
their authentication challenges, and a token is about to be issued to the app. For more
information, see: Custom authentication extensions (preview).

General Availability - Converged Authentication Methods

Type: New feature

Service category: MFA

Product capability: User Authentication

The Converged Authentication Methods Policy enables you to manage all authentication
methods used for MFA and SSPR in one policy, migrate off the legacy MFA and SSPR
policies, and target authentication methods to groups of users instead of enabling them
for all users in your tenant. For more information, see: Manage authentication methods.

General Availability - Provisioning Insights Workbook

Type: New feature

Service category: Provisioning

Product capability: Monitoring & Reporting

This new workbook makes it easier to investigate and gain insights into your
provisioning workflows in a given tenant. This includes HR-driven provisioning, cloud
sync, app provisioning, and cross-tenant sync.

Some key questions this workbook can help answer are:

How many identities have been synced in a given time range?

How many create, delete, update, or other operations were performed?
How many operations were successful, skipped, or failed?
What specific identities failed? And what step did they fail on?
For any given user, what tenants / applications were they provisioned or
deprovisioned to?
For more information, see: Provisioning insights workbook.

General Availability - Number Matching for Microsoft

Authenticator notifications
Type: Plan for Change

Service category: Microsoft Authenticator App

Product capability: User Authentication

Microsoft Authenticator app’s number matching feature has been Generally Available
since Nov 2022! If you haven't already used the rollout controls (via Azure portal Admin
UX and MSGraph APIs) to smoothly deploy number matching for users of Microsoft
Authenticator push notifications, we highly encourage you to do so. We previously
announced that we'll remove the admin controls and enforce the number match
experience tenant-wide for all users of Microsoft Authenticator push notifications
starting February 27, 2023. After listening to customers, we'll extend the availability of
the rollout controls for a few more weeks. Organizations can continue to use the
existing rollout controls until May 8, 2023, to deploy number matching in their
organizations. Microsoft services will start enforcing the number matching experience
for all users of Microsoft Authenticator push notifications after May 8, 2023. We'll also
remove the rollout controls for number matching after that date.

If customers don’t enable number match for all Microsoft Authenticator push
notifications prior to May 8, 2023, Authenticator users may experience inconsistent sign-
ins while the services are rolling out this change. To ensure consistent behavior for all
users, we highly recommend you enable number match for Microsoft Authenticator
push notifications in advance.

For more information, see: How to use number matching in multifactor authentication
(MFA) notifications - Authentication methods policy

Public Preview - IPv6 coming to Azure AD

Type: Plan for Change

Service category: Identity Protection

Product capability: Platform

Earlier, we announced our plan to bring IPv6 support to Microsoft Azure Active Directory
(Azure AD), enabling our customers to reach the Azure AD services over IPv4, IPv6 or
dual stack endpoints. This is just a reminder that we have started introducing IPv6
support into Azure AD services in a phased approach in late March 2023.
If you utilize Conditional Access or Identity Protection, and have IPv6 enabled on any of
your devices, you likely must take action to avoid impacting your users. For most
customers, IPv4 won't completely disappear from their digital landscape, so we aren't
planning to require IPv6 or to deprioritize IPv4 in any Azure AD features or services.
We'll continue to share additional guidance on IPv6 enablement in Azure AD at this link:
IPv6 support in Azure Active Directory

General Availability - Microsoft cloud settings for Azure

AD B2B
Type: New feature

Service category: B2B

Product capability: B2B/B2C

Microsoft cloud settings let you collaborate with organizations from different Microsoft
Azure clouds. With Microsoft cloud settings, you can establish mutual B2B collaboration
between the following clouds:

Microsoft Azure commercial and Microsoft Azure Government

Microsoft Azure commercial and Microsoft Azure China 21Vianet

For more information about Microsoft cloud settings for B2B collaboration., see:
Microsoft cloud settings.

Modernizing Terms of Use Experiences

Type: Plan for Change

Service category: Access Reviews

Product capability: AuthZ/Access Delegation

Starting July 2023, we're modernizing the following Terms of Use end user experiences
with an updated PDF viewer, and moving the experiences from
https://account.activedirectory.windowsazure.com to
https://myaccount.microsoft.com :

View previously accepted terms of use.

Accept or decline terms of use as part of the sign-in flow.

No functionalities will be removed. The new PDF viewer adds functionality and the
limited visual changes in the end-user experiences will be communicated in a future
update. If your organization has allow-listed only certain domains, you must ensure your
allowlist includes the domains ‘myaccount.microsoft.com’ and
‘*.myaccount.microsoft.com’ for Terms of Use to continue working as expected.

February 2023

General Availability - Expanding Privileged Identity

Management Role Activation across the Azure portal
Type: New feature

Service category: Privileged Identity Management

Product capability: Privileged Identity Management

Privileged Identity Management (PIM) role activation has been expanded to the Billing
and AD extensions in the Azure portal. Shortcuts have been added to Subscriptions
(billing) and Access Control (AD) to allow users to activate PIM roles directly from these
blades. From the Subscriptions blade, select View eligible subscriptions in the
horizontal command menu to check your eligible, active, and expired assignments. From
there, you can activate an eligible assignment in the same pane. In Access control (IAM)
for a resource, you can now select View my access to see your currently active and
eligible role assignments and activate directly. By integrating PIM capabilities into
different Azure portal blades, this new feature allows users to gain temporary access to
view or edit subscriptions and resources more easily.

For more information Microsoft cloud settings, see: Activate my Azure resource roles in
Privileged Identity Management.

General Availability - Follow Azure AD best practices with

recommendations
Type: New feature

Service category: Reporting

Product capability: Monitoring & Reporting

Azure AD recommendations help you improve your tenant posture by surfacing

opportunities to implement best practices. On a daily basis, Azure AD analyzes the
configuration of your tenant. During this analysis, Azure AD compares the data of a
recommendation with the actual configuration of your tenant. If a recommendation is
flagged as applicable to your tenant, the recommendation appears in the
Recommendations section of the Azure AD Overview.

This release includes our first 3 recommendations:

 Convert from per-user MFA to Conditional Access MFA
Migration applications from AD FS to Azure AD
Minimize MFA prompts from known devices

For more information, see:

What are Azure Active Directory recommendations?

Use the Azure AD recommendations API to implement Azure AD best practices for
your tenant

Public Preview - Azure AD PIM + Conditional Access

integration
Type: New feature

Service category: Privileged Identity Management

Product capability: Privileged Identity Management

Now you can require users who are eligible for a role to satisfy Conditional Access policy
requirements for activation: use specific authentication method enforced through
Authentication Strengths, activate from Intune compliant device, comply with Terms of
Use, and use 3rd party MFA and satisfy location requirements.

For more information, see: Configure Azure AD role settings in Privileged Identity
Management.

General Availability - More information on why a sign-in

was flagged as "unfamiliar"
Type: Changed feature

Service category: Identity Protection

Product capability: Identity Security & Protection

Unfamiliar sign-in properties risk detection now provides risk reasons as to which
properties are unfamiliar for customers to better investigate that risk.

Identity Protection now surfaces the unfamiliar properties in the Azure portal on UX and
in API as Additional Info with a user-friendly description explaining that the following
properties are unfamiliar for this sign-in of the given user.

There's no additional work to enable this feature, the unfamiliar properties are shown by
default. For more information, see: Sign-in risk.
General Availability - New Federated Apps available in
Azure AD Application gallery - February 2023
Type: New feature

Service category: Enterprise Apps

Product capability: 3rd Party Integration

In February 2023 we've added the following 10 new applications in our App gallery with
Federation support:

PROCAS , Tanium Cloud SSO, LeanDNA, CalendarAnything LWC , courses.work,

Udemy Business SAML, Canva, Kno2fy, IT-Conductor, ナレッジワーク(Knowledge Work),
Valotalive Digital Signage Microsoft 365 integration , Priority Matrix HIPAA , Priority
Matrix Government , Beable, Grain , DojoNavi, Global Validity Access Manager ,
FieldEquip , Peoplevine , Respondent, WebTMA, ClearIP , Pennylane, VsimpleSSO ,
Compliance Genie, Dataminr Corporate , Talon.

You can also find the documentation of all the applications from here
https://aka.ms/AppsTutorial .

For listing your application in the Azure AD app gallery, read the details here
https://aka.ms/AzureADAppRequest

Public Preview - New provisioning connectors in the

Azure AD Application Gallery - February 2023
Type: New feature

Service category: App Provisioning

Product capability: 3rd Party Integration

We've added the following new applications in our App gallery with Provisioning
support. You can now automate creating, updating, and deleting of user accounts for
these newly integrated apps:

Atmos

For more information about how to better secure your organization by using automated
user account provisioning, see: Automate user provisioning to SaaS applications with
Azure AD.

January 2023
Public Preview - Cross-tenant synchronization
Type: New feature

Service category: Provisioning

Product capability: Collaboration

Cross-tenant synchronization allows you to set up a scalable and automated solution for
users to access applications across tenants in your organization. It builds upon the Azure
AD B2B functionality and automates creating, updating, and deleting B2B users. For
more information, see: What is cross-tenant synchronization? (preview).

Public Preview - Devices option Self-Help Capability for

Pending Devices
Type: New feature

Service category: Device Access Management

Product capability: End User Experiences

In the All Devices options under the registered column, you can now select any pending
devices you have, and it opens a context pane to help troubleshoot why the device may
be pending. You can also offer feedback on if the summarized information is helpful or
not. For more information, see: Pending devices in Azure Active Directory.

General Availability - Apple Watch companion app

removed from Authenticator for iOS
Type: Deprecated

Service category: Identity Protection

Product capability: Identity Security & Protection

In the January 2023 release of Authenticator for iOS, there's no companion app for
watchOS due to it being incompatible with Authenticator security features, meaning you
aren't able to install or use Authenticator on Apple Watch. This change only impacts
Apple Watch, so you can still use Authenticator on your other devices. For more
information, see: Common questions about the Microsoft Authenticator app .

General Availability - New Federated Apps available in

Azure AD Application gallery - January 2023
Type: New feature

Service category: Enterprise Apps

Product capability: 3rd Party Integration

In January 2023 we've added the following 10 new applications in our App gallery with
Federation support:

MINT TMS, Exterro Legal GRC Software Platform, SIX.ONE Identity Access Manager ,
Lusha, Descartes, Travel Management System , Pinpoint (SAML), my.sdworx.com, itopia
Labs , Better Stack .

You can also find the documentation of all the applications from here
https://aka.ms/AppsTutorial .

For listing your application in the Azure AD app gallery, read the details here
https://aka.ms/AzureADAppRequest

Public Preview - New provisioning connectors in the

Azure AD Application Gallery - January 2023
Type: New feature

Service category: App Provisioning

Product capability: 3rd Party Integration

We've added the following new applications in our App gallery with Provisioning
support. You can now automate creating, updating, and deleting of user accounts for
these newly integrated apps:

SurveyMonkey Enterprise

For more information about how to better secure your organization by using automated
user account provisioning, see: Automate user provisioning to SaaS applications with
Azure AD.

Public Preview - Azure AD cloud sync new user

experience
Type: Changed feature

Service category: Azure AD Connect Cloud Sync

Product capability: Identity Governance

Try out the new guided experience for syncing objects from AD to Azure AD using Azure
AD Cloud Sync in Azure portal. With this new experience, Hybrid Identity Administrators
can easily determine which sync engine to use for their scenarios and learn more about
the various options they have with our sync solutions. With a rich set of tutorials and
videos, customers are able to learn everything about Azure AD cloud sync in one single
place.

This experience helps administrators walk through the different steps involved in setting
up a cloud sync configuration and an intuitive experience to help them easily manage it.
Admins can also get insights into their sync configuration by using the "Insights" option,
which integrates with Azure Monitor and Workbooks.

For more information, see:

Create a new configuration for Azure AD Connect cloud sync

Attribute mapping in Azure AD Connect cloud sync
Azure AD cloud sync insights workbook

Public Preview - Support for Directory Extensions using

Azure AD cloud sync
Type: New feature

Service category: Provisioning

Product capability: Azure AD Connect Cloud Sync

Hybrid IT Admins now can sync both Active Directory and Azure AD Directory Extensions
using Azure AD Cloud Sync. This new capability adds the ability to dynamically discover
the schema for both Active Directory and Azure AD, allowing customers to map the
needed attributes using Cloud Sync's attribute mapping experience.

For more information on how to enable this feature, see: Cloud Sync directory
extensions and custom attribute mapping

December 2022

Public Preview - Windows 10+ Troubleshooter for

Diagnostic Logs
Type: New feature

Service category: Audit

Product capability: Monitoring & Reporting

This feature analyzes uploaded client-side logs, also known as diagnostic logs, from a
Windows 10+ device that is having an issue(s) and suggests remediation steps to
resolve the issue(s). Admins can work with end user to collect client-side logs, and then
upload them to this troubleshooter in the Entra Portal. For more information, see:
Troubleshooting Windows devices in Azure AD.

General Availability - Multiple Password-less Phone Sign-

ins for iOS Devices
Type: New feature

Service category: Authentications (Logins)

Product capability: User Authentication

End users can now enable password-less phone sign-in for multiple accounts in the
Authenticator App on any supported iOS device. Consultants, students, and others with
multiple accounts in Azure AD can add each account to Microsoft Authenticator and use
password-less phone sign-in for all of them from the same iOS device. The Azure AD
accounts can be in the same tenant or different tenants. Guest accounts aren't
supported for multiple account sign-ins from one device.

End users aren't required to enable the optional telemetry setting in the Authenticator
App. For more information, see: Enable passwordless sign-in with Microsoft
Authenticator.

Public Preview(refresh) - Updates to Conditional Access

templates
Type: Changed feature

Service category: Conditional Access

Product capability: Identity Security & Protection

Conditional Access templates provide a convenient method to deploy new policies

aligned with Microsoft recommendations. In total, there are 14 Conditional Access policy
templates, filtered by five different scenarios; secure foundation, zero trust, remote work,
protect administrators, and emerging threats.

In this Public Preview refresh, we've enhanced the user experience with an updated
design and added four new improvements:

Admins can create a Conditional Access policy by importing a JSON file.

Admins can duplicate existing policy.
Admins can view more detailed policy information.
Admins can query templates programmatically via MSGraph API.

For more information, see: Conditional Access templates (Preview).

Public Preview - Admins can restrict their users from
creating tenants
Type: New feature

Service category: User Access Management

Product capability: User Management

The ability for users to create tenants from the Manage Tenant overview has been
present in Azure AD since almost the beginning of the Azure portal. This new capability
in the User Settings option allows admins to restrict their users from being able to
create new tenants. There's also a new Tenant Creator role to allow specific users to
create tenants. For more information, see Default user permissions.

General availability - Consolidated App launcher (My

Apps) settings and new preview settings
Type: New feature

Service category: My Apps

Product capability: End User Experiences

We have consolidated relevant app launcher settings in a new App launchers section in
the Azure and Entra portals. The entry point can be found under Enterprise applications,
where Collections used to be. You can find the Collections option by selecting App
launchers. In addition, we've added a new App launchers Settings option. This option
has some settings you may already be familiar with like the Microsoft 365 settings. The
new Settings options also have controls for previews. As an admin, you can choose to
try out new app launcher features while they are in preview. Enabling a preview feature
means that the feature turns on for your organization. This enabled feature reflects in
the My Apps portal, and other app launchers for all of your users. To learn more about
the preview settings, see: End-user experiences for applications.

Public preview - Converged Authentication Methods

Policy
Type: New feature

Service category: MFA

Product capability: User Authentication

The Converged Authentication Methods Policy enables you to manage all authentication
methods used for MFA and SSPR in one policy. You can migrate off the legacy MFA and
SSPR policies, and target authentication methods to groups of users instead of enabling
them for all users in the tenant. For more information, see: Manage authentication
methods for Azure AD.

General Availability - Administrative unit support for

devices
Type: New feature

Service category: Directory Management

Product capability: AuthZ/Access Delegation

You can now use administrative units to delegate management of specified devices in
your tenant by adding devices to an administrative unit. You're also able to assign built-
in, and custom device management roles, scoped to that administrative unit. For more
information, see: Device management.

Public Preview - Frontline workers using shared devices

can now use Microsoft Edge and Yammer apps on
Android
Type: New feature

Service category: N/A

Product capability: SSO

Companies often provide mobile devices to frontline workers that need are shared
between shifts. Microsoft’s shared device mode allows frontline workers to easily
authenticate by automatically signing users in and out of all the apps that have enabled
this feature. In addition to Microsoft Teams and Managed Home Screen being generally
available, we're excited to announce that Microsoft Edge and Yammer apps on Android
are now in Public Preview.

For more information on deploying frontline solutions, see: frontline deployment

documentation .

For more information on shared-device mode, see: Azure Active Directory Shared Device
Mode documentation.

For steps to set up shared device mode with Intune, see: Intune setup blog .

Public preview - New provisioning connectors in the

Azure AD Application Gallery - December 2022
Type: New feature

Service category: App Provisioning

Product capability: 3rd Party Integration

We've added the following new applications in our App gallery with Provisioning
support. You can now automate creating, updating, and deleting of user accounts for
these newly integrated apps:

GHAE

For more information about how to better secure your organization by using automated
user account provisioning, see: Automate user provisioning to SaaS applications with
Azure AD.

General Availability - On-premises application

provisioning
Type: Changed feature

Service category: Provisioning

Product capability: Outbound to On-premises Applications

Azure AD supports provisioning users into applications hosted on-premises or in a

virtual machine, without having to open up any firewalls. If your application supports
SCIM , or you've built a SCIM gateway to connect to your legacy application, you can
use the Azure AD Provisioning agent to directly connect with your application and
automate provisioning and deprovisioning. If you have legacy applications that don't
support SCIM and rely on an LDAP user store, or a SQL database, Azure AD can support
those as well.

General Availability - New Federated Apps available in

Azure AD Application gallery - December 2022
Type: New feature

Service category: Enterprise Apps

Product capability: 3rd Party Integration

In December 2022 we've added the following 44 new applications in our App gallery
with Federation support:

Bionexo IDM , SMART Meeting Pro , Venafi Control Plane – Datacenter, HighQ,
Drawboard PDF , ETU Skillsims, TencentCloud IDaaS, TeamHeadquarters Email Agent
OAuth , Verizon MDM , QRadar SOAR, Tripwire Enterprise, Cisco Unified
Communications Manager, Howspace , Flipsnack SAML, Albert , Altinget.no , Coveo
Hosted Services, Cybozu(cybozu.com), BombBomb , VMware Identity Service,
HexaSync , Trifecta Teams , VerosoftDesign , Mazepay , Wistia, Begin.AI , WebCE,
Dream Broker Studio , PKSHA Chatbot, PGM-BCP , ChartDesk SSO, Elsevier SP,
GreenCommerce IdentityServer , Fullview , Aqua Platform, SpedTrack, Pinpoint ,
Darzin Outlook Add-in , Simply Stakeholders Outlook Add-in , tesma, Parkable, Unite
Us

You can also find the documentation of all the applications from here
https://aka.ms/AppsTutorial ,

For listing your application in the Azure AD app gallery, read the details here
https://aka.ms/AzureADAppRequest

ADAL End of Support Announcement

Type: N/A

Service category: Other

Product capability: Developer Experience

As part of our ongoing initiative to improve the developer experience, service reliability,
and security of customer applications, we'll end support for the Azure Active Directory
Authentication Library (ADAL). The final deadline to migrate your applications to Azure
Active Directory Authentication Library (MSAL) has been extended to June 30, 2023.

Why are we doing this?

As we consolidate and evolve the Microsoft Identity platform, we're also investing in
making significant improvements to the developer experience and service features that
make it possible to build secure, robust and resilient applications. To make these
features available to our customers, we needed to update the architecture of our
software development kits. As a result of this change, we’ve decided that the path
forward requires us to sunset Azure Active Directory Authentication Library. This allows
us to focus on developer experience investments with Azure Active Directory
Authentication Library.

What happens?
We recognize that changing libraries isn't an easy task, and can't be accomplished
quickly. We're committed to helping customers plan their migrations to Microsoft
Authentication Library and execute them with minimal disruption.
 In June 2020, we announced the 2-year end of support timeline for ADAL .
In December 2022, we’ve decided to extend the Azure Active Directory
Authentication Library end of support to June 2023.
Through the next six months (January 2023 – June 2023) we continue informing
customers about the upcoming end of support along with providing guidance on
migration.
On June 2023 we'll officially sunset Azure Active Directory Authentication Library,
removing library documentation and archiving all GitHub repositories related to
the project.

How to find out which applications in my tenant are

using Azure Active Directory Authentication Library?
Refer to our post on Microsoft Q&A for details on identifying Azure Active Directory
Authentication Library apps with the help of Azure Workbooks.

If I’m using Azure Active Directory Authentication Library,

what can I expect after the deadline?
There will be no new releases (security or otherwise) to the library after June 2023.
We won't accept any incident reports or support requests for Azure Active
Directory Authentication Library. Azure Active Directory Authentication Library to
Microsoft Authentication Library migration support would continue.
The underpinning services continue working and applications that depend on
Azure Active Directory Authentication Library should continue working.
Applications, and the resources they access, are at increased security and reliability
risk due to not having the latest updates, service configuration, and enhancements
made available through the Microsoft Identity platform.

What features can I only access with Microsoft

Authentication Library?
The number of features and capabilities that we're adding to Microsoft Authentication
Library libraries are growing weekly. Some of them include:

Support for Microsoft accounts (MSA)

Support for Azure AD B2C accounts
Handling throttling
Proactive token refresh and token revocation based on policy or critical events for
Microsoft Graph and other APIs that support Continuous Access Evaluation (CAE)
 Auth broker support with device-based conditional access policies
Azure AD hardware-based certificate authentication (CBA) on mobile
System browsers on mobile devices
And more. For an up-to-date list, refer to our
migration guide.

How to migrate?
To make the migration process easier, we published a comprehensive guide that
documents the migration paths across different platforms and programming languages.

In addition to the Azure Active Directory Authentication Library to Microsoft

Authentication Library update, we recommend migrating from Azure AD Graph API to
Microsoft Graph. This change enables you to take advantage of the latest additions and
enhancements, such as CAE, across the Microsoft service offering through a single,
unified endpoint. You can read more in our Migrate your apps from Azure AD Graph to
Microsoft Graph guide. You can post any questions to Microsoft Q&A or Stack
Overflow .

November 2022

General Availability - Use Web Sign-in on Windows for

password-less recovery with Temporary Access Pass
Type: Changed feature

Service category: N/A

Product capability: User Authentication

The Temporary Access Pass can now be used to recover Azure AD-joined PCs when the
EnableWebSignIn policy is enabled on the device. This is useful for when your users
don't know, or have, a password. For more information, see:
Authentication/EnableWebSignIn.

Public Preview - Workload Identity Federation for

Managed Identities
Type: New feature

Service category: Managed identities for Azure resources

Product capability: Developer Experience

Developers can now use managed identities for their software workloads running
anywhere, and for accessing Azure resources, without needing secrets. Key scenarios
include:

Accessing Azure resources from Kubernetes pods running on-premises or in any

cloud.
GitHub workflows to deploy to Azure, no secrets necessary.
Accessing Azure resources from other cloud platforms that support OIDC, such as
Google Cloud.

For more information, see:

Configure a user-assigned managed identity to trust an external identity provider

(preview)
Workload identity federation
Use an Azure AD workload identity (preview) on Azure Kubernetes Service (AKS)

General Availability - Authenticator on iOS is FIPS 140

compliant
Type: New feature

Service category: Microsoft Authenticator App

Product capability: User Authentication

Authenticator version 6.6.8 and higher on iOS will be FIPS 140 compliant for all Azure
AD authentications using push multi-factor authentications (MFA), Password-less Phone
Sign-In (PSI), and time-based one-time pass-codes (TOTP). No changes in configuration
are required in the Authenticator app or Azure portal to enable this capability. For more
information, see: FIPS 140 compliant for Azure AD authentication.

General Availability - New Federated Apps available in

Azure AD Application gallery - November 2022
Type: New feature

Service category: Enterprise Apps

Product capability: 3rd Party Integration

In November 2022, we've added the following 22 new applications in our App gallery
with Federation support
Adstream, Databook, Ecospend IAM , Digital Pigeon, Drawboard Projects, Vellum ,
Veracity , Microsoft OneNote to Bloomberg Note Sync , DX NetOps Portal, itslearning
Outlook integration , Tranxfer, Occupop , Nialli Workspace , Tideways , SOWELL ,
Prewise Learning , CAPTOR for Intune , wayCloud Platform , Nura Space Meeting
Room , Flexopus Exchange Integration , Ren Systems , Nudge Security

You can also find the documentation of all the applications from here
https://aka.ms/AppsTutorial ,

For listing your application in the Azure AD app gallery, read the details here
https://aka.ms/AzureADAppRequest

General Availability - New provisioning connectors in the

Azure AD Application Gallery - November 2022
Type: New feature

Service category: App Provisioning

Product capability: 3rd Party Integration

We've added the following new applications in our App gallery with Provisioning
support. You can now automate creating, updating, and deleting of user accounts for
these newly integrated apps:

Keepabl
Uber

For more information about how to better secure your organization by using automated
user account provisioning, see: Automate user provisioning to SaaS applications with
Azure AD.

Public Preview - Dynamic Group pause functionality

Type: New feature

Service category: Group Management

Product capability: Directory

Admins can now pause, and resume, the processing of individual dynamic groups in the
Entra Admin Center. For more information, see: Create or update a dynamic group in
Azure Active Directory.

Public Preview - Enabling extended customization

capabilities for sign-in and sign-up pages in Company
Branding capabilities.
Type: New feature

Service category: Authentications (Logins)

Product capability: User Authentication

Update the Azure AD and Microsoft 365 sign-in experience with new company branding
capabilities. You can apply your company’s brand guidance to authentication
experiences with pre-defined templates. For more information, see: Configure your
company branding.

Public Preview - Enabling customization capabilities for

the Self-Service Password Reset (SSPR) hyperlinks, footer
hyperlinks and browser icons in Company Branding.
Type: New feature

Service category: Directory Management

Product capability: Directory

Update the company branding functionality on the Azure AD/Microsoft 365 sign-in
experience to allow customizing Self Service Password Reset (SSPR) hyperlinks, footer
hyperlinks and browser icon. For more information, see: Configure your company
branding.

General Availability - Soft Delete for Administrative Units

Type: New feature

Service category: Directory Management

Product capability: Directory

Administrative Units now support soft deletion. Admins can now list, view properties of,
or restore deleted Administrative Units using the Microsoft Graph. This functionality
restores all configuration for the Administrative Unit when restored from soft delete,
including memberships, admin roles, processing rules, and processing rules state.

This functionality greatly enhances recoverability and resilience when using

Administrative Units. Now, when an Administrative Unit is accidentally deleted, you can
restore it quickly to the same state it was at time of deletion. This removes uncertainty
around configuration and makes restoration quick and easy. For more information, see:
List deletedItems (directory objects).
Public Preview - IPv6 coming to Azure AD
Type: Plan for change

Service category: Identity Protection

Product capability: Platform

With the growing adoption and support of IPv6 across enterprise networks, service
providers, and devices, many customers are wondering if their users can continue to
access their services and applications from IPv6 clients and networks. Today, we’re
excited to announce our plan to bring IPv6 support to Microsoft Azure Active Directory
(Azure AD). This allows customers to reach the Azure AD services over both IPv4 and
IPv6 network protocols (dual stack).
For most customers, IPv4 won't completely
disappear from their digital landscape, so we aren't planning to require IPv6 or to de-
prioritize IPv4 in any Azure Active Directory features or services.
We'll begin introducing
IPv6 support into Azure AD services in a phased approach, beginning March 31, 2023.
We have guidance that is specifically for Azure AD customers who use IPv6 addresses
and also use Named Locations in their Conditional Access policies.

Customers who use named locations to identify specific network boundaries in their
organization need to:

1. Conduct an audit of existing named locations to anticipate potential risk.

2. Work with your network partner to identify egress IPv6 addresses in use in your
environment.
3. Review and update existing named locations to include the identified IPv6 ranges.

Customers who use Conditional Access location based policies to restrict and secure
access to their apps from specific networks need to:

1. Conduct an audit of existing Conditional Access policies to identify use of named

locations as a condition to anticipate potential risk.
2. Review and update existing Conditional Access location based policies to ensure
they continue to meet your organization’s security requirements.

We continue to share additional guidance on IPv6 enablement in Azure AD at this link:

https://aka.ms/azureadipv6 .

October 2022

General Availability - Upgrade Azure AD Provisioning

agent to the latest version (version number: 1.1.977.0)
Type: Plan for change

Service category: Provisioning

Product capability: Azure AD Connect Cloud Sync

Microsoft stops support for Azure AD provisioning agent with versions 1.1.818.0 and
below starting Feb 1,2023. If you're using Azure AD cloud sync, make sure you have the
latest version of the agent. You can view info about the agent release history here. You
can download the latest version here

You can find out which version of the agent you're using as follows:

1. Going to the domain server that you have the agent installed
2. Right-click on the Microsoft Azure AD Connect Provisioning Agent app
3. Select on “Details” tab and you can find the version number there

７ Note

Azure Active Directory (AD) Connect follows the Modern Lifecycle Policy. Changes
for products and services under the Modern Lifecycle Policy may be more frequent
and require customers to be alert for forthcoming modifications to their product or
service.
Product governed by the Modern Policy follow a continuous support and
servicing model. Customers must take the latest update to remain supported. For
products and services governed by the Modern Lifecycle Policy, Microsoft's policy is
to provide a minimum 30 days' notification when customers are required to take
action in order to avoid significant degradation to the normal use of the product or
service.

General Availability - Add multiple domains to the same

SAML/Ws-Fed based identity provider configuration for
your external users
Type: New feature

Service category: B2B

Product capability: B2B/B2C

An IT admin can now add multiple domains to a single SAML/WS-Fed identity provider
configuration to invite users from multiple domains to authenticate from the same
identity provider endpoint. For more information, see: Federation with SAML/WS-Fed
identity providers for guest users.
General Availability - Limits on the number of configured
API permissions for an application registration enforced
starting in October 2022
Type: Plan for change

Service category: Other

Product capability: Developer Experience

In the end of October, the total number of required permissions for any single
application registration must not exceed 400 permissions across all APIs. Applications
exceeding the limit are unable to increase the number of permissions configured for.
The existing limit on the number of distinct APIs for permissions required remains
unchanged and may not exceed 50 APIs.

In the Azure portal, the required permissions list is under API Permissions within specific
applications in the application registration menu. When using Microsoft Graph or
Microsoft Graph PowerShell, the required permissions list is in the
requiredResourceAccess property of an application entity. For more information, see:
Validation differences by supported account types (signInAudience).

Public Preview - Conditional access Authentication

strengths
Type: New feature

Service category: Conditional Access

Product capability: User Authentication

We're announcing Public preview of Authentication strength, a Conditional Access

control that allows administrators to specify which authentication methods can be used
to access a resource. For more information, see: Conditional Access authentication
strength (preview). You can use custom authentication strengths to restrict access by
requiring specific FIDO2 keys using the Authenticator Attestation GUIDs (AAGUIDs), and
apply this through conditional access policies. For more information, see: FIDO2 security
key advanced options.

Public Preview - Conditional access authentication

strengths for external identities
Type: New feature

Service category: B2B

Product capability: B2B/B2C

You can now require your business partner (B2B) guests across all Microsoft clouds to
use specific authentication methods to access your resources with Conditional Access
Authentication Strength policies. For more information, see: Conditional Access:
Require an authentication strength for external users.

Generally Availability - Windows Hello for Business, Cloud

Kerberos Trust deployment
Type: New feature

Service category: Authentications (Logins)

Product capability: User Authentication

We're excited to announce the general availability of hybrid cloud Kerberos trust, a new
Windows Hello for Business deployment model to enable a password-less sign-in
experience. With this new model, we’ve made Windows Hello for Business easier to
deploy than the existing key trust and certificate trust deployment models by removing
the need for maintaining complicated public key infrastructure (PKI), and Azure Active
Directory (AD) Connect synchronization wait times. For more information, see: Hybrid
Cloud Kerberos Trust Deployment.

General Availability - Device-based conditional access on

Linux Desktops
Type: New feature

Service category: Conditional Access

Product capability: SSO

This feature empowers users on Linux clients to register their devices with Azure AD,
enroll into Intune management, and satisfy device-based Conditional Access policies
when accessing their corporate resources.

Users can register their Linux devices with Azure AD

Users can enroll in Mobile Device Management (Intune), which can be used to
provide compliance decisions based upon policy definitions to allow device based
conditional access on Linux Desktops
If compliant, users can use Microsoft Edge Browser to enable Single-Sign on to
M365/Azure resources and satisfy device-based Conditional Access policies.

For more information, see:

Azure AD registered devices.
Plan your Azure Active Directory
device deployment
General Availability - Deprecation of Azure Active
Directory Multi-Factor Authentication.
Type: Deprecated

Service category: MFA

Product capability: Identity Security & Protection

Beginning September 30, 2024, Azure Active Directory Multi-Factor Authentication

Server deployments will no longer service multi-factor authentication (MFA) requests,
which could cause authentications to fail for your organization. To ensure uninterrupted
authentication services, and to remain in a supported state, organizations should
migrate their users’ authentication data to the cloud-based Azure Active Directory
Multi-Factor Authentication service using the latest Migration Utility included in the
most recent Azure Active Directory Multi-Factor Authentication Server update. For more
information, see: Migrate from MFA Server to Azure AD Multi-Factor Authentication.

Public Preview - Lifecycle Workflows is now available

Type: New feature

Service category: Lifecycle Workflows

Product capability: Identity Governance

We're excited to announce the public preview of Lifecycle Workflows, a new Identity
Governance capability that allows customers to extend the user provisioning process,
and adds enterprise grade user lifecycle management capabilities, in Azure AD to
modernize your identity lifecycle management process. With Lifecycle Workflows, you
can:

Confidently configure and deploy custom workflows to onboard and offboard

cloud employees at scale replacing your manual processes.
Automate out-of-the-box actions critical to required Joiner and Leaver scenarios
and get rich reporting insights.
Extend workflows via Logic Apps integrations with custom tasks extensions for
more complex scenarios.

For more information, see: What are Lifecycle Workflows? (Public Preview).

Public Preview - User-to-Group Affiliation

recommendation for group Access Reviews
Type: New feature

Service category: Access Reviews

Product capability: Identity Governance

This feature provides Machine Learning based recommendations to the reviewers of

Azure AD Access Reviews to make the review experience easier and more accurate. The
recommendation detects user affiliation with other users within the group, and applies
the scoring mechanism we built by computing the user’s average distance with other
users in the group. For more information, see: Review recommendations for Access
reviews.

General Availability - Group assignment for

SuccessFactors Writeback application
Type: New feature

Service category: Provisioning

Product capability: Outbound to SaaS Applications

When configuring writeback of attributes from Azure AD to SAP SuccessFactors

Employee Central, you can now specify the scope of users using Azure AD group
assignment. For more information, see: Tutorial: Configure attribute write-back from
Azure AD to SAP SuccessFactors.

General Availability - Number Matching for Microsoft

Authenticator notifications
Type: New feature

Service category: Microsoft Authenticator App

Product capability: User Authentication

To prevent accidental notification approvals, admins can now require users to enter the
number displayed on the sign-in screen when approving an MFA notification in the
Microsoft Authenticator app. We've also refreshed the Azure portal admin UX and
Microsoft Graph APIs to make it easier for customers to manage Authenticator app
feature roll-outs. As part of this update we have also added the highly requested ability
for admins to exclude user groups from each feature.

The number matching feature greatly up-levels the security posture of the Microsoft
Authenticator app and protects organizations from MFA fatigue attacks. We highly
encourage our customers to adopt this feature applying the rollout controls we have
built. Number Matching will begin to be enabled for all users of the Microsoft
Authenticator app starting February 27 2023.

For more information, see: How to use number matching in multifactor authentication
(MFA) notifications - Authentication methods policy.

General Availability - Additional context in Microsoft

Authenticator notifications
Type: New feature

Service category: Microsoft Authenticator App

Product capability: User Authentication

Reduce accidental approvals by showing users additional context in Microsoft

Authenticator app notifications. Customers can enhance notifications with the following
steps:

Application Context: This feature shows users which application they're signing
into.
Geographic Location Context: This feature shows users their sign-in location based
on the IP address of the device they're signing into.

The feature is available for both MFA and Password-less Phone Sign-in notifications and
greatly increases the security posture of the Microsoft Authenticator app. We've also
refreshed the Azure portal Admin UX and Microsoft Graph APIs to make it easier for
customers to manage Authenticator app feature roll-outs. As part of this update, we've
also added the highly requested ability for admins to exclude user groups from certain
features.

We highly encourage our customers to adopt these critical security features to reduce
accidental approvals of Authenticator notifications by end users.

For more information, see: How to use additional context in Microsoft Authenticator
notifications - Authentication methods policy.

New Federated Apps available in Azure AD Application

gallery - October 2022
Type: New feature

Service category: Enterprise Apps

Product capability: 3rd Party Integration

In October 2022 we've added the following 15 new applications in our App gallery with
Federation support:

Unifii , WaitWell Staff App , AuthParency , Oncospark Code Interceptor , Thread

Legal Case Management , e2open CM-Global, OpenText XM Fax and XM SendSecure,
Contentkalender, Evovia, Parmonic , mailto.wiki , JobDiva Azure SSO , Mapiq, IVM
Smarthub, Span.zone – SSO and Read-only , RecruiterPal , Broker groupe Achat
Solutions, Philips SpeechLive , Crayon, Cytric, Notate , ControlDocumentario ,
Intuiflow , Valence Security Platform, Skybreathe® Analytics

You can also find the documentation of all the applications from here
https://aka.ms/AppsTutorial ,

For listing your application in the Azure AD app gallery, read the details here
https://aka.ms/AzureADAppRequest

Public preview - New provisioning connectors in the

Azure AD Application Gallery - October 2022
Type: New feature

Service category: App Provisioning

Product capability: 3rd Party Integration

You can now automate creating, updating, and deleting user accounts for these newly
integrated apps:

LawVu

For more information about how to better secure your organization by using automated
user account provisioning, see: Automate user provisioning to SaaS applications with
Azure AD.