Skip to content
Read the datasheet

Deliver identity security as a service, without building the platform

Your customers want MFA, single sign-on and identity threat detection run for them, not sold to them. Mirket is built for that: one multi-tenant console across every customer, capacity drawn from a shared pool and billed monthly on what's used, and support access you can switch on for a job and off afterwards. You operate the service. We build the platform underneath it.

What you can offer your customers

Four modules run as multi-tenant SaaS and are operated from your console. Three run inside each customer's own environment by design, and you deliver them per customer. Together they're the whole identity estate — the login, what happens after it, and the service accounts that never log in at all.

ModuleHow you deliver itWhat the customer gets
Multi-Factor AuthenticationMulti-tenant SaaSMFA for the customer's VPN, firewalls, Microsoft 365, Exchange, Windows/macOS/Linux logons and LDAP applications — run for every tenant from your console.
Single Sign-OnMulti-tenant SaaSA SAML, OAuth and OpenID Connect identity provider per tenant, with the customer's own applications federated to it.
Secure Self-ServiceMulti-tenant SaaSPassword reset, unlock and MFA enrolment the customer's users do themselves — the ticket category your desk no longer carries.
Identity Threat Detection & ResponseMulti-tenant SaaSBehavioural detection and automated response across every tenant, reading the sign-ins the other modules already produce. The natural core of a managed detection offer.
Privileged Access · ZTNA · LDAP ProxyDeployed per customerThese run inside the customer's own environment by design — recordings, credentials and directory traffic stay there. You deploy and operate them per customer, alongside the SaaS tenant.

The deployment split and the reason for it are on the deployment page.

Built to be operated for many customers

A managed identity practice is profitable when each new customer costs less to run than the last. That's an architecture question, and these are the answers.

One console for every tenant

Your analysts work across all your customers from one place. Adding a customer adds a tenant, not a login.

Tenant isolation you can describe

Each tenant's data and policy are separated by design — the answer you need when a customer's auditor asks how you keep them apart.

Shared licence pools, monthly billing

Capacity is drawn from a common pool and billed monthly on usage, so nothing sits stranded in a quiet tenant while a growing one waits for procurement.

Roles that match how you're organised

A Master Admin sees the account list; an Account Admin sees one tenant. Each in a Full Control or Read-Only profile — so your Tier 1 can look without touching.

Support access you switch on and off

Remote Support is toggled per tenant. You hold access to a customer's environment for the job in front of you, then remove it — not a standing key into every account you manage.

The customer's own wording and brand

Enrolment and notification emails are rewritten per tenant, SMS can go through the customer's own gateway, and each federated application carries its own name and logo.

Who this fits

Managed security service providers adding identity to a detection and response practice — ITDR reading every tenant's sign-ins is the natural centre of that. Managed service providers with a security line who want to stop reselling three identity products and operate one. Telecoms operators and hosting providers with a business customer base that keeps asking for MFA and SSO as a service. And distributors who want to offer a managed option to resellers under them.

The common thread is a customer base with a real on-premise footprint — Active Directory, legacy applications, servers — because that's where the platform's coverage is widest and where the cloud-only alternatives leave the most uncovered.

How the commercial model works

Licences are drawn from shared pools and billed monthly on usage, so you're not buying blocks ahead per customer and you're not stranding capacity in tenants that shrink. As your tenants grow, the pool grows with them; as they churn, so does your cost. The specific rates and pool terms are in the partner agreement, and deal registration applies to MSSP opportunities in the same way as to resold ones — the rules are here.

Getting started

  1. 1

    Tell us about your service

    The form below — what you run today, roughly how many customers, and whether identity would be a new line or replace something you resell.

  2. 2

    Platform walkthrough for your operators

    The multi-tenant console as your team would use it: creating a tenant, drawing from the pool, scoping an admin, toggling support access.

  3. 3

    Agreement

    Partner terms including the usage-based billing model, set out in writing.

  4. 4

    Your first tenant

    Usually an existing customer you already manage. Our engineers join the onboarding.

Start the conversation

We use these details to answer this enquiry. Nothing else.

See the multi-tenant console

A demo run the way you'd operate it — creating a tenant, drawing from the pool, scoping an operator.

By continuing, you accept our Privacy Policy and End User Licence Agreement. We use strictly necessary cookies to run this site. With your permission we would also use analytics and marketing cookies. You can change this at any time from Cookie Settings in the footer.