How it works
Read-only. Nothing changes unless you say so.
The first question anyone sensible asks is whether it is safe to point at a client’s tenant. Here is the honest, specific answer.
Start to finish
Four steps, one afternoon
No agent to deploy, no connector to install, nothing left behind in the tenant when you’re done.
Sign in, read-only
One Microsoft Graph sign-in with read permissions. No agent, no appliance, no service principal quietly left running afterwards.
If the account you sign in with cannot write, the tool cannot write — the permission boundary is Microsoft’s, not a setting we ask you to trust us on.
It reads the tenant
Across 58 Microsoft Graph endpoints, it collects the current state of identity, endpoints, patching, protection and Microsoft 365 configuration — then resolves every policy assignment to find out what actually reaches a device.
A few minutes of runtime for most tenants. Nothing is written, queued, or scheduled.
You review the findings
89 Microsoft best practices, ranked by severity, each carrying the reference it maps to. Anything that could not be measured is labelled as such rather than being dropped from the total.
At this point you have a complete picture and have still changed absolutely nothing.
You decide what to fix
Remediation is a separate, deliberate act. You review each item, confirm it, and only then does anything run — one at a time, with the change visible before you approve it.
Access
What it asks for, and what it cannot do
The safest tool is one that is structurally incapable of the thing you are worried about.
Read scopes only, for the assessment
- Device inventory and compliance state
- Configuration profiles and their assignments
- Conditional Access policies
- Identity and privileged-role posture
- Update rings and patch state
- Licence and subscription entitlements
- Certificate and token expiry data
No writes during assessment. None.
- Creates nothing — no policies, groups or profiles
- Modifies nothing that already exists
- Deletes nothing, ever, under any mode
- Leaves no agent, connector or standing service principal
- Sends no email and touches no user
Where the data goes
The assessment runs on your machine. Findings, reports and exports are written to a folder on your own disk — the tenant data never passes through us, and there is no portal holding your clients’ configuration on someone else’s infrastructure.
For anyone assessing tenants on a client’s behalf, that matters. It is a much shorter conversation than explaining a third-party cloud service to a nervous customer.
Remediation
Three ways to fix something, all of them yours
Every fix is sorted by how much judgement it needs — and none of them run on their own.
Safe, reversible, well understood
Presented with the exact change, ready to run once you confirm. Still your click.
Needs a decision from you
The tool knows what should change but not what is right for this tenant. It asks rather than assumes.
Do this yourself, here’s how
Too consequential to automate. Written up step by step so someone competent can follow it.
Why it will never fix things by itself
An automated remediation engine pointed at a client’s production tenant is a bad idea wearing a good idea’s clothes. The tool cannot know that the “misconfigured” policy is a deliberate exception, or that the exempt group exists for a reason nobody wrote down.
So it does not decide. It finds, explains, ranks and prepares — and a person confirms. That is a design decision, not a missing feature, and it is not on the roadmap to change.
Point it at a tenant you already understand
The fastest way to trust it is to run it somewhere you know well, and see whether it tells you something you didn’t already know.
Email [email protected]