Configure CA Policy to Restrict User Register Device to Azure AD
Overview
On some occasions, the company prefers users to avoid registering their personal devices to Azure AD. This is because when users sign into Microsoft 1st party apps or perform MFA using their authenticator app, there is a possibility that their personal devices may be automatically registered to AAD. Microsoft potentially provides options for users to register their devices, as shown in the following picture. Selecting “No, sign into this app only” is the only way to prevent users from further registering their devices to AAD.

Although, the above 1st party app sign-in behavior enables end-users to achieve Single Sign-On (SSO) during login. For enterprises, the increasing number of personal devices can pose management challenges. Additionally, if the company has implemented a device-based CA policy to restrict customer logins, these personal devices are likely to bypass the policy.
Since Azure AD does not have native functionality to strictly block user device registration, this post will focus on a workaround that leverages the new feature, Authentication Strengths, on Microsoft CAP. This workaround can indirectly fulfill the discussed requirements.
Overview of Azure Active Directory authentication strength – Microsoft Entra | Microsoft Learn
1. Configure the CA policy set
1.1 Configure the Authentication Strengths
Open our Azure Active Directory, click Security blade > Conditional Access > Authentication strengths
Click New authentication strength in order to customize our own combination of authentication methods.

We will get a new tab pop up on the right-hand side, let’s click Temporary Access Pass (One-time use). n the deep dive section, we will delve further into the reasons behind our choice of Temporary Access Pass as our authentication strength.

1.2 Configure the CA Policy
After our customized Authentication Strengths configured, let’s create our CA policy.

Configure “Cloud apps or actions” and select “user actions”. Then choose “Register or join devices.”

In the condition > locations section, select “Any location” and then exclude the company network segment (or the trusted named locations).

Lastly, in the Grant, we will select Require authentication strength, and select the customized method we configured on section 1.1

2. Deep Dive
2.1 Limitations of “Register or join devices”
As you may have noticed, our approach is to require MFA for registering or joining devices rather than blocking access altogether. For further information on this topic, please refer to the following documentation:
“Authentication strengths” can be considered as an additional layer of MFA. This feature empowers us to select MFA operations that users are unable to independently complete, thereby providing greater control over device registration.
2.2 Why we use TAP as our Authentication strengths
My previous post briefly introduced what TAP is and its purpose:
Enable Web Sign-in with Temporary Access Pass – Ruian’s Tech Troubleshooting Toolbox (ruianding.com)
The reason we chose TAP here is because only tenant administrators can create TAPs for users to use. Additionally, in emergency situations where users are not physically present in the company premises but require urgent device registration, TAP can be used to fulfill this need.
If the administrator neglects to create the TAP (Temporary Access Pass) for a user who is registering a device outside the company, the user will encounter the following message when attempting to register the device to Azure AD:

