Every SeQontrol product runs on the same base: one onboarding flow, one findings store, one audit trail and one licence model.
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 framework, 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 services 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 environment 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.
Scheduled scans with live progress, a report engine that produces evidence packs, and a notification system. Shared by every product rather than rebuilt in each one.
Onboarding is one flow you learn once, not one grant that covers everything.
| 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 Power Platform 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.
ShareCare finds an external share. SecurityPortal finds a Conditional Access gap. Both land in CompliancePortal already tagged to the controls they satisfy — so the thing you fixed is the thing your auditor sees, with no export in between.
Every product has its own Entra app, scoped to what that product needs — so nothing inherits permissions it has no use for, and revoking one product revokes exactly one. Adding a product is a second consent, through the same onboarding you already know.
Whatever any product checked, changed or waived is in one hash-chained record you can show a client or an auditor. Waivers expire on their own; nothing quietly stays green.
An app-only Entra app per product, each asking only for what that product needs. Same onboarding flow every time.
Each scanning product reads through that connection and writes into one shared findings store.
Findings carry control tags, so a security finding becomes compliance evidence without a second integration.
Remediation is simulate-then-execute, with grace windows, approvals and undo where the platform allows it.
Waivers expire, approvals are recorded, and the audit trail is hash-chained. Findings are live records that change as the environment changes; what is chained is the trail of what was done and the evidence snapshots taken from it.
Because the products share the platform, adding one to an environment you already run is a known, repeatable step — its own consent, through the onboarding flow you have already done once — and it covers ground the others could not reach. More coverage, the same console, 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 one onboarding flow that every product on a client's tenant goes through the same way.
A new vendor asking for read access to your entire Microsoft 365 environment should expect hard questions. Here are the answers before you ask.
Scanning is app-only, and a scan only reads. 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 service, 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.