> For the complete documentation index, see [llms.txt](https://docs.cipp.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cipp.app/user-documentation/identity/administration/users/user/conditional-access.md). # Conditional Access This page runs a Conditional Access "what if" evaluation for the user: you describe a sign-in, and CIPP reports which of the tenant's policies would apply to it and why. It is the quickest way to answer questions like whether a new policy would lock someone out, or why an existing one is not catching the sign-ins you expected. {% hint style="info" %} The evaluation is a simulation. No sign-in takes place, nothing is written to the tenant, and the user is not affected in any way, so it is safe to run against a live account at any time. The results table reports each policy's state alongside the outcome, so a policy that would apply in report-only mode can be told apart from one that would be enforced. {% endhint %} ## Test Conditional Access Policy {% stepper %} {% step %} ### Select the application to test The application the simulated sign-in is directed at, chosen from the service principals in the tenant. This is the only required field. {% endstep %} {% step %} ### Set any optional conditions Anything left blank is simply not included in the evaluation, so start with the application alone and add conditions as you narrow down the behaviour you are chasing. The options are described below. {% endstep %} {% step %} ### Select **Test policies** The evaluation runs against Entra ID and the results replace whatever is in the table. {% endstep %} {% step %} ### Review the results Work through the table on the right, described in #ca-test-results. {% endstep %} {% endstepper %} ## Optional Parameters | Field | Description | | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Select the device platform to test | The operating system the sign-in comes from: Windows, iOS, Android, MacOS or Linux. | | Select the client application type to test | How the sign-in reaches Microsoft 365: All, Browser, Mobile apps and desktop clients, Exchange ActiveSync, EAS supported, or Other clients. Legacy authentication policies usually turn on this condition. | | Select the authentication flow | Whether the sign-in uses a flow that policies can target separately: None, Device code flow or Authentication transfer. | | Test from this IP | The address the sign-in appears to originate from, entered in the form `8.8.8.8`. Use this to check policies built on named locations. | | Test from this country | The country the sign-in appears to originate from. | | Select the sign-in risk level of the user signing in | The risk Entra ID Protection would assign to the sign-in itself: Low, Medium, High or None. | | Select the user risk level of the user signing in | The risk Entra ID Protection would assign to the account: Low, Medium, High or None. | {% hint style="info" %} The two risk conditions describe risk the evaluation should assume, not risk the account currently carries. Setting them is how you test a risk-based policy without waiting for Entra ID Protection to flag someone, and the policies themselves still need the licensing that risk-based Conditional Access requires before they will do anything in production. {% endhint %} ## CA Test Results Each of the tenant's Conditional Access policies is listed with what the evaluation decided about it. | Column | Description | | ---------------- | ------------------------------------------------------------------------------------------------------------------------- | | Display Name | The name of the policy. | | State | Whether the policy is enabled, disabled, or enabled in report-only mode. | | Policy Applies | Whether the policy would apply to the sign-in as described. | | Analysis Reasons | Why the evaluation reached that conclusion, which for a policy that does not apply names the condition that ruled it out. | {% hint style="info" %} Analysis Reasons is the column that earns its keep. A policy showing as not applying will usually name the single condition responsible, so it points straight at the assignment or condition to change rather than leaving you to compare the policy against your test settings by hand. {% endhint %} *** ## Feature Requests / Ideas We value your feedback and ideas. Please raise any [feature requests](https://github.com/CyberDrain/CIPP/issues/new?template=feature.yml) on GitHub. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.cipp.app/user-documentation/identity/administration/users/user/conditional-access.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.