Security findings
The security checks run against every tenant, the posture score, fixing findings one at a time or in bulk, accepting a risk, and the CIS, NIST, SCuBA and Essential Eight frameworks.
After every sync, Tenvara checks each tenant against the same baseline of security checks, using only what sync read. Nothing is guessed: if something could not be read, the check says Not known.
Findings across every tenant
Cloud > Findings lists every check with its Severity, Area, how many tenants are Failing (as a bar, for example 3 / 4), how many objects are Affected and how many tenants have Accepted the risk. Filter by severity, area and state. Checks that do not apply to a tenant are left out of its count, so a check can show 2 / 2 while four tenants are connected.

Click a check to open a side panel with why it matters, how to fix it, and each tenant's result with Fix and Accept risk buttons beside it.
When the AI readiness feature is on for a tenant, its checks appear in the same list under the AI readiness area. See AI readiness.
A tenant's findings
Open a tenant and go to Findings. The top shows:
- The posture score out of 100, with counts of Failing, Warnings, Passing and Not known, and For information when the tenant has results of checks shown for information only.
- Microsoft's Secure Score for comparison.
- Check again, which reads the tenant's security settings and sign-ins now.
- A Trend chart of the posture score and Secure Score, daily. The chart marks the day the check rules changed ("Rules changed in ...") and breaks the line there, so a jump in the score that day is explained rather than read as progress or decline.

