Granted for the worst day of the year, kept for every other one
A database administrator needs production access for a failover, a quarterly patch and the occasional emergency. It gets granted once and stays, because taking it away means somebody has to give it back in the middle of an incident — and nobody wants to be the reason a recovery was delayed.
So access that was justified for a handful of hours is available for all of them.
That is where exposure accumulates, and it is not a discipline problem. Nothing in an ordinary environment is built to grant something for an afternoon: directory membership has no expiry, an approval flow waiting on one named person becomes decoration, and the standing grant is kept as the safety net precisely because the alternative is unreliable.
Removing access when the work is finished depends on somebody remembering. Nothing ever does.
Access with a request, a reason and an approver behind it
Mirket turns reaching a privileged system into something that has to be asked for and closes on its own.
The person picks the target as usual. Where the policy calls for it, they are asked for a window and a reason; a named approver decides; the session opens inside that window and ends with it. Nothing has to be revoked afterwards, because nothing was left open.
- What you get back from every session A request, a stated reason, a named approver, a window, and an identifier that ties all of it to the recording and the command transcript.
- What nobody has to do Remember. The window closes on the clock rather than on a task somebody was meant to complete after the incident was over.
It works best alongside credential injection and vaulting: the vault means nobody is carrying the password around, and this means nobody is carrying an open door around either.
It’s a third action on the policy you already have
Just-in-time is not a module sitting beside the access model. A session policy’s action can be accept, deny, or JIT, and everything else stays as it was — the same account mapping, the same matching by user, group, target and schedule.
The consequence is practical: there is no second access model to keep correct, no parallel set of entitlements drifting away from the first, and nothing to migrate. You turn it on for the policies where it belongs.
Schedule still applies underneath. If a policy doesn’t match outside working hours, it doesn’t match — the request flow never starts, so there is no separate clash rule to reason about.
The window is absolute, and approval doesn’t move it
The person picks a start and an end rather than a duration, with shortcuts for one, three, six, twelve and twenty-four hours, and writes a reason for the approver to decide on.
Approving does not start a clock. The window was fixed when it was requested, and approval only makes it valid:
| Approved… | What happens |
|---|---|
| Before the window starts | It opens as planned |
| After it has started | The end stays put, so the usable time is shorter — unless the approver moves it |
| After it has ended | No usable access is produced. The grant is recorded as never used |
That removes the ambiguity that otherwise creeps into every approval flow: when does the clock start, the moment I asked or the moment you said yes? Here it was settled at the moment of asking.
Approval that doesn’t wait on one person
If the approver is a single named individual, they are asleep, flying or on leave a meaningful part of the year — which is exactly why standing access survives as the safety net and the approval flow becomes decoration.
Several approvers can be named on a policy, and the first decision settles it; once a request is approved or declined, the others can no longer act on it. There is no automatic timeout either: an undecided request stays pending rather than quietly expiring into a yes or a no that nobody chose.
Nobody approves their own request
Anyone in a policy’s user list cannot be added as an approver on that same policy — saving the policy fails. Not flagged in a review, not caught by an auditor a year later. At configuration time, which is the only moment it costs nothing to fix.
No upper limit, on purpose
There is no maximum window length, and that is a design decision rather than an omission.
A limit invites the wrong conversation — arguing for exceptions, and a number that is too short for real work and too long to be meaningful. Visibility replaces the rule: as the approver edits the window, the calculated total duration updates live beside it.
Somebody who clicks the wrong month in a date picker will not notice the date. They will notice that it now says 720 hours.
When the window closes
Sessions opened under that grant are closed, and the person sees a termination message. Anything they have open through other policies is untouched — the expiry is scoped to the grant, not to the user.
After that the cycle simply starts again: reaching the asset means a new request. There is no quiet drift back into standing access, which is how most time-bound schemes actually die.
An approved grant can also be revoked early, including one approved for a window that hasn’t started yet.
One identifier, from the request to the transcript
Access and evidence usually live in different systems, which is why reconstructing an incident is archaeology.
Every request carries a JIT ID, and it is searchable and filterable. The same identifier appears on the request, on active sessions opened under it, in session history, in the audit log, and on the session recording and command transcript.
One JIT ID answers the whole chain: who asked, what reason they gave, who approved it, what window was granted, which sessions opened, and what was typed in them.
That correlation is also why overlapping requests for the same asset are refused. If two grants covered the same moment, a session could not be attributed to one of them, and the chain would break at exactly the point somebody needed it.
What changes with Mirket
| Before | With Mirket |
|---|---|
| Access granted for one afternoon is available for the whole year | It exists inside the window it was asked for |
| A stolen credential can be used immediately | Outside a window there is no session to open |
| Access is removed when somebody remembers | The window closes on the clock |
| One approver, sometimes asleep | Several approvers, first decision settles it |
| Self-approval is forbidden in a policy document | The policy refuses to save |
| “Do they still need it?” | “What did they ask for, and what did they do?” |
| Access and evidence live in different systems | One searchable identifier links them |
| The clock starts whenever the approval lands | The window was fixed when it was requested |
Frequently asked questions
What is just-in-time privileged access?
Making privileged access exist for a stated window rather than continuously. Somebody asks to reach a system, gives a reason, an approver decides, and the access ends when the window does.
What exactly becomes time-bound?
Access to the target through Mirket — whether a session opens at all, with the credential injected, under policy and on camera. Each one is requested for a specific window, approved by somebody else, and ends when that window does.
What does that change in practice?
Two things. Outside an approved window there is no session to open, so there is nothing standing for somebody to walk into. And every session that does happen carries a request, a stated reason and a named approver — which is the difference between an access log and an answer.
Is this a separate product from PAM?
No. It is a third possible action on a session policy. Where the action would otherwise be accept or deny, it can be JIT, and account mapping and policy matching are untouched. A parallel access model would be a second thing to keep correct.
How is the window decided?
The person picks a start and an end — with shortcuts for one, three, six, twelve and twenty-four hours — and writes a reason. The window is absolute: approving it does not shift it. Approve before it starts and it opens as planned; approve after it has started and the usable time is simply shorter, unless the approver moves the end.
Is there a maximum window length?
No, deliberately. Instead of a limit, the approval screen shows the calculated total duration live as the window is edited. An approver who clicks the wrong month will not notice the date, but will certainly notice that it now says 720 hours.
What if the approver is asleep or on leave?
Several approvers can be named on a policy and the first decision settles it — after that, the others cannot act on the request. There is no automatic timeout: an undecided request stays pending rather than quietly expiring into a yes or a no.
Can somebody approve their own request?
No, and it is refused at configuration time. Anyone in a policy's user list cannot be added as an approver on that same policy — saving the policy fails. That is deliberate: the rule belongs in the product rather than in a document nobody reads at three in the morning.
What happens when the window ends?
Sessions opened under that grant are closed. Anything the same person has open through other policies is untouched. They see a termination message, and reaching the asset again means a new request — the cycle starts over rather than drifting into standing access.
Can access be taken back early?
Yes. An approved grant can be revoked before its window ends, including one that has been approved but not yet started. Without that, approvers grant shorter windows than the work needs and people compensate by filing three requests instead of one.
Can I request two overlapping windows for the same system?
No — overlapping requests for the same asset are refused when you pick the dates. Separate windows are fine. The restriction exists so that a session can only ever belong to one grant, which is what keeps the audit chain unambiguous.
How do I connect a request to what was actually done?
Every request carries a JIT ID, and it is searchable. The same identifier appears on the request, on active sessions opened under it, in session history, in the audit log, and on the recording and command transcript — so one identifier gives an auditor the whole chain.
Is it available as a service?
No — it is part of Mirket PAM, which runs on your own servers. Since the decision governs whether a session opens at all, it lives in the same place the session does. Deployment covers which modules run where.
Related
Solutions — Privileged Password Vaulting · Third-Party & Vendor Access · Privileged Account Discovery · Session Control & Command Policy · RDP & SSH Session Recording
Product — Privileged Access Management