Skip to content
Read the datasheet
Book a Demo

Products

Seven modules. One platform.

01Access & Authentication

02Privileged & Zero Trust

03Threat Detection

Solutions

Authentication ends at the login. Identity security doesn't.

By industry

01Secure Access

02Privileged Access

03Zero Trust & Remote

04Non-Human Identity

05ITDR

06Operations

The opportunity

Your customers buy identity from one vendor and privileged access from another. Sell them one platform — on-premise or SaaS — with deal protection.

Apply to partner

01Partner with Mirket

Resources

Documentation, integration guides, the feature matrix, a glossary and release notes — the material behind the Mirket platform, mostly public.

01Resources

Company

Mirket is an identity security company: one platform for workforce, privileged and non-human identity, on your infrastructure or as a service. 400+ organisations.

01Company

Zero Trust & Remote

On-Premise

You asked to connect one administrator to a few servers. The VPN connected their laptop to everything

Privileged Remote Access Without a VPN

Administrators have to reach servers from outside — from home, on the road, during an incident. A VPN answers that small request with a large grant: it puts the whole laptop on the network and leaves a gateway listening on the internet. Here is what privileged remote access should do instead, and the architecture that delivers it.

Book a Demo The architecture
  • Named targets, not a network route
  • Every session authorised on its own
  • Credential injected, never on the laptop
  • Native RDP and SSH
  • Nothing listening at your edge
  • On-Premise

The request was small. The grant was not

The need is always specific: this engineer has to administer those four servers, from outside. What gets issued is VPN access, because the VPN is already there.

Traditional remote-access VPNs are designed to extend network connectivity. Even when firewall rules narrow that reach, the control model is still network access first — not per-session privileged access to a named target. Once the tunnel is up, the administrator’s laptop has an address on your internal network and can reach whatever those rules allow from there. The rules were written years ago, for machines that have since moved.

Reaching the fifth server isn’t a decision. Authorisation happened once, when the tunnel came up. After that, moving from the four servers they needed to anything else still permitted is routing rather than a fresh, identity-aware check.

A VPN was asked to connect one person to a few servers. It answered by connecting their laptop to your network.

And when the incident review asks what the administrator actually did in there, the VPN log has one answer: that they connected. Not what they ran, not what they changed, not what they took.

What privileged remote access should do

Five things, and they are worth holding any product to — ours included.

  1. Reach the target, not the network. Access is granted to specific authorised systems rather than an internal network route.
  2. Authorise every session. A connection to another system is another authorisation decision, not an inheritance from a tunnel that came up an hour ago.
  3. Keep privileged credentials off the endpoint. Credentials are injected into the session rather than revealed to the remote administrator.
  4. Record what happened. Privileged sessions leave video and searchable session evidence, not just a connection log.
  5. Expose no inbound remote-access gateway. Both sides initiate outbound connections, so no inbound listener is required at the customer edge.

ZTNA is the transport. PAM is the authority.

ZTNA gets the administrator to the authorised target without putting their laptop on the network. PAM decides who can connect, which account they can use and when, injects the credential, and records what happens next.

That division is the whole design. Most of what makes remote privileged access safe is not transport at all — it is the authorisation, the credential handling and the evidence, and all three stay where they already are.

Both ends dial outward end-to-end encrypted — the relay sits inside this span, not in it Administrator native RDP or SSH Mirket agent dials outward Mirket relay forwards ciphertext Connector + PAM inside your network, dials outward too The target one named system The relay never holds ✕Session keys ✕Privileged credentials ✕Session content ✕Policies ✕Recordings Compromise yields ciphertext — not privileged sessions Decided and kept inside your network ✓Who may connect, to what ✓Which account, injected ✓Command policy ✓Video and searchable transcript
The same PAM authority that governs an administrator sitting in the office governs one connecting from a hotel. What the remote path adds is transport — not a second access model.

The administrator connects. The password doesn’t.

PAM injects the privileged credential into the authorised session. The administrator does not need to know, copy or type the target account password on the remote laptop — which is what decides how much a compromised endpoint is actually worth. A phished laptop with a VPN client on it is a way in. A phished laptop with the Mirket agent on it holds no server credential to steal.

Mirket hosts the relay. You don’t have to trust it with the session.

The relay moves end-to-end encrypted traffic between the administrator and your environment. It does not hold the session keys, the privileged credentials, the policies or the recordings, and it cannot decrypt the privileged session. Compromise of the relay yields encrypted traffic, not privileged session content.

Nothing listens at your edge

The administrator-side agent and the customer-side connector both establish outbound connections. There is no inbound Mirket remote-access gateway waiting to be scanned, because the architecture never needed one.

Keep the tools administrators already use

Remote administrators continue working in native RDP and SSH rather than being pushed into a browser-only administration experience. Mirket’s isolated browser is there for the people who want it — a contractor, an auditor, an unmanaged machine — but it isn’t the price of admission for your own engineers.

Why the admin VPN persists

Why it persistsWhat’s actually going on
It’s what’s already thereThe VPN was bought for the workforce. Using it for administrators too costs nothing today, so the specific risk of privileged remote access never gets its own decision.
Network access is invisible until it’s abused“Connect once, reach everything still permitted” looks fine every day it isn’t exploited. The exposure is latent, so it doesn’t force a change.
Recording remote work seems separateSession recording is thought of as an internal PAM concern. Remote admin sessions arrive over the VPN and are never recorded, because the VPN’s job ended at “connected”.
Exposing the gateway feels unavoidable“Something has to listen for people to connect to” is assumed. That both ends could dial outward instead isn’t usually on the table.

A remote-access gateway has to listen on a public address, so it is scanned continuously and every advisory against it starts a race to patch. That is a real cost, but it isn’t the argument. The argument is the one before it: why expose a privileged remote-access gateway at all, if the architecture doesn’t require one?

Check your current privileged remote access

Three questions, answerable from what you already run.

1. How much can one remote administrator reach? Compare the systems they need with the network destinations available after the VPN connects. The route table shows the ranges the endpoint is being given a path towards — compare that reach with the handful of systems the administrator actually needs.

2. What privileged credential reaches their laptop? Does the administrator know, or type, the server credential locally? If so, that credential’s safety is now a property of a machine that also reads email.

3. Can you replay what they actually did? Not whether the VPN connected — the commands, the actions and the session itself.

If the answers are “more than they need”, “the privileged password” and “no”, the problem isn’t remote connectivity. It’s privileged remote access.

What changes

Traditional privileged remote accessWith Mirket
The remote laptop receives network reachOnly authorised targets are reachable
Access is established when the tunnel connectsEvery privileged session is separately authorised
A remote-access gateway listens on the internetNothing listens at the customer edge
The administrator handles the target credentialPAM injects it into the authorised session
The VPN records the connectionPAM records the privileged session
Network rules define the blast radiusTarget mapping defines what the administrator can reach
Remote work uses a separate security modelThe same PAM controls apply inside and outside the network

Solutions — Third-Party & Vendor Access · RDP & SSH Session Recording · Session Control & Command Policy · Just-in-Time Access

Products — Zero Trust Network Access · Privileged Access Management

Bring one admin VPN session.

We'll walk the same access through Mirket — the targets that become reachable, the credential that never arrives on the laptop, and the recording the session leaves behind.

Book a technical demo Explore Mirket ZTNA

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.