We don't keep your clients' data.
Each scan reads raw data into memory, scores it, and drops it. The only thing kept is one signed result per scan.
How a scan works, step by step
Collect
Armada reads posture from Microsoft Graph into memory. Access is one multi-tenant Entra app that each client tenant approves on Microsoft's own consent page. Under GDAP you approve it yourself. All three permissions are read-only, so the app can't change a tenant.
Evaluate
Nineteen weighted controls, eight of them measurable today. The score counts only what the scan verified. MFA enforcement is a knockout: a verified failure caps the grade no matter what else passes. A control the scan can't reach is a coverage gap, not a failure.
Destroy
Raw data lives for one function call and is never written down. When scoring ends, it's gone. No table, field or backup in the system can hold it.
Attest
One signed record is kept: the score, each control's status, the catalog version, whether the scan was live or a test fixture, and an ECDSA P-256 signature chained to the scan before it. Edit an old record and every later hash stops matching. The public key is published and the checker runs in the browser, so your client's auditor can check a record without us. Check one now. The open issue is key custody, covered below.
Security posture you can interrogate.
Armada is pre-launch. No client tenant has been scanned, no third party has assessed the software, and we hold no certifications. We have a written information security policy and incident response plan, and a SOC 2 Type II audit is on the roadmap. Until then, here is exactly what the code does.
What the platform can and cannot do
Read-only, least-privilege scopes
The platform can read and nothing else. All three permissions are listed below with the endpoint each one is for. A build test fails if the registration script, the consent screen and this page ever disagree.
Client-revocable at any time
Consent is an enterprise app in your client's own tenant. They can delete it from their Entra portal without asking anyone, and the next scan fails instead of falling back to anything.
No raw telemetry at rest
The system has no table, field or backup where raw posture data could be stored.
A claim is never counted as a measurement
Eleven of the nineteen controls have no telemetry behind them, but your provider often knows the answer. They can record a declaration: a named person, a date, an expiry and pointers to evidence. Declarations sit inside the signed record, so they can't be edited later without breaking the chain.
Declarations are never scored. They can't move a score, a tier or a knockout. The code enforces this three ways: declarations use their own vocabulary instead of pass and fail, every one needs an expiry, and each records the version of the check it answered so a later rule change can't inherit it. The report shows measured results and declarations separately.
One limit: we hold the signing key, so the signature proves we recorded the claim and that it hasn't changed. It doesn't prove the named person made it.
Cryptographically signed results
Attestations are signed with ECDSA P-256 and hash-chained, so changing any record breaks every record after it. The weak point is key custody: today the app generates the signing key and keeps it on disk. The public key is published and anyone can check a record against it. The key moves to hardware-backed Azure Key Vault before any live client tenant is signed.
The exact scopes, published.
Here is the full list of permissions, before you click anything. If Armada ever asks your client for one that isn't on this page, refuse it and tell us.
| Permission | What it reads | Why it exists |
|---|---|---|
AuditLog.Read.All |
/reports/authenticationMethods/userRegistrationDetails |
MFA registration coverage, whether any admin is unregistered, and whether every admin has a sign-in method stronger than a text or a call. It scores the MFA-coverage and strong-admin-method controls. |
Policy.Read.All |
/identity/conditionalAccess/policies/policies/identitySecurityDefaultsEnforcementPolicy/policies/authorizationPolicy |
Conditional Access policies and the security defaults switch: whether MFA is actually required for every user, and whether legacy authentication is blocked. Security defaults settles both on tenants without Entra ID P1. The authorization policy says whether users can consent to apps on their own, who can invite guests, and what guests can see. One permission, three reads, four controls. |
RoleManagement.Read.Directory |
/roleManagement/directory/roleAssignments |
How many standing Global Administrator assignments exist, matched on the role's fixed template id. It scores the privileged-access control. |
What we deliberately do not ask for
Every permission is .Read, so the app can't write anything. We also dropped five permissions in July 2026 after checking what the code actually calls:
Directory.Read.All,User.Read.AllandOrganization.Read.Allwere registered early on, but the scanner never used them.SecurityEvents.Read.Allwas only for Microsoft Secure Score, which never became a control status. We removed that collector instead of asking for the permission.UserAuthenticationMethod.Read.Allappeared on an early version of our consent screen, though the app never requested it. We're noting the mistake here rather than deleting it. 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 Entra portal.
Asked and answered.
Software for MSPs and VARs. It reads each client's Microsoft 365 security settings, scores them against a versioned control catalog, and produces a report under your brand, backed by a signed record. Drift alerts are designed but not built. Armada is a reporting tool. It is not a managed security service and doesn't replace anything in your stack.
No raw posture data. Signals are read into memory, scored and dropped within a single scan. What's kept is the result: a score, a status for each control and a signed hash. Storage holds your client list, the signed attestation chain and any declarations. None of those has a place for raw telemetry.
The first integration reads five things from Microsoft 365 with three read-only permissions: MFA registration, Conditional Access policies, the security defaults setting, consent and guest settings, and Global Administrator assignments. Those score seven controls: MFA coverage, MFA enforcement, legacy authentication, strong admin sign-in methods, privileged access, user app consent and guest access. An eighth, email authentication, checks the SPF, DKIM and DMARC records in the client domain's public DNS and needs no Microsoft permission. Everything else in the 19-control catalog is labeled "not verified." The collectors are written and tested but haven't run against a live tenant yet. Every scan so far used labeled test fixtures, and each record says which mode it ran in.
It's a simplified illustration with three controls, and it's labeled that way. The product scores the full 19-control catalog, counting only what a scan verified. Nothing on this site or in the demo console is customer data. The console runs on sample data, every export says so, and no real environment has been scanned yet.
Yes. Your company name, product name and accent color appear across the console and on the report letterhead. Logo upload and custom domains are planned but not built. Your clients don't see Armada's name unless you show them.
Not yet. Armada is in development and not for sale, and no MSP runs it in production. We're talking with owner-operators who manage Microsoft 365 for their clients, and those conversations will decide the next integration and the pricing. Request early access if you want a say, or a walkthrough of the console on sample data.
Interrogate it yourself.
Send us your questions about architecture, permissions or data retention. A founder answers every one.
Request early access