Collected once. Checked once. Then it's gone.
Every scan is single-use by construction. There is no database of your clients' security data, because the architecture has nowhere to put one.
Collect
Through the delegated access you already hold, posture is read directly from source systems into volatile memory. Read-only scopes. Nothing is written anywhere.
Evaluate
Controls are scored against a versioned catalog built from what actually moves risk in a Microsoft 365 tenant. Verified means verified — unchecked controls are labeled, never guessed.
Destroy
The buffer is overwritten and released the moment evaluation completes. Zero bytes of raw telemetry survive the scan.
Attest
What persists is one cryptographically signed record — score, status, and a hash chained to every scan before it. Tamper-evident by design.
Security posture you can interrogate.
Armada is being built to SOC 2 control posture from the first commit — with an independent Type II audit on the roadmap, not claimed before it's earned. In the meantime, the architecture makes the strongest claims for us.
Read-only, least-privilege scopes
The platform can look. It can never touch, change, or administer anything in a client's environment. There are three, and every one is published below with the endpoint it exists for.
Client-revocable at any time
Access runs through the delegated relationship you already hold, and the client can revoke it from their own portal — without asking you or us.
No raw telemetry at rest
There is no table, field, or backup where client security data could accumulate. Structurally absent, not policy-forbidden.
Cryptographically signed results
Attestations are signed with ECDSA P-256 and hash-chained, so history can't be quietly rewritten — including by us. Hardware-backed key custody (Azure Key Vault) lands before any live client tenant is signed; today's signing keys are held by the application.
The exact scopes, published.
Most vendors say “least-privilege” and leave you to find out at the consent screen. Here is the whole list, before you click anything. If Armada ever asks your client for a permission that is not on this page, something is wrong — refuse it and tell us.
| Permission | What it reads | Why it exists |
|---|---|---|
AuditLog.Read.All |
/reports/authenticationMethods/userRegistrationDetails |
MFA registration coverage, and whether any admin is unregistered. This is the one that scores the MFA control. |
Policy.Read.All |
/identity/conditionalAccess/policies |
Conditional Access policy state — evidence that MFA is actually enforced, not merely registered. Supporting context; never scored on its own. |
RoleManagement.Read.Directory |
/roleManagement/directory/roleAssignments |
How many standing privileged role assignments exist. This is the one that scores the privileged-access control. |
What we deliberately do not ask for
Every permission is .Read — the app has no write capability of any kind. Beyond that, four permissions were removed in July 2026 after we checked what the code actually calls:
Directory.Read.All,User.Read.All,Organization.Read.All— registered historically; no part of the scanner read them.Directory.Read.Allin particular is the broadest-looking line on any consent screen, and it bought us nothing.SecurityEvents.Read.All— needed only for Microsoft Secure Score, which is cross-domain context that never becomes a control status. We removed the collector rather than ask your client for a security-events permission to fetch a number nothing scores.UserAuthenticationMethod.Read.All— an early version of our consent screen listed this, and the app never actually requested it. That is a mistake in the direction that flatters nobody, so it is recorded here rather than quietly deleted. MFA registration comes from the report endpoint above.
Your client can revoke all of it at any time by deleting the enterprise application in their own Entra portal, without asking you or us.
Asked and answered.
Software for MSPs and VARs. It reads each client tenant's Microsoft 365 security posture, scores it against a versioned control catalog, flags drift between scans, and produces a signed, client-ready report you can put your own brand on. It is a reporting and evidence layer — not a managed security service, and not a replacement for your stack.
No. Posture data is read into memory, evaluated, and destroyed within a single scan. What persists is the result — a score, a status, and a signed hash. The storage layer has no place for raw telemetry by design, so retaining it isn't a policy we follow; it's a capability we don't have.
The first integration collects three identity signals from Microsoft 365 — MFA registration, Conditional Access enforcement, and privileged role hygiene. Those signals currently score two controls on the catalog: MFA coverage and privileged access. The full catalog is 13 controls, and every control this integration can't reach is labeled "not verified" rather than estimated — including ones a correlated signal could tempt us to infer. Coverage expands integration by integration, and we'd rather tell you the number is two than round it up.
It's a simplified, clearly-labeled illustration using three controls. The product runs the full 13-control catalog with knockout logic, and the numbers there come from verified scans of real environments — never from a marketing page's math.
Yes — that's the point. Your name, logo, colors, and domain sit on the console and on every client report. Your clients never see Armada's brand unless you want them to. White-labeling is what makes this a service you sell rather than a tool you resell.
Armada is in active development, shaped directly by conversations with MSP owners. If you manage Microsoft 365 for a book of clients and want to influence what gets built — or be first in line when it ships — request early access.
Interrogate it yourself.
Ask us the hard questions — architecture, scopes, retention. A founder reads and answers every note.
Request early access