> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/prevention-tools/cloud-scan/results.md).
# Reading results
The `Cloud Services` > `Results` dashboard shows the security level of your cloud infrastructure and the misconfigurations to address.
## Dashboard header
The top of the results page gives you an at-a-glance overview of your cloud security posture.
### Health status
The health status indicates the overall state of your cloud infrastructure security. It tells you immediately whether your configuration requires attention.
### Score
Your cloud security score is displayed out of 100. A score of 100 means no misconfigurations were detected. The lower the score, the more misconfigurations need to be addressed. The score is calculated based on the number and severity of detected misconfigurations across all your connected providers.
A score of 100 or empty results are usually correct: the scan ran and found nothing (small environment, or an Entra ID tenant with few users). The page may say "Results will be displayed here once the scan is complete" even though the scan is done: check the last scan date.
### Graph
The graph shows the evolution of your score over time, so you can track whether your cloud security posture is improving or degrading. Use it to monitor the impact of remediation actions you've taken.
## Misconfigurations
Only detected misconfigurations are displayed in the results table. Each misconfiguration shows:
* **Name:** the misconfiguration detected
* **Criticality:** Critical, High, Medium, or Low
* **Description:** an explanation of the issue and its potential impact
Click a misconfiguration to access the remediation steps required to resolve it.
Misconfigurations cannot be excluded, marked as accepted risk or marked as false positives today. This includes shared mailboxes, emergency accounts and users protected some other way: the Cloud scan shows everything it finds.
## MFA findings (Entra ID)
**Users with MFA Disabled** lists active accounts that have no MFA method registered in Entra ID. That is not the same as "MFA enforced": a user covered by a policy who has not registered a method yet, often an account that never signs in, still appears. The full list is in the finding's resources and in the export.
These accounts are not counted:
* accounts with sign-in blocked
* Entra Connect sync accounts
* guests, which have their own finding: `No MFA Policy for Guest Users`
If you enforce MFA with Conditional Access, the finding is dropped only if a policy is **On** (not report-only), includes **All users** (a group does not count), requires MFA (grant control or authentication strength), and can be read (`Policy.Read.All` granted). Otherwise, the listed users really have no MFA: register MFA for them, or cover them with an "All users" policy.
* **Emergency (break-glass) accounts:** they cannot be excluded from the finding. Excluding them from your "All users" MFA policy is fine: the policy still counts and the finding disappears.
* **Shared mailboxes and meeting rooms:** they appear because they can still sign in. Block sign-in for them in Microsoft 365 (Microsoft recommends this for shared mailboxes): they disappear at the next scan.
To check MFA status per user in Azure, see [MFA status](/prevention-tools/cloud-scan/azure/mfa-status.md).
## Other findings
* **Shadow Admin Users:** accounts that hold one of these Entra roles without being Global Administrator: Application, Cloud Application, Authentication, Privileged Authentication, Privileged Role, Password, Helpdesk or User Administrator. These roles let someone become admin, so dedicated admin accounts are flagged on purpose.
* **High Percentage of Privileged Users:** only appears when there are at least 4 privileged accounts and they are more than 10% of all users.
* **Root Account Used Recently (AWS):** the AWS root account was used to sign in during the last 90 days.
## Exporting results
Export the results table in CSV or XLS format using the `...` button at the right of the search bar.
{% hint style="info" %}
To fix a finding, see the [Cloud Scan remediation guide](https://docs.stoik.io/cyber-best-practices/vulnerability-remediation-guides/cloud-scan) for step-by-step fixes per provider (Microsoft Azure / Entra ID / Microsoft 365, AWS, GCP).
{% endhint %}
## Troubleshooting
A fixed misconfiguration is still reported
* **Has the scan run since?** See [The results haven't updated](#the-results-havent-updated).
* **Can Stoïk see the fix?** Conditional Access changes are invisible without `Policy.Read.All`, see [Policy.Read.All cannot be granted](https://docs.stoik.io/prevention-tools/cloud-scan/pages/o078MxFZGrJa3CHRphbh#policy.read.all-cannot-be-granted-or-a-permission-is-missing).
* **Does the fix match what is checked?** For example, a Conditional Access policy for a group of users does not count as "All users", and a custom role that nobody is assigned to does not count.
* **Is it a known limitation?** These findings can stay even when the setting is in place, and you can ignore them:
* GCP `Log Metric Filter Doesn't Exist…` / `Alerts Doesn't Exist For…`
* Azure `No Administering Resource Locks Role` when the role is given through PIM (eligible assignment): only permanent assignments are seen.
The results haven't updated
Check the last scan date, then:
* **Stoïk's access was removed or changed.** Before each scan, Stoïk checks that it still has access. After 3 failed checks in a row, the scans of that provider stop. Once the access is fixed, do the setup again to restart the scans.
* **The environment is very large.** A scan stops after 1 hour, and very large environments can hit that limit.
Restart the scan from `Cloud Scan` > `Settings`. If the date still has not changed the next day, contact .
---
# 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.stoik.io/prevention-tools/cloud-scan/results.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.
