Severity, blast radius, and what to fix first
What the two numbers on a finding mean, why sorting by severity alone gives you the wrong queue, and the order we would work in with the reasoning for each position.
Every finding carries two numbers, and they are frequently confused. Severity says how bad this kind of weakness is in general. Blast radius says how much of your business it touches in particular. Neither one on its own gives you a sensible order of work, which is why this article exists.
- Severity
- One of critical, high, medium, low or info, set by the check rather than by your data — though a few checks escalate themselves.
ZQ-M365-PRIV-001is high when you have three or four Global Administrators and critical at five or more, on the grounds that at five in a small business the role has stopped meaning anything. - Blast radius
- How many people or systems a compromise — or a change — would affect. A blast radius of 1 is treated very differently from a blast radius of "everyone". It is a count of real named objects, not an estimate.
- Info
- Not a mild problem. An info finding is usually a statement about what we could not see.
ZQ-M365-PRIV-013says no Global Administrator could be identified, and adds that this is almost certainly a permission limit on our side rather than a real absence — so treat that whole section as unverified rather than clean.
What is in the pack
Your report was produced by check pack m365-2026.08.1, which contains 82 checks across nine categories. The categories are not equally sized, and the sizes tell you something about where risk concentrates in a small Microsoft 365 estate.
| Category | Checks | What it examines |
|---|---|---|
| Privilege | 13 | Who holds administrative power, how much, how many of them there are, and how well protected each one is. The highest-value category in the pack. |
| Authentication | 12 | Second factors, which methods are registered, whether they resist real-time phishing, password policy, and self-service reset. |
| Access policy | 11 | Conditional Access — the rules that decide who may sign in from where, on what, and with what proof. Includes whether the rules are actually switched on. |
| Account hygiene | 11 | Dormant accounts, disabled accounts that still hold roles, guests who have not signed in for months, accounts that have never signed in at all. |
| Exposure | 9 | Mail leaving the organisation quietly: external forwarding, concealment inbox rules, anonymous sharing links, mailbox delegation. |
| Device | 8 | Which computers reach company data, which are managed, which are personal, and which you cannot see inside. |
| Application | 7 | Third-party applications with standing access to company data, and the consent-phishing attack that creates them. |
| Logging | 6 | Whether anything is keeping a record of what happens, how long it is kept, and whether it would survive the incident it is meant to document. |
| Licensing | 5 | Paid seats nobody uses, and capabilities you are already paying for and not using. |
The severity mix across the pack is deliberately narrow at the top. Twelve checks can produce a critical finding. If everything were critical, the word would carry no information and the report would be a wall of red that nobody works through.
| Severity | Checks | What it means for your queue |
|---|---|---|
| critical | 12 | Work these first, in the order below. There should be very few. |
| high | 21 | This week. Most of these are one approval each. |
| medium | 31 | This month. Largely hygiene, and largely cheap once you are in the habit. |
| low | 8 | When convenient. Real, but not what an attacker would reach for. |
| info | 9 | Read them. Several are statements about what could not be assessed. |
Why severity alone gives you the wrong queue
Severity is a property of a kind of weakness. Your queue needs to reflect three things severity does not know about: how many people are affected, how long the fix takes, and whether the fix will break something.
A critical finding affecting one dormant account and a medium finding affecting every member of staff are not comparable on severity. Neither are two critical findings where one takes two minutes per person and the other takes an afternoon and a conversation with your accountant. So the report sorts within each pile by blast radius, widest first, and then stably by an internal key so the order does not reshuffle between reads. The order below then layers cost and disruption on top of that.
The order we would work in
This is the queue, with the reasoning for each position. It is built on the principle that the first hour of work should remove the most risk for the least disruption — not the most findings.
1. Administrators without a second factor
About two minutes per person, and Microsoft's own data puts the reduction in account-compromise risk above 99%. Nothing else in your report has that ratio of effect to effort. A password alone protects these accounts today, and passwords are guessed, reused, and bought in bulk from other companies' breaches — so a correct password is complete access, with no alarm and no further work required. Do this before you read anything else.
2. An application that can read everyone's email, or send as your staff
Second because it is already happening rather than merely possible, and because no amount of work on passwords or second factors touches it. The application holds its own access: changing a password does not revoke it, and a passkey does not affect it. Withdrawing a grant is one tap and is restorable in one tap, so the cost of getting it wrong is low and recoverable. See An application can read everyone's email.
3. Admin accounts used for daily email
About ten minutes per person. Third rather than first only because it takes longer and because a second factor on the same account buys you real protection in the meantime. The combination of a tier-zero role and a mailbox is what turns one bad click into the end of the business rather than an inconvenience. See Why we flag admin accounts used for daily email.
4. Concealment or external-forwarding inbox rules
A rule that hides incoming mail from the person it was sent to, or copies it outside the business, is not a misconfiguration. It is usually evidence that a mailbox is already compromised, which makes this finding a live incident wearing a posture finding's clothes. Fourth because it is rarer than the three above, and top of the list the moment it appears.
5. No Conditional Access rule requiring a second factor from administrators
Fifth, and worth understanding as distinct from position one. Position one is about who has registered a second factor; this is about whether anything requires them to use it. Registration without enforcement means an attacker with a correct password may never be asked for one. Check that any existing rule is switched on rather than report-only before concluding you are covered.
6. Legacy sign-in methods still in use
A large security win that will break something, and the platform does not know what. That is why it is here rather than higher: the work is finding out which printer, scanner, meeting-room device or old laptop depends on it. Turning it off blind on a Friday is how a well-intentioned security improvement becomes a Monday outage. The change to block it at the policy level sits in the approve pile; turning the protocol off entirely sits in decide, deliberately.
7. Guest accounts holding administrator roles
A guest is somebody signed in from another organisation, under their own employer's security settings rather than yours. An administrator role on a guest puts your tenant behind somebody else's front door — and the partner or supplier is usually smaller and less defended than you. Rated critical; seventh in the queue only because most organisations do not have one, and those that do can fix it in minutes.
8. An emergency access account
Not an attack so much as a trap, and it moves up this list the moment you start doing the things above it. One administrator plus a strict sign-in policy plus a lost phone equals a business locked out of its own email, and Microsoft support cannot reliably get you back in. One account, long printed password, physically in a safe, excluded from the sign-in policies, alerted on whenever it is used.
9. Everything else, in the order the report gives it
Dormant accounts, unmanaged devices, licences nobody uses, retention windows, unverified publishers. Real work, none of it urgent, and much of it cheap. This is also where the platform is most useful over time — the approve pile refills slowly and each item is one tap.
- Concealment inbox rule
- A mailbox rule that deletes, marks as read, or moves incoming mail to Deleted Items, Junk Email or Archive. Attackers create these to hide the replies to fraud they are conducting from the account's real owner.
- Tier-zero role
- A role whose holder can escalate to full tenant control: Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, Application Administrator, Cloud Application Administrator, Hybrid Identity Administrator, Domain Name Administrator. Matched on the role template identifier rather than the display name, so a renamed or localised role cannot hide.
Three things that should move an item up your list
The order above is a default. Your own circumstances change it, and three signals in particular should override it.
- A finding that names an account you do not recognise. Position in the queue stops mattering. An unaccounted-for administrator, guest or application is an investigation, not a task.
- A skipped logging check. If nothing is keeping a record of what happens in your Microsoft 365, then every other finding is being fixed in the dark and you will not be able to answer questions about anything that already happened. This is why
enable_unified_audit_log,enable_mailbox_auditingandset_log_retentionare among the nine changes the platform applies without asking — they are the cheapest possible way to stop making the same mistake going forward. - A blast radius of "everyone" on a medium finding. Sorting within a pile already surfaces these, and they deserve a second look before you work through a longer list of narrower critical items.
Why some findings are absent rather than low
A few checks decline to fire when your licence cannot support the fix. ZQ-M365-PRIV-011, which recommends moving day-to-day administration to on-request elevation, only runs when your tenant already has the licence that provides it. Recommending something your licence cannot do wastes your time and damages your trust in everything else in the report, so the check stays quiet instead.
The exception is upgrade_licence, which appears in the decide pile when a capability is worth paying for. It is in decide for the plainest possible reason: it costs you money, and that is not our decision to make.
Once you have worked the first three items above, the shortest useful path through the rest is the first-week checklist, which is the same order with the approvals grouped so you can do them in one sitting.