> 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/tenant/security-simulator/situations.md). # Sign-in Situations Test a set of realistic sign-ins against a tenant's Conditional Access policies without anyone signing in. This tab takes a set of realistic sign-ins and runs each one through Microsoft's Conditional Access What If API against the tenant's real policies. Nothing signs in and nothing changes: the API only reports what the policies would do. It is one of the three tabs of [Security Simulations](/user-documentation/tenant/security-simulator.md), and needs a single tenant selected. {% hint style="warning" %} The tenant needs an Entra ID P1 or P2 licence. Without one there are no Conditional Access policies to evaluate, and the tab shows a warning instead of results. The risk-based situations also need Entra ID P2; without it they are left out, and the summary line says how many. {% endhint %} ## Sign in as Every situation is evaluated as a real account from the tenant. CIPP picks one account for each group when the tab loads, and this card lets you change them. Changing any field re-evaluates straight away, and the fields reset to CIPP's own picks when you switch tenants. | Field | Description | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Admin account | The account used for the admin situations. Only enabled, non-guest accounts that hold a privileged directory role are offered. CIPP's own pick prefers an admin who is not excluded from any Conditional Access policy. | | Standard user account | The account used for the standard user situations. Guests and disabled accounts are left out. CIPP's own pick prefers a licensed account that holds no admin role and is not excluded from any Conditional Access policy. | | Guest account | The account used for the guest situations. | | Foreign country | Where the "sign-in from a foreign country" situations come from. Defaults to Russia. | ## Situations Situations are grouped by who is signing in: Admin accounts, Standard users, and Guests. Each row shows the result of the evaluation: | Result | Meaning | | ------------------------------ | -------------------------------------------------------------------------------------- | | Blocked | A policy blocks the sign-in. | | Requires *controls* | The policies demand controls, such as MFA or a compliant device, before letting it in. | | Allowed - *controls* satisfied | The sign-in gets in because it already meets what the policies ask for. | | Allowed | No policy applies to the sign-in. | | Not evaluated | The situation could not be run, and the row says why. | Each situation also has an expected result: most should be blocked, and some only need to be challenged for MFA or a compliant device. A protected row (green) shows the policies that stopped it. A row that gets through (red) explains which control is missing, and names any report-only policy that would have stopped it if it were enforced. Where the missing control matches a Conditional Access template, **Deploy a CA template** opens [CA Templates](/user-documentation/tenant/conditional/list-template.md). A situation shows Not evaluated when the tenant has no suitable account for that group, for example a tenant with no guest accounts, or when the evaluation itself fails. The line above the list totals the sign-ins evaluated, how many are protected, how many get through (and how many of those only because a policy is report-only), how many could not be evaluated, and how many risk-based situations were left out for lack of Entra ID P2. | Group | Situations | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Admin accounts | Unmanaged device at a known location, sign-in from a foreign country, sign-in from a hosting-provider address, device-code flow, legacy authentication client, high sign-in risk, unmanaged macOS device, desktop client on an unmanaged device | | Standard users | Unmanaged device in a browser, sign-in from a foreign country, device-code flow, legacy Exchange ActiveSync, other legacy client, high sign-in risk, high user risk, elevated insider risk, unmanaged Android device, unmanaged iOS device, desktop client on an unmanaged device | | Guests | Browser access at a known location, sign-in from a foreign country, legacy authentication client, unmanaged device in a browser, device-code flow, high sign-in risk, authentication transfer | The high sign-in risk, high user risk, and elevated insider risk situations are the risk-based ones that need Entra ID P2. *** ## 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.cipp.app/user-documentation/tenant/security-simulator/situations.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.