A password has a history, and nobody writes it down
Take the domain administrator password, or the local administrator account on a hundred servers, or the one for the SAN. Follow any of them backwards.
It was created during a build or a migration, by somebody who may no longer work there. It was written down so the rest of the team could work — a shared vault entry, a spreadsheet on a file share, a wiki page, an appendix in a handover document. It was copied into whatever needed it: a monitoring check, a backup job, a deployment script, three runbooks. Each copy is now independent of the original and nobody keeps a list. It was shared in a ticket during an outage, in a chat message at 2am, read aloud to a vendor engineer on a call.
And it was never changed, because changing it means finding every one of those copies first, and nobody can promise they have found the last one.
The exposure isn’t that the password is weak. It’s that you can’t count who has seen it, and you can’t change it without an outage.
Every leaver takes their copy with them — not maliciously, they simply remember it, or it is still in a browser profile on a laptop that was wiped, or it is in an export of their password manager. The account doesn’t know they left.
Why rotation never happens
| Why it persists | What is actually going on |
|---|---|
| Rotation is an outage, not a task | The same password sits in a dozen configurations. Changing it means coordinating all of them on one night, with a rollback plan. It gets scheduled for a quiet weekend, then a quieter one |
| Nobody owns the list of copies | There is no authoritative record of where a password has been used, so rotation becomes an act of faith — and the first failure teaches everybody not to try again |
| A shared vault helped and hurt | It solved distribution and multiplied visibility. Twelve people can read the entry, and what gets recorded is that they opened it — not what happened next |
Nobody receives the password
Everything else on this page follows from one decision: the credential goes into the session, not to the person.
The administrator picks a target, not a password. Mirket completes the authentication on its own side, so there is nothing to save, nothing to screenshot, nothing sitting in Credential Manager afterwards, and nothing to take to a new job.
- The session becomes the audit record Not "user X opened entry Y at 14:02" — the actual session, as video and searchable transcript. What somebody did with a credential is the thing worth keeping.
- Attribution stops being guesswork A shared account can stay shared, because the session belongs to the person Mirket authenticated rather than to whoever knows the password.
Rotation stops being a change-control event
For the accounts on this page — the ones people log in with — the blocker was never the rotation itself. It was that the same password sat in a dozen places and changing it meant coordinating all of them.
Remove the copies and there is nothing to coordinate. Rotation is set per account — an interval in days and a time of day — and it happens. Nobody is notified, because nobody needed to know the old one.
Daily rotation is entirely reasonable for a credential no human ever types. The reason most organisations rotate annually is not policy; it is fear of the coordination.
⚠️ This reasoning is about interactive privileged accounts. A credential an application holds is a different problem — the application still has to be given the new value somehow, which is why it takes a different path. See below.
The accounts no directory manages
The local administrator account on each server is the one that appears in no group audit, survives every leaver process, and — if it came from a build image — may be identical across the estate. One of those machines being compromised is all of them being compromised.
Mirket’s discovery scans domain-joined servers and imports their local accounts, so they arrive in the vault rather than remaining the part of the estate nobody has a list of. The scan itself, and what to look for in the results, is on Privileged Account Discovery.
When somebody genuinely does need to see one
Sometimes a password has to be readable by a person — a vendor with a contractual requirement, a break-glass procedure, an appliance that can’t be reached any other way.
That is set on the credential, not on the vault: who may view this one, by user, by group or by an external source. Everything not explicitly made visible stays invisible, which is the right default and the opposite of how a shared folder behaves.
Being on the list isn’t the same as being the person
Authorisation answers who may. It doesn’t answer whether this is really them — and a signed-in console somebody walked away from, a browser left open on a shared workstation, or a session lifted off a laptop all look exactly like an authorised user to the system.
So revealing a password is an authentication of its own. The request goes to the registered phone and has to be approved there before anything is shown. Holding the session isn’t enough; the approval happens on a device the person has to be holding, which is the one thing a stolen session can’t supply.
And every reveal is recorded — who asked, which credential, when, and whether it was granted — as an auditable event rather than something that happened quietly inside a browser tab.
The list of people who have seen a privileged password stops being a guess, and becomes a list with dates on it.
That is the sentence this page has been working towards. The exposure was never that the password was weak; it was that nobody could count who had seen it. For a credential nobody is authorised to reveal, the count is zero and stays that way. For one somebody genuinely needs, the count is a record — made at the moment it happened, by a person who proved they were there.
When the vault itself is what’s down
A credential store that is unavailable during a major incident is a second incident. So the answer cannot live inside the same system.
Glass Break is a sealed, encrypted recovery package, reissued automatically whenever accounts or mappings change, and opened with a single-use recovery password kept offline — on paper, in a safe. It is deliberately awkward to use, because using it should be a decision somebody makes rather than a habit.
Application secrets take a different path
A password an application reads at start-up has nothing in common with one a person types, and treating them as the same thing is how secrets end up hard-coded.
| Secrets vault | Encrypted storage and lifecycle for application secrets and API keys |
| Credential provider | The application asks for its secret at run time instead of carrying a copy of it |
For the specific case of directory service accounts — the credential an application binds to Active Directory with — the answer is different again, and it is NHI LDAP Proxy.
What changes with Mirket
| Before | With Mirket |
|---|---|
| The password is in a vault, a runbook and four memories | It is in one place, and nobody has read it |
| Rotation is a weekend with a rollback plan | Rotation is an interval and a time of day |
| Leavers keep whatever they remember | There is nothing to remember |
| Local administrator accounts sit outside everything | They are discovered and brought in |
| The audit record is who opened the entry | The audit record is the session |
| Everyone in the folder can read everything in it | Visibility is set on each credential |
| The vault being down means no access at all | A sealed offline path exists, opened deliberately |
Frequently asked questions
What is privileged password vaulting?
Holding administrative credentials in one controlled place instead of in configurations, runbooks and people's memories. Storing them is the straightforward part. What decides whether a vault is useful is whether the password still has to be handed to a person in order to be used.
What is credential injection, and why does it matter?
The credential is placed into the session by the platform rather than shown to the administrator. They choose a target, not a password. Nothing reaches their clipboard, their browser profile or a screenshot — so there is no copy of it anywhere to go stale, leak or be taken to a new employer.
Isn't check-out and check-in good enough?
It records that somebody opened an entry, which is a different thing from knowing what they did with it. And the moment a password is checked out it exists on an endpoint you don't control. Injection removes both problems at once.
Why is rotation so hard without this?
Because the same password sits in a dozen configurations, and changing it means coordinating every one of them on the same night with a rollback plan. That is why rotation policies exist on paper. If nothing holds a copy, there is nothing to coordinate.
How often can passwords be rotated?
It is set per account — an interval in days and a time of day — and nothing else has to be touched for it to happen. Daily is entirely reasonable for credentials nobody ever types.
What about the local administrator account on every server?
That is the account no directory manages, and it survives every leaver process and every group cleanup. Discovery imports local accounts from domain-joined servers so they come into scope rather than staying outside it — Privileged Account Discovery covers how that scan works.
What if somebody genuinely does need to see a password?
Then that is set explicitly on that credential — who may view it, by user, by group or by an external source. Visibility is a property of the individual credential rather than of the vault, so everything else stays invisible by default. Being on that list is the first gate rather than the only one: revealing the password also requires the person to approve the request on their registered phone, and every reveal is logged with the account, the person and the time.
What happens if the vault is down during an incident?
Glass Break is a sealed recovery package, reissued whenever accounts or mappings change, opened with a single-use recovery password you keep offline. It exists precisely so that the platform being unavailable and the credentials being unavailable are not the same event.
Do application secrets work the same way?
No, deliberately. A password an application reads at start-up has different mechanics from one a person uses. Mirket handles those through a secrets vault for storage and lifecycle, and a credential provider so the application requests its secret at run time instead of carrying a copy.
How is this different from a team password manager?
A shared password manager solves distribution and multiplies visibility at the same time — twelve people can now read the credential, and what it records is that they opened the entry. Here the credential is not distributed at all, and what is recorded is the session it was used in.
Is it available as a service?
No, and for a credential store that is a feature rather than a restriction. Copying your privileged passwords into a vendor's cloud would solve one problem by creating a larger one, so this module stays on hardware you control. Deployment explains the split across modules.
Related
Solutions — Privileged Account Discovery · RDP & SSH Session Recording · Web & Desktop Application Access · LDAP Service Account Security · Service Account Password Rotation
Products — Privileged Access Management · NHI LDAP Proxy