We read it, we score it, and then it's gone.
Every scan is single-use. Raw posture data is read into memory, scored, and dropped. What persists is one signed result per scan, because the storage layer has nowhere to put anything else.
How a scan works, step by step
Collect
Posture is read from Microsoft Graph into process memory and nowhere else. Access is one multi-tenant Entra application, approved per client tenant on Microsoft's own admin-consent page. Under an existing GDAP relationship you approve it yourself. Three scopes, every one of them read-only, so the application has no write capability and could not alter a tenant 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
Signals exist for one function invocation and are never written down. Scoring ends, the call returns, and the last reference to them goes with it. 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, whether the scan ran live or against test fixtures, and an ECDSA P-256 signature over a hash chained to every scan before it. Alter one old record and every hash after it stops matching, and that break is visible to anyone who cares to look. The public key is published and the checker runs in the browser, so your client's auditor can confirm a record without coming through us. Check one now. What is still ours to fix is key custody, not visibility.
Security posture you can interrogate.
Start with the status, because it shapes everything below. Armada is pre-launch. No client tenant has been scanned, no third party has assessed the software, and it holds no certification. An information security policy and an incident response plan are written, and an independent SOC 2 Type II audit is on the roadmap. We won't claim it before it's earned. Until an auditor signs something, the architecture makes the strongest claims we have, so here is exactly what the code does.
What the platform can and cannot do
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. A test in the build reads the app registration script, the consent screen, and this page, and fails if any of the three stops matching the others.
Client-revocable at any time
Consent lives as an enterprise application in your client's own tenant. They can delete it from their Entra portal without asking you or us, and the next scan then fails outright rather than falling back to anything.
No raw telemetry at rest
There is no table, field, or backup anywhere in the system where raw posture data could accumulate. It's structurally absent rather than forbidden by policy.
A claim is never counted as a measurement
Eleven of the thirteen controls have no Microsoft telemetry behind them, and your provider usually knows the answer anyway. They can put it on the record as a declaration: a named person, on a date, with an expiry and pointers to evidence. It is carried inside the signed record, so it cannot be edited afterwards without breaking the chain.
It is never scored. A declaration cannot move a score, a tier, or a knockout, and three separate mechanisms in the code stop it rather than one. Declarations use their own vocabulary and never borrow the pass and fail language of a measured control, an expiry is required so a claim cannot quietly stand forever, and a declaration records which version of the check it answered so a later rule change cannot inherit it. A report shows both numbers: what was measured, and what someone will put their name to.
The limit worth stating: because we hold the signing key, the signature proves we recorded the claim and that nothing changed since. It does not prove the named person made it. That would need their key, and they do not have one.
Cryptographically signed results
Attestations are signed with ECDSA P-256 and hash-chained, so no record can change without breaking every record after it. The honest limit is key custody. Today the signing key is generated by the application and held on disk, so the chain is only as good as our own handling of it. The public key is published, and anyone can check a record against it without asking us first. Hardware-backed custody in Azure Key Vault is the piece still outstanding, and it lands before any live client tenant gets signed.
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, five 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, and produces a client-ready report on your own letterhead, backed by a signed attestation record. Drift alerts between scans are designed and not yet built, so treat them as roadmap. Think of the whole thing as a reporting and evidence layer. It isn't a managed security service and it won't replace anything in your stack.
No raw posture data. Signals are read into memory, evaluated, and dropped inside a single scan. What persists is the result: a score, a per-control status, and a signed hash. Storage holds two things, your client records and the attestation chain, and there is no third place where telemetry could land. So not retaining it isn't a policy we follow. It's a capability we don't have.
The first integration reads three identity signals from Microsoft 365: MFA registration, Conditional Access enforcement, and privileged role hygiene. Those signals 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. One thing to be plain about: those collectors are written and tested, and they have not yet run against a live tenant. Every scan so far has been against labeled test fixtures, and each record carries the mode it ran in. 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 it scores only the controls a scan actually verified. Be clear on where the numbers come from: nothing on this site or in the demo console is customer telemetry. The console runs on sample data, every export it produces says so in the file, and no real environment has been scanned yet.
Yes. That's the whole point. Today your company name, your product name, and your accent color carry through every console surface and onto the report letterhead, and the color retints the interface as you type it. Logo upload and a domain of your own are planned and not built yet. 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.
Not yet. Armada is in active development, it is not for sale, and no MSP is running it in production. What comes next is a set of conversations with owner-operators who manage Microsoft 365 for a book of clients, and what those conversations say will decide the next integration and the pricing. If you want a say in that, or a walkthrough of the console with the sample data labeled as sample data, 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