Products — Warden
Sign in read-only, cache what matters, run the checks, rate each result, attach the evidence, write the report. Built to be run by an auditor and defended afterwards.
Honest status
Warden's platform is real and in use: sign-in, collection, caching, the coverage model, the rating engine, evidence handling and report generation are all working, with a test suite that gates the build. What is not finished is the check library. Thirty datasets are collected and twenty-eight finding types are catalogued with default ratings and portal steps, and at the time of writing one check is built end to end: D4, excessive MFA exemptions. It is the reference implementation the other twenty-seven are being written against.
We are telling you this because an assurance product that blurs the line between "collected" and "assessed" is worse than no product. A run reports its own coverage, so a tenant Warden could not fully assess can never read as a clean one.
How it works
Collection is the only network phase. Everything after it runs offline against the local cache, which is why a re-run after a policy change costs you nothing and re-analyses can happen days later without bothering anyone.
Warden authenticates to each tenant in an engagement one of three ways: an app registration with a client secret, the same app registration with a certificate (our preference where you can do it), or delegated sign-in as an assessor holding Global Reader. It then decodes the token it was actually issued and records what was granted.
Hard stop
If that token carries write permissions Warden did not ask for, collection refuses to run. This catches the common real-world case where an admin means to grant read access and grants a privileged role by mistake.
Each check declares its data dependencies, so a run fetches the datasets its enabled checks actually consume rather than everything imaginable. Results are written to a per-tenant cache as JSONL, one file per dataset, with a manifest recording completeness and timestamps.
Complete datasets are never re-fetched. A partial one resumes from its last saved page, which matters: a 160,000-user tenant takes hours, and if the session drops mid-sweep nothing collected so far is wasted.
Each check reads the cache and evaluates a specific failure mode — who is excluded from MFA and whether anything else covers them, who holds a privileged role and why, which policy grants more than it appears to. Checks are re-runnable against the same cache with different parameters, so "what if we treat that group as protected?" is a second run, not a second engagement.
Every finding is rated on what it would take to exploit against how likely that is here, in this tenant, with reasoning recorded at each step. Deliberately not CVSS: a base score cannot express "this exemption group contains no people", which is exactly the judgement a real assessment has to make.
Non-production tenants cap severity. A Critical in a lab is not reported as a Critical, and the report says it applied that cap and why.
Findings register, client questions, manual evidence tasks and an HTML report. Findings carry dated evidence blocks with the exact Graph query behind each one. Anything unreadable becomes a recorded Limitation — a 403 on a dataset is reported as "we could not read this", never as "you have nothing here".
What makes it different
The interesting problems in Conditional Access are almost never inside one policy. They live in the gaps between several of them, and in what the tenant failed to say.
A tool that reports "these accounts are excluded from MFA" is reading a field. Warden builds the coverage model: who is excluded, whether any other enforced policy picks them up, whether the exclusion is protected from casual change, and whether the group has owners at all. That is the difference between a list and a risk.
Some of the most consequential findings are absences. No licence assigned to anyone, so sign-in activity returns nothing for anyone — which quietly destroys the discriminating power of every "this account has never signed in" inference in the report. Warden is built to notice missing signal, not just bad signal.
If a dataset comes back degraded or denied, the run says so in the Limitations section with the reason. An empty result is treated as suspect rather than clean: zero policies returned can mean "the tenant has none" or "this token cannot read them", and guessing wrong in the flattering direction is how a broken assessment reads as a pass.
Evidence blocks are timestamped and include reproducible Graph requests. Your identity team can paste them and confirm the finding independently, which is the only answer that survives an internal disagreement about whether the finding is real.
Check coverage
Every finding type has an ID, a default rating, the Entra admin centre steps to confirm it manually, and framework mappings. A sample of the areas, with real status:
| ID | Finding type | Status |
|---|---|---|
D1 | Legacy authentication reachable | Catalogued |
D4 | Excessive MFA exemptions | Built |
D6 | Break-glass and emergency accounts | Catalogued |
D14 | Privileged role over-assignment | Catalogued |
D23 | Security defaults and baseline drift | Catalogued |
D24 | Cross-tenant and drift comparison | Catalogued |
"Catalogued" means the finding type is specified and the data it needs is already collected — the remaining work is the check itself. It does not mean the check has run against your tenant. Ask us which checks a quote covers; we will answer with the number, not a range.
Collection scope
Thirty datasets per tenant. Read this list as the boundary: Warden has no capability to fetch anything not on it. Group membership and ownership are fetched in addition, on demand, for the groups your enabled checks actually reference.
What you get
This is the part clients tell us matters most, so it is worth being specific about the four artefacts a run produces.
Findings register
Every finding, ranked, with the rating, the reasoning behind the rating, the affected objects and the recommendation. This is the document your team works from. If it is a hundred rows, we should be arguing about the filtering, and we expect to.
Client questions
Items where the technical state is clear but the intent is not: is this service account expected, is this exemption a documented decision, does anyone still use this app. Risk in an identity tenant is frequently a business fact we cannot read out of Graph.
Manual evidence tasks
Some things are only visible in the portal, or need a screenshot for the file. These come out as a checklist with the exact admin centre path, so they can be done by your team in a few minutes rather than becoming an open question forever.
Full report
The HTML report: every check with its evidence blocks, the coverage table showing what was assessed against what was not, all limitations with reasons, tenant metadata and the exact version of the tool that ran. This is the document that makes the summary defensible.
It does not write to your tenant — not restricted, absent. It does not read sign-in logs at scale or contents of mailboxes, files or endpoints. It is not a monitoring platform and does not alert in real time; it is a point-in-time assessment you re-run. It does not replace a penetration test or check whether your policies are appropriate for your business — only whether they do what they appear to. And it does not certify anything: no ISO, no SOC 2, no Cyber Essentials. That is a different exercise, and we will say so rather than stretch the word "assurance".
Set up read-only access and we will run it, or ask us for a lab run first. Either way you get the real report, not a deck about it.
