Anyone can ship a scanner. What is hard — and what makes the next product cheap to add — is everything a scanner has to sit on: one tenancy model, one connector plane, one findings substrate, one audit trail, one entitlement catalog.
A provider organisation manages a fleet of client tenants with delegated onboarding, audited impersonation for support, and an opt-in approval gate that must be satisfied before a provider acts inside a managed tenant. Every product gets multi-client support without building it.
Every product registers its connector through the same plane, with the same onboarding flow, the same secret handling and the same audit trail. What is not shared is the grant: each product has its own Entra application and asks for its own consent, scoped to the permissions that product actually needs.
That is a deliberate trade. It means enabling a second product is a second consent rather than a switch — but it also means no product inherits another's permissions, and revoking one revokes exactly one. The adjacent planes are separate again: Exchange admin, Power Platform, Azure and DNS each need their own one-time setup, and write-back is its own opt-in on top of the read grant.
The scanning products write findings into one store with severity, waivers and control-reference tags. This is the reason a security finding can become compliance evidence with no second integration, and the reason one board can show all of it.
A hash-chained audit trail across the platform. When a client or an auditor asks what was checked, what changed, and who approved it, the answer is a record that can be shown to have not been edited after the fact.
Worth being exact about what that covers: the chain protects the audit trail and the evidence snapshots taken from a point in time. Findings themselves are live records — they open, change severity and close as the estate does. Chaining them would make them immutable, which is the opposite of what a finding is for.
A catalog of features gated per plan and wired to metered billing. Because packaging is a platform capability rather than per-product plumbing, adding a product is a configuration change — not an implementation project.
Scheduled scans with live progress, a report engine that produces evidence packs, a notification system, and a full feature-flag and experiment framework with four-eyes approval and scheduling. Shared by every product rather than rebuilt in each one.
Onboarding is one flow you learn once, not one grant that covers everything. We would rather be precise about that here than let you discover it during onboarding.
| Step | What it needs | How often |
|---|---|---|
| Microsoft 365 and Entra | An admin consent for the product's own Entra app, declaring only that product's Graph permissions | Once per product |
| Enabling another product | Its own Entra app and its own admin consent, through the same flow. Nothing inherits another product's permissions, and revoking one revokes exactly one | Once per product |
| Write-back and remediation | A separate, explicit opt-in on top of the read grant — which is what keeps read access from silently becoming write access | Once per product that writes |
| Exchange admin | A certificate: provision it, upload the public key to the Entra app, and grant the Exchange management role | One-time setup |
| Power Platform | A service principal registered by an administrator before the plane can be read | One-time setup |
| Azure and Log Analytics | A workspace and a reader role assignment on it. Without the export, the log-based checks report “not assessed” rather than a pass | One-time setup |
| DNS, for MailTrust | Its own OAuth2 authorisation per DNS provider — a wholly separate flow from Graph | One-time, per provider |
ShareCare, SecurityPortal, CompliancePortal and Dredd read through the shared Graph connector. MailTrust and PosturePortal do not: MailTrust authorises DNS providers directly and ingests DMARC reports from a mailbox, and PosturePortal connects to nothing at all — it reads the findings the others have already written.
Because the products share the platform, adding one to an estate you have already connected costs you almost nothing to switch on — and covers ground the others could not reach. More coverage, the same connection, the same bill.
That is what makes the expansion path real rather than aspirational: you buy one product because one problem hurts, and the second one costs you an entitlement and a connector to switch on, instead of a project. It is also what makes the provider model work at all — one provider tenant, one console, and a client's permission grant that every later product rides on.
A new vendor asking for read access to your entire Microsoft 365 estate should expect hard questions. Here are the answers before you ask.
Scanning is app-only and read-first. Scopes are documented, and the connector's remediation consent is separate from the read consent — so read access never silently becomes write access.
Nothing is written to your tenant unless both the license entitlement and the connector's own remediation consent are present. Turning either off stops the write path.
Providers can be required to obtain approval before acting inside a managed tenant, and every impersonated support session is audited.
Controls, desired states, findings, remediations, approvals, waivers and scan sessions preserve their history. Governance decisions overlay the facts; they never rewrite them.
Waivers and risk acceptances carry a mandatory expiry and are invalidated automatically when the underlying finding changes shape. A waived finding is still a finding — because security stands above compliance, and an accepted risk that vanishes from the screen is just a risk you stopped counting.
Where a check cannot be assessed — no exported logs, an unsupported plane, a missing permission — the product reports "not assessed" with the reason. It does not quietly score it green.
The fastest way to judge a platform claim is to connect one tenant and look at what comes back.