Secrets Management

What is secrets management?

Secrets management is the practice of securely storing, distributing, rotating, and auditing the credentials that applications and infrastructure use: API keys, database passwords, private keys, certificates, and access tokens. The goal is to remove static secrets from code, configuration files, and human memory, and to place them behind a controlled, auditable interface.

How secrets management works

• Secrets are held in a dedicated vault, encrypted at rest and reachable only through authenticated calls.
• Applications retrieve them at run time instead of reading them from a file committed to a repository.
• Access is scoped by policy, so each workload retrieves only what it needs.
• Secrets are rotated on a schedule or on demand, ideally without a redeployment.
• Every retrieval is logged, which is what makes a compromise investigable afterward.

The secrets you know about are the easy ones

A vault protects what has been put into it. The exposure lives elsewhere: keys in local environment files, tokens pasted into a chat channel, credentials sitting in an old API testing collection, and personal access tokens a developer generated for a one-off script. None of those appear in the vault inventory, and most of them survive that person leaving the company.

Examples and use cases

A company deploys a vault and migrates its production credentials into it. Six months later, a departing engineer personal access token is still pulling from a private repository, because it was issued inside the code hosting platform and never touched the vault. Secrets management solved the infrastructure half. The other half is knowing which tokens and grants exist per person and revoking them at offboarding, which is what Corma covers across the SaaS estate.

Related concepts

• IAM for security teams
• Identity and access management platform
• Automated onboarding and offboarding for HR teams

FAQ

What counts as a secret?

Any credential granting access without a human present: API keys, database passwords, private keys, certificates, service account credentials, webhook signing keys, and access tokens.

Why not just use environment variables?

They are convenient and they leak. They end up in logs, in container images, in repository history, and on developer laptops, with no rotation path and no audit trail.

How often should secrets be rotated?

As often as the system allows without breaking, with immediate rotation after any suspected exposure and after any person with access leaves the company.

What replaces long-lived secrets?

Workload identity, where the platform issues short-lived credentials based on what the workload is, removing the static secret from the picture entirely.

Request a demo