What are shared credentials, and why are they risky?

Shared credentials are a single username and password, API key or token that several people use, so that the system on the other end sees one identity no matter which person is acting.

Where you find them

• SaaS dashboards without seats. A registrar, a status page, an old analytics tool where everyone signs in as ops@.
• Service keys used by people. The production database password that developers also use for manual queries.
• Root and admin accounts. A cloud root user or a router admin password kept "for emergencies" and known to half the team.
• Team .env files. Every developer holds the same staging keys, copied from the same file.

Some sharing is unavoidable. Many services don't offer per-person accounts on every plan, and many API keys are issued per account, not per user.

Why they are risky

• No attribution. The audit log says ops@ did it. You can't tell who, which turns a simple question into an investigation.
• Offboarding means a reissue. Removing one person from a shared credential means changing it for everyone. NIST SP 800-53 makes this an explicit control: organizations should "establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group" (NIST SP 800-53 Rev. 5, AC-2). Because it is disruptive, it tends to be skipped.
• Hidden second factors. A shared account's one-time codes often live on one person's phone. When that person leaves, the account becomes hard to recover.
• Wide blast radius. Everyone who knows the credential carries all of its power. See blast radius.

Better options, in order

1. Personal accounts wherever the service offers them, so each person can be removed alone.
2. One credential per consumer for machines: a key per service and per environment rather than one key for everything.
3. Narrow, replaceable shared credentials where sharing is unavoidable: least permissions, a recorded list of who knows them, a second factor the team controls, and a reissue on every departure.

Common mistakes

• Keeping the list of who knows it in someone's head. Without it, you don't know when a reissue is due.
• Sharing by chat. The password is then known to everyone in the channel, including future members.
• Not reissuing after a departure because "they were trustworthy". The control exists because you can't tell in advance.

How Crunu fits

Crunu doesn't turn a shared login into personal ones; that depends on the service. It changes how the values your team must share are held. Every member has their own account and their own keys; access is granted per person, per environment, often through an access profile such as Developers. Removing one person rotates the keys of the environments they could read, without anyone else re-entering anything, and the exposure report shows what they received.

What remains shared is the value at the provider. If three developers received a staging API key, the reissue checklist lists it when one of them leaves, and replacing it at the provider is still your step. The order of work on someone's last day, including shared logins and their second factors, is in what to rotate when a developer leaves.

Sources

• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, control AC-2, checked October 30, 2026.