- **C2** – Require compliant devices
- **C3** – Require trusted locations
To use the Conditional Access Auth Contexts create or modify your Conditional Access policies. Examples policies could be:
- All users signing-into this web application must successfully complete 2FA for auth context ID **C1**.
- All users signing into this web application must successfully complete 2FA and also access the app from a defined IP address range for auth context ID **C3**.
> [!NOTE]
> The Conditional Access auth context values are declared and maintained separately from applications. It is not advisable for applications to take hard dependency on auth context ids. IT Administrators usually craft Conditional Access policies as they have a better understanding of the resources available. For example, IT admins would know of how many users are equipped to use 2FA for MFA and can ensure that Conditional Access policies that require 2FA are scoped correctly.
> Similarly, if the application is used in multiple tenants, the auth context ids in use could be different and, in some cases, not available at all.
**Second**: The developers of an application planning to use Conditional Access auth context are advised to first provide the application admins or IT admins a means to map potential sensitive actions to auth context IDs. The steps roughly being:
1. Identity actions in the code that can be made available to map against auth context Ids.
1. Build a screen in the admin portal of the app (or an equivalent functionality) that IT admins can use to map sensitive actions against an available auth context ID.
1. See the code sample, [Use the Conditional Access Auth Context to perform step-up authentication](https://github.com/Azure-Samples/ms-identity-ca-auth-context/blob/main/README.md) for an example on how it's done.
These steps are the changes that you need to carry in your code base. The steps broadly comprise of
- **C2** – Require compliant devices
- **C3** – Require trusted locations
To use the Conditional Access Auth Contexts, create or modify your Conditional Access policies. Examples policies could be:
- All users signing-into this web application must successfully complete 2FA for auth context ID **C1**.
- All users signing into this web application must successfully complete 2FA and also access the app from a defined IP address range for auth context ID **C3**.
> [!NOTE]
> The Conditional Access auth context values are declared and maintained separately from applications. It is not advisable for applications to take hard dependency on auth context ids. IT Administrators usually craft Conditional Access policies as they have a better understanding of the resources available.
> Similarly, if the application is used in multiple tenants, the auth context ids in use could be different and, in some cases, not available at all.
**Second**: The developers of an application planning to use Conditional Access auth context are advised to first provide the application admins or IT admins a means to map potential sensitive actions to auth context IDs. The steps roughly being:
1. Identity actions in the code that can be made available to map against auth context Ids.
1. Build a screen in the admin portal of the app (or an equivalent functionality) that IT admins can use to map sensitive actions against an available auth context ID.
1. See the code sample, [Use the Conditional Access Auth Context to perform step-up authentication](https://github.com/Azure-Samples/ms-identity-ca-auth-context/blob/main/README.md) for an example.
These steps are the changes that you need to carry in your code base. The steps broadly comprise of