Store and manage database credentials securely across many connections

Working across dozens of databases usually means passwords living in scripts, config files, or sticky notes, and that's an audit finding waiting to happen.

The problem: credential sprawl

Every extra database connection a team manages is another place a password can end up written down somewhere it shouldn't be: a script, a shared spreadsheet, a config file someone forgot was readable by half the company. In an audited or regulated environment, that's not a theoretical risk. It's a finding.

The BroadSQL approach: one encrypted store, connect by name

Every connection BroadSQL knows about (the JDBC URL, the username, the password) lives in a single encrypted database, the Connections Definition File (CDF), unlocked by one master password. Day to day, nobody types a database password at all:

CONNECT finance_prod;
SELECT * FROM invoices WHERE status = 'OVERDUE';

The credential for finance_prod never appears in this session, in a script, or in anyone's notes. It's resolved from the vault. See Security for exactly how the CDF is encrypted and what its guarantees actually are.

Honest scope

This is encrypted credential storage and day-to-day convenience, not a replacement for a dedicated enterprise secrets manager with rotation, fine-grained access policies, and a full audit trail. If your compliance requirements go that far, BroadSQL's vault is a real improvement over passwords in scripts, but it isn't the last word in secrets management.

Who this is for

Compliance-conscious teams, and anyone in a regulated or public-sector environment where "where do your database passwords live" is a real question someone will ask.

Get set up properly

I set up the connections vault correctly for a team from day one, and can pair it with per-session activity logging for a full audit trail of who ran what, against which database. Get in touch to talk about your compliance requirements.