Below, switch between Checks and Frameworks. The checks are grouped into areas, each with its own count across the top: Identity and access, Applications, Email, Auditing, Data and sharing and, where that feature is on, AI readiness. The Review N fixes button beside them lists every failing check of the tenant that Tenvara can fix, so you can go through them in one sitting.
Results
| Result | Meaning |
|---|---|
| Pass | The check is met |
| Warning | Mostly met, with something to look at |
| Fail | Not met |
| Not known | Tenvara could not read what it needs. Never counted as a pass |
| Not applicable | The tenant does not have the licence the check needs, such as Entra ID P1 or Defender for Office 365 |
| Accepted | Someone accepted the risk until a date |
| For information | A check shown for information only (severity Info) that did not pass. Its tooltip says what the check found. It is never scored, never alerts and is not counted as failing |
The score
Each check carries points by severity: critical 40, high 25, medium 12, low 5, and Info none. A pass earns all of them, a warning half, a fail none. Not known, not applicable and accepted checks count on neither side, and a tenant whose only results are for information has no score.
A result can be graded below the check's own severity when what it found is less serious. For example, Users can only consent to low-risk apps is a High check, but Microsoft's managed default consent setting is a Low warning. The result is scored and alerted at its own grade, which the finding and the security report show, unless you set the check's severity yourself in the check settings.
What is checked
A selection of the checks, by area:
- Identity and access: administrators must use MFA for every sign-in, administrators use phishing-resistant MFA, every privileged administrator has registered MFA, everyone must use MFA for every sign-in, all users can complete MFA, per-user MFA is off, text, call and email codes are turned off, sign-in risk and user risk policies are on, legacy authentication is blocked, device code sign-in is blocked, two to four Global Administrators, emergency access accounts are excluded from Conditional Access, Authenticator shows the app and location when asking to approve, Temporary Access Pass and self-service password reset, idle Microsoft 365 web sessions sign out, and sign-in from countries the business never works in is blocked.
- Accounts and directory: administrator accounts are cloud only, directory sync has run recently, password hash sync is on for a hybrid tenant, directory sync is not blocked by Conditional Access, guests cannot browse the directory or invite other guests, stale guests, shared mailboxes cannot sign in, no accounts unused for 90 days and blocked users do not hold licences. These show under Identity and access.
- Applications: users can only consent to low-risk apps (graded by the consent policy the tenant actually uses), high privilege apps are reviewed (an app marked Sanctioned on the SaaS apps page counts as reviewed), admin consent requests are on, users cannot register apps or create tenants, multi-tenant app registrations have the property lock on, and Conditional Access covers workload identities.
- Email: automatic forwarding to outside addresses is blocked, no mailbox forwards mail outside without approval, no suspicious inbox rules, mail flow rules do not send mail outside or skip filtering, SMTP AUTH is off for the whole organisation, anti-phishing stops spoofing and impersonation, everyone is covered by a preset security policy, dangerous attachment types are blocked and malware is purged after delivery, no allow list lets mail skip spam filtering, Safe Attachments, Safe Links, DMARC, SPF, DKIM, and Outlook tags mail from outside.
- Auditing: the unified audit log is on, mailbox auditing is on for the organisation, no account bypasses mailbox auditing, and audit log retention fits the need.
- Data and sharing: SharePoint and OneDrive don't allow open "Anyone" links, Anyone links expire within 30 days and are view only, the default sharing link is for specific people and view only, guest access to sites and OneDrive expires, guests cannot reshare files, site and group creation is limited, a leaver's OneDrive is kept long enough to recover files, outsiders can't start Teams chats with staff, and anonymous people wait in the Teams lobby.
Some checks are shown For information only: Exchange PowerShell is limited to people who manage Exchange, The sign-in page shows the company's branding and Office IP addresses are defined as trusted locations. They tell you how the tenant is set up without counting against it.
A few checks worth knowing in more detail:
- Users can only consent to low-risk apps reads the tenant's actual consent policy. Any app allowed fails High; Microsoft's verified publishers, low impact setting passes (with a Medium warning naming any extra permission classified as low impact beyond basic sign-in); Microsoft's managed default is a Low warning; a custom policy is judged by what it really allows; consent turned off passes and says whether admin consent requests are on.
- Automatic forwarding to outside addresses is blocked fails High only when the Default policy, or one covering everyone, allows forwarding outside. Policies scoped to named people are listed as allowed exceptions, a policy left on Automatic is a Low warning, and a block on the Default remote domain counts.
- DMARC stops forged mail for every domain needs a policy of quarantine or reject (p=none is a Medium warning). A parked domain, one that sends no mail, needs p=reject and an SPF record of exactly "v=spf1 -all". DKIM is not judged for parked domains or for mail sent from another platform.
- Safe Attachments blocks malware judges the policies actually in force, and its fix turns on Safe Documents only where the tenant is licensed for it. Safe Links with only Microsoft's built-in protection is a Medium warning.
- No suspicious inbox rules treats the same rule (same name, conditions and actions) on more than five mailboxes as one deployed rule, shown once as a Low item with who made it, rather than as many compromised mailboxes. A mailbox forward outside that is wanted can be marked as expected on the Forwarding view, and a forward the forwarding policy already blocks is Low.
- No account bypasses mailbox auditing lists each account set to bypass mailbox auditing. It has no Fix, because a tool may rely on the bypass and it is decided per account.
- Audit log retention fits the need compares how long audit records are kept with the days you need. It uses the same setting as AI readiness (How long audit records are kept on the Checks tab of Settings > Microsoft 365, per customer where needed), so the two never disagree.
- Admin consent requests are on has a fix that turns Microsoft's admin consent workflow on. You choose who reviews the requests when the fix runs: keep the reviewers set now, a role that can grant consent (Global Administrator, Cloud Application Administrator, Application Administrator or Privileged Role Administrator) or named people holding one. Requests expire after 30 days. Turning requests off is not counted as loosening, but the preview says that people who cannot consent will have no way to ask.
- Multi-tenant app registrations have the property lock on looks at the tenant's own app registrations that other tenants use. Without Microsoft's app instance property lock, an administrator account taken over in any of those tenants could add credentials to the app there. No lock fails Medium, a lock that leaves sensitive properties open warns Low and names them. The fix puts the full lock on each open app, and its undo puts each lock back as it was.
- Conditional Access covers workload identities needs Microsoft Entra Workload ID Premium; without it the check is shown as not applicable, never as failing. With it, an enforced policy that blocks risky service principals passes and a report-only one warns. The fix deploys the Block high-risk workload identities template, report-only first.
- No accounts unused for 90 days counts only successful sign-ins, so an account that only sees failed password attempts is still inactive. An inactive administrator raises the result to Medium.
Note: Emergency access (break-glass) accounts are recognised, not configured: an enabled Global Administrator left out of every enforced Conditional Access policy. One rule finds them for every check and fix. They are left out of the MFA and legacy authentication checks and of inactive accounts, so a well-run tenant does not fail for following Microsoft's advice, and the Conditional Access fixes and Block sign-in never touch them.
Looking at one check
Click a check to open its side panel. You see the result and severity, the summary, Why it matters, every Affected user, mailbox, app or policy, How to fix it, the Evidence the check used, and its History (when it was last checked, the status since, when it first failed and every change of status). Accept risk and Fix are at the top of the panel. A check that names a Conditional Access policy links to it, so you can open the policy's detail, effect and history from the finding (see Conditional Access policies in detail).

Fixing a finding
Many checks have a Fix button. It runs the matching change through the change log, with a preview first.
- Press Fix on the check (in the list or in its side panel).
- Read the preview. For Conditional Access, the policy is created report-only, with the tenant's emergency access accounts left out: it records what it would do in the sign-in logs and stops nobody.
- Confirm. The tenant's security settings are read again shortly afterwards and the check runs again.

