Skip to content

Credentials vault

The credentials vault holds the passwords, keys, and other secrets your team needs to manage a client’s estate. Every secret is encrypted, every reveal is recorded before the value is shown, and a technician can often use a credential without ever seeing it. This page explains how the vault is organized, who can do what with a credential, and what Outpost records. The console calls the records Credentials.

A credential has a Name, a Username, a Kind, a Collection, a Category, Labels, and Web addresses. These are stored readable so you can search and sort by them. Search never matches the secret.

The secret itself, the Notes, and the One-time code seed are encrypted. Outpost computes one-time codes from the seed and never shows the seed again after you save it.

The kinds are Login, Secure note, API key, SSH key, Certificate, License key, Wi-Fi, Database, and Other. A credential can be marked as an SNMP credential for network discovery.

When entering a credential, password fields have an eye button labeled Show password or Hide password to check the value you entered.

VaultWho can see itWhere in the console
A client’s credentialsAnyone with access to that client and to the credential’s collectionThe client’s Documentation > Credentials
Practice credentials (MSP plan)Your practice’s own credentials, not any client’sDocumentation > Credentials at practice level
My vault (MSP plan)Only you. Nobody else in the practice can read the list, and a reveal is still recorded.Documentation > My vault at practice level

Every credential belongs to a collection. A collection is a flat group with no nesting. Through the API, an administrator with vault:manage can move a disabled or deleted person’s My vault credentials into another collection as part of offboarding, without decrypting them.

Two things decide what you can do with a credential: your permissions, and the collection’s access table.

PermissionAllows
vault:readListing credentials and reading everything except the secret
vault:useUsing a credential in a shell or a remote session without seeing it. It does not include vault:read: a holder sees only the credentials they can use, by name.
vault:revealShowing the secret, a one-time code, or a previous value
vault:writeCreating and changing credentials and collections, and checking credentials out and in
vault:rotateChanging a credential’s password, and Rotate now on a managed local administrator password
vault:manageDeleting collections, access tables, Force check-in, and the departure reports
vault:shareSending a credential as a one-time link. See Share a credential securely.

A collection with Restrict this collection to the roles and people named below selected has an access table under Who can see it. Each row names a role or a person and a level:

LevelMeans
Can see itReveal and use
Can use it, not see itUse in a session, but never reveal
Can change itReveal, use, change, and read previous values

A row can be a deny instead of an allow. A deny always wins. With restriction off, anyone who can read the client’s credentials can read the collection’s. The whole table is saved at once, so an allow and a deny never disagree in between. Changing an access table or deleting a collection needs vault:manage.

On a credential, the The password card offers Reveal. Outpost asks Show this password on screen?, and the value appears when you select Show it. Under it, a receipt reads “This reveal was logged. Audit entry” followed by its number.

  • Copy puts the value on the clipboard and clears it after 90 seconds where the browser allows. When the browser does not, the console says so.
  • The value hides on its own after A revealed value hides after, minutes in Documentation > Settings, 30 by default. Working on the page resets the countdown.
  • Show the code on the One-time code card shows the current code. Only the code is shown, never the seed.
  • Show previous values on the Previous values card lists every value the credential has held. It needs Can change it access, and reading it is recorded the same way a reveal is. Keep this many old passwords in Settings sets how many are kept, 10 by default.

Outpost writes the audit entry before it decrypts the value. If the audit entry cannot be written, the value is not shown. A reveal of a credential that does not exist writes nothing. The entry records the credential’s name, the reason if one was asked for, and your address, never the secret. Reveals, uses, one-time code reads, previous value reads, link opens, and exports all appear in the audit log and feed the departure reports. See Audit logs and Password health and at-risk reports.

A reveal can ask for more before it shows anything:

  • Ask for a second factor before revealing it, on a credential, or Ask for a second factor before a reveal, in Settings, asks you to confirm it is you first, with a passkey, an authenticator code, or a recovery code. Your password is not accepted. See Confirm it is you. The confirmation stays good for A second factor stays good for, minutes, 15 by default. It belongs to this browser session, so a code entered in another browser does not count.
  • Ask why, every time it is revealed, on a credential, or Ask for a reason before a reveal, in Settings, asks Why are you revealing this? The answer is written on the audit entry.

The same rules apply to using a credential and to the one-time code. Step-up needs an authenticator app or a passkey on your account. See Secure your console account.

A technician with vault:use can hand a credential to an endpoint without the value reaching their browser:

  • Open shell as opens a shell on the endpoint the credential belongs to, running as that account. The agent signs in with the password directly, so nothing is typed into the shell.
  • Type into session has the agent type the password into an open remote session on that endpoint.

Each use is recorded as Used in a session when you start it. The grant behind it lasts 60 seconds and works once.

Changing a credential’s password in the console keeps the old value under Previous values. Change it by sets a date that appears on Expirations.

Outpost can also own the password of a local administrator account on an endpoint. A profile turns this on, and the agent sets a new password on the endpoint on a schedule. The credential shows a Rotated by Outpost card with the account, the endpoint, when it was last set, and Rotate now, which needs vault:rotate. Outpost stores the new password before the endpoint sets it, so nobody is locked out if the endpoint goes offline in the middle. A managed credential cannot be edited by hand: change the rotation policy instead. See Compliance.

A credential can be held by one person at a time. On the credential’s editor, select Let somebody take an exclusive hold on it and set How long a hold lasts, in minutes.

  • On the Checked out card, choose Hold it for (30 minutes, 2 hours, or 8 hours) and select Check out. Only you can check it back in, with Check in. When the hold runs out, Outpost checks it in.
  • While you hold it, nobody else can reveal it, use it, or change its password.
  • With Change the password when it is checked back in, a managed credential is rotated at check-in, so the value you saw stops working. A credential Outpost does not manage cannot be rotated for you, so Outpost raises a documentation alert asking someone to change it.

When someone holding a credential cannot be reached, a holder of vault:manage selects Force check-in, enters Why are you breaking it?, and selects Break the hold. The reason is recorded with their name, and an alert is raised. A break-glass action exists, and it is never quiet.

Outpost scores each password’s strength when it is saved and checks the vault every six hours for weak, reused, stale, and breached passwords. See Password health and at-risk reports.

Content is licensed CC BY 4.0. Code samples are MIT. Outpost and the Outpost mark are trademarks of Outpost Business Solutions, PBC and are not covered by either license.