Inventory
Create a customer, attach their tenants, register access. One customer can hold many tenants, and several customers can belong to one group.
Many tenants, one baseline, one known state.
mandio keeps customers and their Microsoft Entra tenants as master data, deploys a reviewed configuration state as a baseline, and shows continuously where reality has drifted away from it.
The problem
After the workshop everyone knows how it should look. A year later nobody does.
A tenant's target configuration gets agreed carefully once, then lives in a document. The build is done by hand. At the next customer someone else builds almost the same thing, and almost is the operative word.
Then reality moves. Someone adds a policy because a project is pushing. Someone removes one because an executive complained. Both are reasonable, neither is recorded anywhere. At the next audit you sit with last year's document and today's tenant and diff them by hand.
mandio turns that around. The target state stops being a description and becomes data: deployable, comparable, versioned. Anything that differs from it is either a finding or a documented exception, never a surprise.
How it works
01
02
Define
A baseline is a versioned bundle of individually versioned building blocks. Not a monolith you clone for every deviation.
03
Deploy
A what-if preview before every change, then apply. Each run is recorded immutably: who, when, what, and with which outcome.
04
Verify
Recurring comparison against the assigned baseline. What differs is a finding. What differs by agreement is a time-boxed exception with a reason and an approver.
Principles
Decisions taken early that are expensive to reverse later. They are listed here because they are what sets the tool apart, not because they read well.
01 No standing write access
Reads run through a stored credential with read-only permissions. Writes only ever happen on behalf of a signed-in person. Nowhere is there a credential that could change anything unattended.
02 Deployment never cleans up
Objects that exist in the tenant but not in the baseline are reported, not deleted. A tool that tidies up on deployment will eventually remove a policy that was created by hand for a good reason.
03 Exceptions are recorded
An agreed deviation is not drift. It is an exception with a reason, an approver and an expiry date. Without that distinction every report repeats the same items until nobody reads it.
04 The audit log names a person
Because changes run under the signed-in user, the target tenant's sign-in log shows a named individual rather than an opaque service principal.
05 No object IDs in baselines
Objects carry different identifiers in every tenant. Baselines therefore reference logical names, and the mapping is kept per tenant. Without that separation every second run creates the same objects again.
06 Runs are immutable
Runs and their individual steps are written once and read thereafter. What was done and when cannot be smoothed over after the fact.
Scope
What is available today and what is being worked on.
- ✓Master data for groups, customers and tenants
- ✓Certificate-based sign-in to connected tenants, read-only, with no stored secrets
- ✓Inventory per tenant, including licence tier and object counts
- ✓Sign-in via Entra ID with PKCE and full token validation, plus a monitored break-glass path
- ✓Job queue for longer runs, kept out of the web tier
- ○Building blocks and baselines with versioning and assignment
- ○Drift detection against the assigned baseline
- ○Deployment with what-if preview
- ○Exceptions with approval and expiry
Contact
Questions about the tool, about connecting a tenant, or about the roadmap go to hello@mandio.app.