Fixes include deploying Conditional Access templates, showing the app and location in Authenticator requests, the registration campaign and Temporary Access Pass, limiting user consent, app registration and guest access, tightening SharePoint sharing and site creation, keeping a leaver's OneDrive longer, switching on the audit log, mailbox auditing, the external sender tag and Safe Attachments, blocking automatic forwarding, and DKIM per domain. Some checks have per-object fixes, such as blocking sign-in for an inactive account or disabling a suspicious rule.
Some checks are fixed by hand, for example the number of Global Administrators, phishing-resistant MFA for administrators (enforcing it would lock out every administrator without a passkey) and accounts that bypass mailbox auditing. Teams checks have Open admin centre instead where Teams settings cannot be changed app-only.
Fixes that ask first
- Enforcing a Conditional Access policy asks Who is left out of the enforced policy: Leave the emergency access accounts out or Keep the exclusions as they are. The preview shows what the policy did in report-only over the last 30 days: the sign-ins it would have blocked or asked more of, and the accounts behind them. While the choice is open, an alert's fix button sends you to the tenant's Findings tab to enforce from there.
- Limit user consent to low-risk apps sets Microsoft's verified publishers, low impact policy, or Turn user consent off instead. It keeps the Teams and chat owner consent Microsoft says to keep, and the preview says apps already consented to keep working and whether admin consent requests are on (and with how many reviewers).
- Choose how to limit sharing (SharePoint) offers New and existing guests (recommended), Keep Anyone links: 30 days, view only (when Anyone links are on), Existing guests only and Only people in the organisation. Before anything changes, the preview says how many Anyone links are in use and that they stop working within about an hour.
- Change Teams external access (the fix for Outsiders can't start Teams chats with staff) stops personal accounts starting chats and blocks trial tenants, and keeps your federation with other organisations as it is. Turning federation off is a separate, explicit choice on the form.
- Restrict guest access changes only the setting that fails, and its preview says what each choice affects.
- Block automatic forwarding outside sets only the Default policy (and any covering everyone), keeps exceptions scoped to named people, and the preview lists every forward outside that would start bouncing.
- Block sign-in (inactive accounts, shared mailboxes) is refused for emergency access accounts, and asks you to type the account's name before blocking an administrator or an account an app or device signs in as.
Exchange PowerShell is shown for information and has no Fix: limiting it safely depends on roles Tenvara does not read.
Tip: Every tenant setting a fix changes is recorded with its value before, so it can be put back from the change log. See Making changes safely.
Accepting a risk
When a finding is deliberate (for example the customer archives mail with their own tool), accept it rather than leaving it red.
- Press Accept risk on the check for that tenant.
- Enter Why is it accepted?: who agreed and why. Everyone sees this beside the finding.
- Choose Until, at most two years ahead.
- Press Accept risk.

While accepted, the check shows as accepted everywhere and counts on neither side of the score, and its alert is cleared. It counts again after the date or when the acceptance is withdrawn.
Frameworks
The Frameworks view maps the checks to four frameworks: CIS Microsoft 365 Foundations Benchmark (3.1), NIST Cybersecurity Framework (2.0), CISA SCuBA Microsoft 365 baselines and ACSC Essential Eight (Maturity Level 2). Each shows a score with how many controls are met, partly met, not met and to check by hand.

Choose a framework to list its controls with the Section, Status and the checks that evidence each. A control no check covers is marked to check by hand and never counts as met. A control with a check that is not known is never counted as met either.
To see every framework's controls against every tenant at once, open Governance and compliance > Microsoft 365 frameworks.
Check settings
Administrators can change how checks behave in Settings > Microsoft 365, the Checks tab. Each check shows why it matters, its Area, any Thresholds it uses, its Default severity and how it is Judged as. Open a check that has thresholds to change them. Switch a check off to stop it being run, scored or alerted on anywhere, or change its severity to change its weight in the score and how loud its alert is. Setting a check to Info shows it for information only: it is never scored, never alerts, and any alert it has open is resolved at the next check.

Alerts
A check that starts failing raises one alert at its severity, or at the result's own grade when that is lower (critical as critical, high and medium as warnings, low as information), cleared when it passes, stops applying, is switched off or gets an exception. It is raised once per failing spell, so resolving the alert while a fix is pending does not page you again. Checks shown for information never raise an alert.
When a check is taken away or replaced by a better one, its results leave the findings, the counts and the score, and its open alerts are resolved with a note saying why (and which check replaces it). Its history stays. A replacement starts fresh: accepted risks and settings of the old check are not carried over, so someone decides again.
Was this page helpful?
Thanks for the feedback.