Password check-out with approval: controlling who uses privileged accounts, and when

In most companies the firewall admin password is known to the IT head, two engineers, the network vendor and possibly someone who left last year. Nobody can say who used it last Tuesday. Password check-out with approval is a simple control that fixes this for the handful of accounts that could take the company down: ask, give a reason, get approval, use it alone for a limited time, and change it afterwards.

Why privileged accounts need more than a shared vault

A shared vault solves the first problem, getting passwords out of spreadsheets and chat groups. Our guide to shared password management for IT teams covers that step. Privileged access management goes one step further for the accounts where a mistake or misuse does the most damage:

For these, "the team knows the password" is not good enough. You need to know who used it, when, why, and that the value they saw no longer works.

How password check-out with approval works

The flow has six steps.

1. Request. The engineer asks for access to the entry and gives a reason: "Firmware upgrade on the Pune firewall, change ticket 4471."
2. Approve. A safe manager, usually the IT head or the system owner, approves. The approval is time-limited, for example two hours.
3. Check out. The engineer checks the password out. While it is checked out, nobody else can use it.
4. Use. The engineer reveals or fills the password. Each reveal is logged with who, when and the reason.
5. Check in. When the work is done the engineer checks it back in. If they forget, it is released automatically after a set time.
6. Rotate. The password is changed, either by the engineer as part of check-in or automatically where the system supports it.

Step six is the one most teams skip, and it is the one that makes the rest worth doing. Password rotation after use means the value the engineer saw is useless the next day.

Vendor remote access

Vendors are where privileged passwords leak most often. The network partner has the switch password "for support", their engineer changes jobs, and the password goes with him.

A better pattern:

• The vendor's engineer has no standing access to the vault, or has only "ask for access" rights.
• Each visit or remote session is a request with a ticket number, approved for a few hours.
• The password is rotated when the session ends.
• The vendor's access is reviewed at contract renewal.

If a vendor insists they need the password permanently, ask why, and write the answer into the contract.

Break-glass access for emergencies

At 2 am the core switch fails and the IT head who approves requests is on a flight. Someone still needs the admin password. Break-glass access exists for this:

• only one or two named people (typically the most senior IT and security roles) can use it;
• they must type a reason;
• the use is flagged in the audit trail and reviewed the next working day;
• the password is rotated afterwards.

If break-glass is used more than a few times a year, the approval setup is wrong, not the emergency.

A worked example from a Pune manufacturer

A 900-person manufacturer has a three-person IT team and an outside network vendor.

• Before: the firewall, core switch and backup console passwords were in an Excel sheet on the IT head's laptop, also shared with the vendor on WhatsApp. They had not changed in two years.
• After: the three entries sit in a "Network and backup" safe. The IT engineers can request them with a reason; the IT head approves; check-out lasts up to four hours. The vendor's engineer can only ask for access, with a change ticket number.
• First month: 11 check-outs, each with a reason and a ticket. Two by the vendor, both followed by rotation. One break-glass use at night during a power failure, reviewed the next morning.

The change cost the team about a day of setup. The audit committee's question, "who can access the firewall?", now has a one-line answer.

What the audit trail should show

For each privileged entry, you should be able to pull up:

• every request, approval and refusal, with reasons;
• every check-out and check-in, with times;
• every reveal, copy and fill;
• every change of the password, and by whom;
• every break-glass use.

CERT-In's 2022 directions require service providers and body corporates to keep logs of their ICT systems for a rolling 180 days within India, and to report many kinds of cyber incidents within six hours. A clean access log for privileged accounts makes both much easier. Under the Digital Personal Data Protection Act, companies must also take reasonable security safeguards to prevent personal data breaches, and control of administrator accounts is about as basic as safeguards get.

Ask how the vault protects secrets

Before you trust any vault with privileged passwords, ask the vendor plainly: how are secrets encrypted, who holds the keys, and can the server read the passwords? There is a trade-off. A design where the server can open secrets, when your rules allow it, is what makes automatic rotation and remote reset possible. A design where it cannot is harder to automate. Neither is wrong, but you should know which you are buying.

Checklist

• List your privileged accounts, with an owner for each.
• Put them in a separate safe with approval and check-out turned on.
• Give vendors request-only access, tied to a ticket.
• Rotate after every check-out by a vendor, and after anyone leaves.
• Limit break-glass to two people and review every use.
• Review the audit trail monthly; it takes ten minutes.

In Vatsin Password Manager Pro, safes can require a reason and approval, approved access is temporary (120 minutes by default), an exclusive entry can be checked out and is released after 240 minutes by default with a reminder to change it, and every reveal is logged. Passwords there are encrypted with your company's key on Vatsin's server, which is what allows optional remote reset after approval. Tickets for access requests fit naturally into an IT helpdesk SLA as their own request type.