What happens in the first hour
From connection to a readable posture report: what discovery reads and in what order, what each status message means, and why the done bucket is already applied.
The claim is that you go from connecting Microsoft 365 to a readable posture report within an hour. That number is instrumented rather than aspirational: the time from signup to your first accepted change set is written to a durable record on every run, so if the claim stops being true we find out from our own data rather than from a customer telling us.
This article is what actually occupies that hour, in order, and what each status message on the screen means.
The statuses, and what they mean
A run moves through a small set of statuses. The status code is for the software; the sentence beside it is for you, and it is the same sentence in the interface, in the API response and in the email.
| Status | The message you see | What is happening |
|---|---|---|
pending | We are getting ready to look at your Microsoft 365 setup. | The run exists and has a slot. Usually a second or two. |
connecting | We are connecting to your Microsoft 365 tenant. | Acquiring a token and confirming the app registration reads what it should. |
discovering | We are taking an inventory of your accounts, computers and policies. This usually takes about half an hour and you do not need to stay on this page. | The ten enumeration stages below, in order. |
assessing | We have your inventory and are checking it against our security checks. | All 82 deterministic checks run over the inventory. Seconds, not minutes. |
awaiting_input | Your report is ready and there are one or two questions only you can answer. | Something landed in the decide bucket — a genuine business trade-off. The report is complete and readable. |
ready | Your report is ready. N change(s) are waiting for you. — or — Your report is ready and there is nothing waiting for you. | Finished. The safe, reversible changes have already been applied and reported. |
failed | We could not finish looking at your setup. Nothing was changed. | A run-ending problem, with the reason recorded. See the end of this article. |
cancelled | This run was stopped. Nothing was changed. | Stopped deliberately, or superseded by a run already in progress. |
Discovery, in order
The tenant itself is read first, because it is the only genuinely fatal step — without a tenant identity nothing else can be attributed to anyone. After that, ten stages run in an order that exists for real reasons: accounts before role membership, because roles are joined onto accounts; accounts before mailbox rules, because the mailbox stage iterates over the accounts it found.
- Users and guests — the staff list, and which accounts are enabled.
- Multi-factor authentication registration — who has a second factor, who is capable of a passkey, who has self-service password reset.
- Administrator roles — who holds them, and which of those members are applications rather than people.
- Groups — membership as a privilege path, with member counts read for role-assignable groups.
- Conditional Access policies — whether a second factor is required rather than merely available.
- Licences — your tier and which service plans are actually provisioned.
- Devices — managed, compliant, personally owned, tampered with, and stale.
- Application consents — which applications hold standing access, and who published them.
- Sign-in logs — a seven-day window by default.
- Mailbox rules — external forwarding and message-hiding rules, administrators first, bounded to 200 mailboxes.
Each stage is independent. If one fails, it becomes a named coverage gap and the run carries on, because a report covering eight of ten areas is worth a great deal and no report is worth nothing. What a gap does to the checks that depended on it is the subject of When a check cannot run.
The half-hour figure is a target measured against real tenants, not an estimate. A 40-person organisation is usually well inside it; the mailbox-rule stage is what makes a larger tenant take longer, because it is one Graph call per mailbox.
While you wait
You genuinely do not need to keep the page open. Progress is recorded as an append-only trail of events — discovery_started, discovery_finished, assessment_finished, change_auto_applied — and the same rows the screen reads are the rows we analyse, so what you see and what we measure cannot diverge.
If you do watch, the page holds a live stream that re-reads the durable record every couple of seconds rather than subscribing to something in memory. That choice matters over a thirty-minute wait: close the laptop, land on a different server, come back tomorrow, and you still see the true state. If the stream has been open a long time it tells you to reconnect rather than dropping silently, because a silent close is indistinguishable from a crash.
Assessment: 82 checks
Once the inventory exists, a versioned pack of 82 checks runs over it. Each check is a plain function over the discovered facts with a severity, a rationale, a description of what an attacker does with it, a remediation and a compliance mapping. Count of accounts holding Global Administrator is greater than two is a comparison, not a judgement call, and it is not model output.
Three properties of this stage are worth knowing. A check whose required dataset is missing is skipped and recorded, never passed. A check that fails outright is contained, so one bad evaluator cannot lose the other 73 findings. And a finding that names no real object is rejected as a bug rather than shown to you, because an ungrounded finding is exactly the failure this architecture exists to make impossible.
Then it is written up
The findings at this point are structurally correct and unreadable. The final step is narration: given a finding whose subjects and facts are already established, the model writes the paragraph a non-expert can act on — you have 3 administrators with no second factor, one of whom last signed in from Brazil rather than MFA coverage: 40%.
The model's only job is that paragraph. It does not decide what is wrong, it does not author a change, and if no model is wired up at all the report still writes itself with a deterministic fallback. What the model says is narration over facts that were already true before it ran.
The three buckets
Every change the checks generate is sorted into exactly one of three buckets: done — safe, reversible, already applied, reported after the fact; approve — one tap, with the reasoning and the undo path shown; and decide — genuine business trade-offs we must not make for you. Done, approve, decide covers the sort in detail.
Two consequences land inside the first hour. Applying the done bucket is part of producing the report rather than a separate action you have to take, so by the time you read the report some things are already better — switching on the tenant audit log, connecting the read-only activity feed, setting a year of retention on our side. And a change that could not be applied is demoted to the approve bucket and reported as needing your attention. It is never reported as done.
If anything reaches the decide bucket, the run finishes at awaiting_input rather than ready, because waiting on a human is more useful information than ready. Both statuses serve the same complete report.
If it fails
A failed run records the reason and says so: We could not finish looking at your setup. Nothing was changed. The common causes are a client secret that expired between connecting and running, a connection that was switched off, or an organisation with more than one enabled Microsoft 365 connection — all three of which are caught before the run starts and explained in Connect Microsoft 365.
A run that stops moving without saying why is the same as a run that never happened, except that you waited for it. So every failure path writes a status you can read.