Skip to main content

Exclusive checkout and check-in

Holding a credential for exclusive use, checking it back in, an administrator's force-release, and how this relates to the Master Policy exclusive access control.

Written for whoever runs IT5 min readUpdated

Checking out a credential holds it for your exclusive use — nobody else can start a session with it until you check it back in, the session ends, or an administrator force-releases it. Use the Checkout row action on a credential in Privileged → Vault, /pam/vault.

The three states the checkout dialog shows

Not checked out
A Reason field and a Check out button. Anyone with the right permission can take it.
Checked out by you
A Check in button to release your own hold.
Checked out by someone else
Who holds it and when they took it, plus a force-release option for anyone with the authority to use it — a type-to-confirm dialog naming the current holder, so a force-release is never a single misclick.

A force-release accepts an optional reason and ends the current holder's exclusive hold immediately, making the account available for another eligible operator. It does not remove the previous holder's underlying safe permissions.

When a checkout is taken for you automatically

If a credential's safe has Master Policy's Exclusive access control on — either at the organisation level or through a Master Policy exception scoped to that safe — a checkout hold is taken automatically and bound to the session the moment you start one, with no separate manual checkout step. A second person's attempt to start a session with the same credential is refused until you check in, your session ends, or an administrator force-releases the hold.

You can still check out a credential manually even when exclusive access is not on for its safe — it is a standalone control, not only a side effect of the policy setting.

What to read next

  1. Master Policy and its exceptions — the org-wide control that can take a checkout automatically.
  2. Starting a privileged session — what happens when a session actually starts against a checked-out credential.

Handing an account to the next operator

Before releasing another person's hold, confirm that their work has finished and check for an active privileged session. Force-release changes the checkout record; it does not itself terminate an existing connection or rotate the password. Use the session controls when a connection must be ended. Enter a clear operational reason so the audit event explains who released the hold and why.

Was this article wrong?

If a procedure here does not match what you see, or a limit we described has changed, tell us and we will fix the page. Email us about this article, or see how to get help if you need an answer rather than a correction.

Everything in privileged access