Four people, one account, and no way to tell them apart
Here is how the gap opens, and it opens without anyone doing anything wrong.
A server gets a local administrator account. It was needed during the build, the password went into a shared vault entry, and four people can read it. The account gets used — a few hundred sessions over two years, some from the infrastructure team, some from a consultant during a migration, one or two from a laptop that was later rebuilt. Then something goes wrong. A scheduled task is deleted, a firewall rule is loosened, a file appears where it shouldn’t. It is noticed three weeks later, which is the normal amount of time for this sort of thing to be noticed.
The Windows event log will tell you there was a logon at 02:14 from 10.42.6.19 as .\svc-admin. That is genuinely useful, and it is also where the trail ends.
The log records that a door opened. It has nothing to say about the room.
Which of the four people it was, whether that address belonged to a person or to a jump host everybody shares, what was typed, what was copied out — none of it was written down anywhere. Not because logging was misconfigured, but because a connection log was never meant to answer that question.
The account is shared. The sessions are not.
Attribution is the part most of this rests on, and it is solved before the session starts rather than during it.
The administrator never holds the target’s password. Mirket injects it into the session instead of handing it over, so it is never typed on a workstation, never cached by an RDP client, never sitting in Credential Manager or a runbook. The session belongs to the person Mirket authenticated, whatever the account on the far end happens to be called.
That turns a shared account from a forensic dead end into an ordinary operational convenience. Four people can still use svc-admin. What changes is that every session under it now has a name attached.
- A tier boundary that actually holds Microsoft's tier model says a Tier 0 credential should never be entered on a lower-tier machine. It is correct and nearly unenforceable with native tooling, because administrators have to work from somewhere. If the password is never typed, the boundary stops depending on people remembering where they are.
- Rotation stops being a project Nobody has to learn a new password, because nobody knew the old one. Changing it becomes a schedule rather than a change window — the mechanics are on Privileged Password Vaulting.
There is a second reason this matters, and it is the one people notice later: if a password can be typed, anyone holding it is indistinguishable from the person it was issued to. A recording would show a session under that account, correctly, and still not tell you who was at the keyboard.
Recorded on every path, which is what stops it being avoided
A recording platform that changes how people work has an expiry date. The administrators with the most tooling to lose are exactly the ones who will find the unrecorded route — not out of bad faith, but because their scripts, their keys and their muscle memory live somewhere else.
So the recording follows the session rather than the other way round:
| In the native client | A generated .rdp opened in Microsoft Remote Desktop, and the SSH client the operating system already provides for SSH and SFTP |
| In the browser | RDP and SSH themselves, run inside Mirket’s isolated browser over HTML5 — the same shell and the same desktop, with nothing installed on the machine. Web consoles open the same way |
Both produce the same recording. That is the whole design argument: there is no faster way in that happens to be the unmonitored one.
Video proves what happened. Text is what makes it findable.
Every session produces two artefacts, and the second is what rescues the first.
An eight-hour session is eight hours of video. Kept for compliance, opened approximately never — which is how organisations discover years later that the recording wasn’t capturing what they assumed.
The command transcript changes the unit of work from watching to searching. Look for the command, and the player moves to the second it was typed. An auditor who would rather work in a spreadsheet can take the transcript as CSV instead.
Escalation stays inside the recording
A session that begins as a named user and continues as root is two identities in one sitting. Split across two records — or worse, with the second half missing — it stops being evidence and becomes an argument.
Mirket keeps it as one continuous recording with the escalation visible inside it, so the transition is part of the story rather than a gap somebody has to explain.
Whether that escalation should have been allowed at all is a different control, and it lives on Session Control & Command Policy.
The recording has to outlive the person being recorded
An audit trail the subject can reach is not an audit trail. Nobody in a session can stop it, edit it or delete it — and that includes people who hold administrative rights on the platform itself.
Live sessions can also be watched while they are happening, and terminated if they need to be. A reviewer can join one with a chosen level of authority, which is the difference between supervising a risky change and finding out about it afterwards.
Where the evidence lives
Session video and command transcripts are among the most sensitive records an organisation holds — a complete account of what your most privileged people do, searchable.
Mirket PAM is deployed on your own servers, so none of it leaves your environment. That is not a limitation of the product; it is the reason the module is offered this way at all. Deployment sets out which modules run where, and why each one sits where it does.
What changes with Mirket
| Before | With Mirket |
|---|---|
| A logon event with a source address | A session tied to a named person |
| Four people share one account, indistinguishably | The account is still shared; the sessions are not |
| The password is typed on an administrator’s laptop | It is injected, and never reaches the administrator’s endpoint |
| A tier model that cannot be enforced in practice | The Tier 0 credential never reaches a lower-tier machine |
| The password cannot change without telling people | It changes on a schedule, and nobody needs telling |
| “What did they do?” is answered from memory | It is answered from the transcript |
| Recording happens only where a browser was used | The same recording on the native path and the browser |
| An eight-hour video nobody opens | A command search that lands on the second it happened |
| Escalation to root breaks the trail | It stays inside the recording |
Frequently asked questions
What is privileged session recording?
Capturing what actually happened inside an administrative session, rather than only the fact that it took place. A connection log tells you an account signed in from an address. A recording tells you which person it was, what they ran, and what they moved.
Does Mirket record video, text, or both?
Both, and the second is what makes the first usable. Every session produces a video and a command transcript as text. Searching the transcript moves the player to the moment the command was typed, so an eight-hour session becomes a search rather than an evening.
Can I search recorded sessions by command?
Yes — that is the point of keeping text alongside the video. You can look for a specific command across sessions, and the transcript can be exported as CSV for an auditor who would rather work in a spreadsheet than a player.
Do administrators have to work in a browser to be recorded?
No, and this matters more than it sounds. Recording applies to native sessions as well as browser ones — whether the session was started from a launcher the portal generated or from the RDP and SSH tooling built into the Mirket agent. The browser option is not a lesser one either: it runs the same RDP and SSH sessions over HTML5, with nothing installed. A platform that only records one path is a platform people route around.
Does the administrator ever see the target password?
Not unless you want them to. The credential is injected into the session rather than handed over, so it is never typed on a workstation, never cached by a client, and never written in a note. That is also what makes attribution real rather than assumed.
How does this help with Microsoft's tier model?
A tier model says a Tier 0 credential should never be entered on a lower-tier machine. That is correct and close to unenforceable with native tooling, because administrators have to work from somewhere. If the password is never typed at all, the boundary holds without depending on anyone remembering where they are allowed to type.
What happens when someone escalates to root?
The escalation stays inside the same recording. A session that begins as a named user and continues as root is one continuous piece of evidence rather than two halves that have to be argued back together.
Can an administrator delete or edit their own recording?
No. Whoever is in the session cannot stop, alter or remove the recording of it, and that includes people with administrative rights on the platform itself. A recording anybody in the session can reach is not evidence.
Does this only cover servers, or web consoles too?
Both. A firewall interface, a hypervisor console or a published desktop application is an asset in the same way a server is, and sessions against them are recorded the same way. Web & Desktop Application Access covers that side.
Where are recordings stored?
In your environment. Mirket PAM is deployed on your own servers, so session video and command transcripts — some of the most sensitive data you hold — never leave it.
Can a recorded session be stopped while it is happening?
Yes. Live sessions can be watched and terminated, and a reviewer can join one with a chosen level of authority. What a session is permitted to do in the first place is Session Control & Command Policy.
Is this available as a service?
No, and the reason is the subject of this page. A session recording is a complete, searchable account of what your most privileged people do. Shipping that to somebody else's cloud would be an odd way to protect it, so PAM is an on-premise module. Deployment covers the whole picture.
Related
Solutions — Session Control & Command Policy · Privileged Password Vaulting · Just-in-Time Access · Third-Party & Vendor Access · Web & Desktop Application Access
Product — Privileged Access Management
Industries — Finance · Healthcare