Secrets management is the practice of storing and controlling access to the credentials that applications and systems use — API keys, database passwords, access tokens, certificates and similar machine secrets — so they are not hard-coded, shared in chat or committed to git. It is distinct from a password manager, which is built for people signing into websites and apps. Secrets management is for the keys your software and CI/CD pipelines need to talk to databases, payment gateways, cloud services and other APIs.
For a small or medium-sized business running a website or cloud integrations, secrets often start as a line in a .env file or a message in team chat. That works until a repository is made public, a laptop is lost, or a contractor keeps a copy after the project ends.
Why plaintext secrets are a problem
When secrets sit in source code, files committed to git, shared drives or chat threads, anyone with access can use them. Common risks include:
- Accidental exposure: a private repository becomes public, a backup is shared too widely, or a config screenshot is posted for troubleshooting.
- Long-lived credentials: the same API key or database password stays unchanged for years, so one leak remains useful for a long time.
- No clear ownership: nobody knows who still has a copy, which environments share the same secret, or how to revoke it quickly.
- Over-broad access: one admin key is reused across staging and production, so a compromise of a lower-risk system reaches the live one.
Once a secret is in git history, deleting the line in a later commit is not enough: the old commit still holds the value. Preventing the secret from being committed is far safer.
How secrets management works
A typical setup includes:
- A vault or store: an encrypted place for secrets, separate from application code and from the password manager staff use for human logins.
- Access policies: rules for which people, services or environments may read which secrets, often aligned with role-based access control and least privilege.
- Rotation: changing secrets on a schedule or after a suspected leak, and updating every system that depends on them.
- Audit logs: records of who or what retrieved or changed a secret.
- Injection into apps and CI: the app or pipeline receives the secret at runtime from the vault or a secure environment variable, instead of from a file in the repository.
Cloud platforms, hosting panels and dedicated vault products all offer some of these features. The important part is one controlled place for machine credentials, rather than copies scattered across laptops and chats.
Secrets, password managers, SSO and MFA
These tools solve related but different problems:
- Secrets management covers machine and service credentials: API keys, database passwords, deploy tokens and certificates used by software.
- A password manager covers human logins: email, hosting panels, social accounts and shared business portals.
- Single sign-on (SSO) reduces how many human passwords staff need by using one company identity for many apps.
- Multi-factor authentication (MFA) adds a second check so a stolen human password alone is not enough.
In a zero trust approach, both people and services prove who they are and get only the access they need. Secrets management is one building block for the service side of that model.
A practical checklist for SMEs
- Map where secrets live today: source code, .env files, CI variables, hosting panels, chat history, shared drives and staff notes.
- Stop committing secrets: keep them out of git; use ignored local files for development and a vault or platform secret store for shared environments.
- Separate environments: use different credentials for development, staging and production.
- Apply least privilege: give each key only the permissions the app needs, and prefer short-lived tokens where the provider supports them.
- Rotate after leaks and when people leave: change any secret that may have been exposed or shared with someone who no longer needs it.
- Restrict who can view production secrets: limit vault and CI access to people who deploy or operate the systems, and review that list regularly.
Frequently asked questions
Is a .env file enough?
A local .env file that is never committed can be fine for one developer's machine. It is not enough for a team or for production: you still need a controlled way to store, share, rotate and revoke secrets across environments.
Do we need a dedicated vault product?
Not always. Many cloud and hosting platforms already provide encrypted secret stores for apps and pipelines. A dedicated vault helps when you have many services, stricter audit needs, or credentials shared across platforms. Start with what you already have, then tighten the gaps.
What if a secret was pushed to git?
Treat it as compromised: revoke or rotate it with the provider immediately, replace it everywhere it is used, then keep it out of the repository going forward. Cleaning old git history is a separate step and does not replace rotating the credential.
How is this different from encrypting a config file?
Encrypting a file helps at rest, but you still must manage who holds the decryption key, how the app gets the value at runtime, and how you rotate it. A secrets manager is built around those operational steps, not only encryption of a static file.
If you would like help reviewing how your apps and pipelines store service credentials, see our cybersecurity and compliance services.