We read it, we score it, and then it's gone.
Every scan is single-use. There is no database of your clients' security data anywhere in Armada, because the architecture has nowhere to put one.
Collect
Posture is read straight from Microsoft Graph into process memory, over the delegated access you already hold. Three scopes, every one of them read-only. The application has no write capability at all, so it could not alter a tenant even if it were told to.
Evaluate
Thirteen weighted controls, scored only across what the scan could actually verify. Four of them are knockouts that cap a tenant's grade on their own. A control the scan couldn't reach is a coverage gap, never a failure, and never a guess.
Destroy
The buffer is overwritten and released the moment scoring finishes. There is no table, field, or backup anywhere in the system that could hold raw telemetry, so nothing survives the scan by accident either.
Attest
One signed record survives: the score, each control status, the catalog version, and an ECDSA P-256 signature over a hash chained to every scan before it. Rewriting the history would break the chain, and the break would be plain to anyone who looked.
Security posture you can interrogate.
Armada is being built to SOC 2 control posture from the first commit. An independent Type II audit is on the roadmap, and we won't claim it before it's earned. Until then, the architecture makes the strongest claims we have.
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 scopes, and every one is published below alongside the endpoint it exists for.
Client-revocable at any time
Access runs through the delegated relationship you already hold, and your 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 anywhere in the system where client security data could accumulate. It's structurally absent rather than forbidden by policy.
Cryptographically signed results
Attestations are signed with ECDSA P-256 and hash-chained, so the history can't be quietly rewritten by anyone, ourselves included. Hardware-backed key custody in Azure Key Vault lands before any live client tenant gets 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 what that meant 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, which is the evidence that MFA is actually enforced and not merely registered. Supporting context only. It is 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, so the app has no write capability of any kind. Beyond that, four permissions came off the list in July 2026 once we checked what the code actually calls:
Directory.Read.All,User.Read.All, andOrganization.Read.Allwere registered historically, and no part of the scanner ever read them.Directory.Read.Allin particular is the broadest-looking line on any consent screen, and it bought us nothing.SecurityEvents.Read.Allwas 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.Allappeared on an early version of our consent screen, and the app never actually requested it. That's a mistake in the direction that flatters nobody, so it's recorded here instead of 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. Think of it as a reporting and evidence layer. It isn't a managed security service and it won't replace anything in your stack.
No. Posture data is read into memory, evaluated, and destroyed inside a single scan. What persists is the result: a score, a status, and a signed hash. The storage layer has no place to put raw telemetry, so not 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 runs to 13 controls, and every control this integration can't reach is labeled "not verified" rather than estimated, including the ones where a correlated signal would tempt us to infer an answer. Coverage expands integration by integration. We'd rather tell you the number is two than round it up.
It's a simplified illustration using three controls, and it's labeled as one. The product runs the full 13-control catalog with knockout logic, and its numbers come from verified scans of real environments rather than from a marketing page's arithmetic.
Yes. That's the whole 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 decide to show them. 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 a say in what gets built, or simply want to be first in line when it ships, request early access.
Interrogate it yourself.
Ask us the hard questions about architecture, scopes, and retention. A founder reads and answers every note.
Request early access