Which module runs where, and why
The honest version of a deployment table includes the reason. Where a module runs in one place only, the reason is what that placement protects — not a gap in the roadmap.
| Module | On-Premise | SaaS | Why it's placed this way |
|---|---|---|---|
| Multi-Factor Authentication | ✓ | ✓ | The same module either way. Run it on your servers or from our cloud. |
| Secure Self-Service | ✓ | ✓ | The same module either way, over the same directory. |
| Single Sign-On | ✓ | ✓ | Either way — with the on-premise option keeping SSO processing and identity data inside your environment. |
| Privileged Access Management | ✓ | — | Privileged credentials, session recordings and command transcripts stay inside your environment by design. |
| Zero Trust Network Access | ✓ | — | Authorization, credentials, policies and recordings stay on-premise. Only end-to-end encrypted session traffic crosses the Mirket Relay, which holds no session keys and cannot decrypt it. |
| NHI — LDAP Proxy | ✓ | — | Real service-account credentials and directory traffic stay inside your environment, while applications authenticate with scoped virtual credentials. |
| Identity Threat Detection & Response | — | ✓ | Scores the sign-ins the service platform already produces, so it needs MFA, SSO or Secure Self-Service running as a service. Delivered as a service so detection logic and threat intelligence can be updated continuously. |
Two shapes, and the choice between them is about ITDR
The privileged modules are settled either way: privileged access, zero trust network access and the LDAP proxy run on your own infrastructure, so the credentials, the session recordings and the directory traffic stay in your data center. What decides the shape is where the workforce modules run — and that in turn decides whether identity threat detection is available at all.
Everything on your own servers
Six modules on-premise: MFA, single sign-on, secure self-service, privileged access, zero trust network access and the LDAP proxy. Nothing about identity leaves your environment, including the authentication records. ITDR is not part of this shape — it scores the sign-ins the service platform produces, and an on-premise deployment doesn't produce any in our cloud for it to read. Organizations with a hard data-residency requirement usually choose this and accept that trade.
Workforce authentication as a service, privileged access on-premise
MFA, single sign-on and secure self-service run as a service, while privileged access, zero trust network access and the LDAP proxy stay on your own servers. This is the shape that makes identity threat detection possible: those sign-ins are already being processed in the Mirket cloud as part of delivering the modules, and ITDR scores them without exporting anything new.
Either way it's one set of users and one console. The difference isn't a compromise on one side and a full product on the other — it's which trade you'd rather make: keep every authentication record in your own data center, or gain a detection layer that stays current without an upgrade project.
What stays in your environment
For the on-premise modules, identity processing and the sensitive security data stay under your control: directory data, privileged credentials, PAM session recordings and command transcripts, policy and audit data all remain on infrastructure you operate.
For ZTNA, only end-to-end encrypted session traffic traverses the Mirket Relay. The relay holds no session key, cannot decrypt the traffic it forwards, and stores no session content — the authorization decision, the injected credential and the recording all stay inside your environment. The architecture is drawn out on the ZTNA page.
Run as a service, the same principle is kept at the edge. Lightweight gateways inside your network talk to the Mirket cloud outbound only, over HTTPS — there is no inbound port to open and nothing published to the internet. The Active Directory service account used for directory integration is entered on a gateway inside your network and stored there, encrypted.
Your Active Directory service-account credential is not stored in the Mirket cloud. It is held on the gateway inside your own network. And because credentials are verified locally against your directory, a user's password is never sent to the Mirket cloud.
How SaaS connects to your directory
Availability and upgrades
On-premise can run as an active-passive high-availability pair — a second node kept in continuous sync that takes over automatically if the primary stops responding — with upgrades applied through a web-based flow when you choose to run them. As a service, availability and updates are ours to run, and improvements arrive continuously rather than at a maintenance window.
Hardware sizing depends on the modules in use and the number of managed systems and concurrent sessions, and is scoped with you during planning rather than quoted as a fixed number here.
