Credential vault

This page explains what the Ironchip PAM credential vault is: the centralized, encrypted repository where your company’s privileged credentials live, how they are rotated and how they are recovered, in a controlled and audited way, during an emergency. It is for you if you administer privileged access or have to answer an audit.

A single encrypted store

All the credentials Ironchip PAM holds are in the Ironchip secret store, encrypted and separated by company: each company has its own space and none can read another’s. The platform database only keeps the description of each item (name, address, account), never the secret.

What it holds	Who uses it	Who can see it	Where it is managed
Resource credentials	The broker, when opening each session	Nobody. A managed password only comes out with a checkout	Resources
Passwords Ironchip manages and rotates	The broker and, in a checkout, whoever takes it out	Nobody has ever seen it; a checkout or a break-glass hands it over	Password rotation
Team passwords	People (a branch office router, a portal)	Its owner and whoever they share it with; every reveal is logged	Team passwords
Application and pipeline secrets	Your workloads, through the Vault-compatible API	Nobody in the console: values are written and never shown again	Secrets for applications
AWS, Google Cloud and Azure credentials	The store, to create short-lived credentials	Nobody, after you change them from the console	Short-lived credentials
Directory account (Active Directory, LDAP or Entra ID)	The store, to change domain passwords	Nobody, after you change it from the console	Directory

The console never returns a stored secret to you: when you edit a resource, the password field appears empty and, if you leave it that way, the current one is kept.

Automatic rotation

When you choose Managed by Ironchip as a resource’s method, nobody types or knows its password: Ironchip generates it in the store and changes it on its own.

• On a per-resource schedule: every hour, every 8 hours, every day, every week or every 30 days.
• After every session, as soon as the last open session on that account closes.
• When a checkout is returned, so the password that was handed over stops working.
• With the complexity you choose, for the whole company or for a specific resource.

The change is made by whoever can make it for each kind of resource: the database itself for PostgreSQL and MySQL, the machine’s agent for local Linux and Windows accounts, and the company’s directory for domain accounts. Assign the schedule according to how critical each resource is: for example, every hour and after every session for production servers, and every week for lab machines. See Password rotation.

Emergency recovery (break-glass)

There are two ways for a person to get a machine’s password, and both are recorded:

• Checkout, within an approved access window. Ironchip first asks for the access factors (for example, the confirmation on the phone) and a reason.
• Break-glass, for an emergency: members of a group you choose can take out the password of any managed machine without anyone’s approval, for a limited time and by writing down the reason.

In both cases, nothing changes the password while it is out, and as soon as it is returned or the time runs out it is rotated, so what was handed over stops working. PAM > Checkouts shows who took it out, when, from which machine, why and whether it has already been changed. See Checkouts and break-glass.

Compared with a traditional vault

	Traditional vault	Ironchip PAM vault
Normal use	Check-out of the password to connect	The broker injects it when connecting; the person does not see it
Password handed over	Valid until the next rotation	Rotated as soon as the checkout is returned or expires
Emergency	An emergency account in an envelope or a safe	Break-glass with a reason, a time limit, a record and rotation at the end
Application secrets	Another product	The same store, with a Vault-compatible API
Stolen login	Access to the vault and everything it holds	The checkout asks for the access factors; without them nothing comes out

More information

• Architecture: where the store is and which pieces use it.
• Recording and auditing: what evidence remains of each access.