The overhead that grows with every customer you win
Running identity for one organisation is a known job. Running it for thirty is that job thirty times — unless the platform is built so that it isn’t.
The trap is per-tenant overhead, and it shows up in four places. A separate console per customer means analysts spend the day logging in and out, and nobody has a single view of anything. Licences bought per tenant, up front leave capacity stranded in the quiet accounts while the growing ones run short. Isolation nobody can describe turns one mistake into a breach spanning your whole book of business. And support access that is all-or-nothing leaves you either locked out of the tenants you are paid to manage, or standing in all of them permanently.
Each one is a fixed cost paid again for every customer, so the thirtieth is as expensive to run as the first — and the margin that was supposed to arrive with scale never does.
Two things have to be true at the same time
This is the tension that makes managed identity hard: nearly every shortcut that buys you one of them costs you the other.
- Operational scale One console, one place to work, capacity that flows to wherever it is needed, and onboarding that doesn't repeat the same setup every time.
- Security isolation Separate tenants, scoped administrators, read-only where read-only belongs, and no standing access into customer environments.
Solve only the first and you have an efficient practice with a single blast radius across every customer. Solve only the second and you have a defensible architecture that costs more with each account you win.
Scale the service without flattening the security boundaries.
Add customers without adding consoles
Mirket is built for MSSPs and large multi-entity organisations managing many tenants from one centralised portal.
That is the difference between operations that scale and operations that multiply. An analyst covering thirty customers works in one place; onboarding the thirty-first adds a tenant, not a login, not a runbook, and not another window in the row along the top of somebody’s screen.
Capacity that moves, billed on what is used
Licences are drawn from shared pools, with monthly, usage-based billing.
The practical effect is that capacity follows demand instead of being guessed at in advance. A quiet account isn’t holding capital that a growing one needs, and a customer expanding mid-month draws more from the pool rather than triggering a purchase conversation.
It also changes what a new customer costs to say yes to. When onboarding doesn’t require buying a block ahead of demand, the smallest accounts stop being the ones you have to think twice about.
One platform does not mean one security boundary
This is the question a customer’s auditor asks, and the one a provider should be able to answer in a sentence.
Every customer remains a separate tenant. Users, policies and data stay inside that tenant while the provider manages all of them from one central portal. Data and policy are segmented between tenants by design rather than by convention — which is the difference between an isolation model you can describe and one you are hoping holds.
Administrators are scoped in two dimensions
| Master Admin | Sees the other tenants on the account as well |
| Account Admin | Sees only their own tenant |
| Full Control | Can make changes |
| Read Only | Can view the interface and change nothing — the right profile for an auditor, and for most of a support rota |
The combination matters more than either half. A junior analyst who should see one customer, read-only, is a configuration rather than a promise.
And this isn’t only a provider’s control. A group running several tenants of its own uses it the same way — an administrator responsible for one subsidiary has no reason to see the others, and here that is a setting rather than an understanding.
The tenant holds the support switch
Reaching into a customer’s environment is something that gets turned on for the work and off afterwards. What makes it worth more than a policy is where the switch sits.
With Remote Support off, nobody above that tenant can administer it. Not the partner managing them, not the MSSP above that — and not Mirket. Only that tenant’s own administrators.
That is worth having as a provider rather than only as a customer. The question that arrives in every security review — what stops your people reaching into our environment whenever they feel like it? — gets a structural answer instead of a procedural one. And a provider permanently inside thirty tenants is carrying thirty liabilities at once, which is the finding that turns up in your customer’s audit rather than in yours.
Onboarding a customer is an operation, not a negotiation
As an MSSP partner you create the tenant and assign its licences yourself, from the pool you already hold. Editing and removing a tenant sit in the same place, and Go to Portal opens that customer’s own portal in a new tab when you need to work inside it.
Nothing in that sequence waits on a purchase order or a provisioning request. It is the difference between a customer you can say yes to on the day and one that needs a week of paperwork first.
The same platform your customers are buying
Underneath, this is not a management layer built over somebody else’s product. Each tenant runs MFA, SSO, Secure Self-Service and ITDR over its own directory — the same platform, configured per customer.
So what you sell and what you operate are the same thing. A feature you learn once applies across your whole book, a question a customer asks has one answer, and there is no separate management product to keep current alongside the one you resell.
Four questions worth asking about your current platform
Short, and they tell you whether it is scaling with you or against you.
- How many separate consoles does an analyst use in a day to cover your customers?
- How much licensed capacity is sitting unused in tenants that never grew into it?
- How many customer environments require permanent support access for your team to do its job?
- What operational work repeats every single time you onboard a customer?
If every new customer adds another management stack, you are scaling customers and overhead at the same rate — and only one of those two was supposed to grow.
What changes with Mirket
| Before | With Mirket |
|---|---|
| One console per customer | One console across every tenant |
| Licences bought per tenant, stranded when unused | Shared pools, billed monthly on usage |
| Isolation is assumed | Tenants are separated by design, and you can say so |
| Support means standing access into every tenant | The tenant holds a switch that shuts out everyone above it, Mirket included |
| Onboarding a customer waits on provisioning | You create the tenant and assign its licences yourself |
| Every admin sees everything, or nothing | Master or Account Admin, Full Control or Read Only |
| A management layer sits over the product you resell | You operate the same platform you sell |
| The thirtieth customer costs as much to run as the first | Per-tenant overhead trends toward zero |
Frequently asked questions
What makes an identity platform genuinely multi-tenant?
That many tenants are the normal case rather than one tenant repeated. In practice that means one console across every customer, capacity that moves between them, administration scoped by role, and isolation between tenants that you can describe to a customer's auditor.
Do analysts need a separate login per customer?
No. Mirket is built for providers managing many tenants from one centralised portal. Anything above one login per analyst is time spent on navigation rather than work, multiplied by every customer and every person on the team.
Can one customer see another customer's data?
No. Each tenant is isolated, with data and policy separated between them. Users, policies and directory integration stay inside the tenant they belong to, while the provider manages all of them from one place.
How are licences handled across customers?
From shared pools, billed monthly on what is actually used. Capacity moves to the tenants that need it rather than being bought per customer up front — so nothing sits stranded in a quiet account while a growing one runs short.
What happens when a customer grows mid-month?
They draw more from the pool. Because billing is usage-based and monthly, growth does not mean renegotiating a block or buying ahead of demand — which is the part that normally makes onboarding a commercial conversation rather than an operational one.
How is administrative access scoped?
Two dimensions. A Master Admin sees the other tenants on the account as well; an Account Admin sees only their own. Each is then either Full Control or Read Only, where read-only can view the interface without changing anything — which is what an auditor or a junior analyst should have. A group running several tenants of its own uses the same two settings.
Does the provider hold permanent access into customer tenants?
No, and the switch belongs to the tenant rather than to you. With Remote Support off, nobody above that tenant can administer it — not the partner managing them, not the MSSP above that, and not Mirket. Only that tenant's own administrators. Standing access into every customer you manage would be a liability on all of them at the same time.
Who creates a tenant, and how are its licences assigned?
You do, as an MSSP partner. Creating, editing and removing a tenant and assigning its licences from your shared pool all sit in your own console, so onboarding a customer is an operational step rather than a purchasing one. Go to Portal then opens that customer's portal in a new tab when you need to work inside it.
Is this a separate management product from what customers get?
No, and that matters operationally. It is the same platform — MFA, SSO, Secure Self-Service and ITDR — over one directory per tenant. What you sell and what you operate are the same product rather than a management layer bolted over the top.
Does this work for a large group with many subsidiaries?
Yes. The shape is identical — many separate entities, each needing its own users, policies and boundaries, managed centrally. The word MSSP describes the commercial model rather than the architecture.
Which modules are available per tenant?
MFA, SSO, Secure Self-Service and ITDR, over that tenant's own directory. ITDR reads the sign-ins those modules produce, so it applies where they are running as a service — Deployment sets out the full picture.
Is it available on-premise?
The multi-tenant model is a SaaS one — a single platform serving many tenants is the thing being described. A single organisation running everything on its own hardware is a different shape, and Deployment covers that one.
Related
Solutions — Self-Service Password Reset · Adaptive Authentication · Account Takeover & Compromised Credential Detection · On-Premise SSO
Products — Multi-Factor Authentication · Single Sign-On · Identity Threat Detection & Response