Secrets Management, The Credential Half of Non-Human Identity

Definition

Secrets management is the practice of storing, distributing, rotating, and retiring the credential material used by non-human identities to authenticate, API keys, passwords, tokens, private keys, certificates, and database credentials. It is distinct from NHI management (which governs the identities themselves) but deeply coupled with it: identities without secret-management are credentials-in-config; secret-management without identities is a lookup service.

Four stages of secret-management maturity

Organisations typically evolve through four stages. Most sit between stage 1 and stage 2 today.

Stage	Pattern	Typical failure
1 · Credentials in code	Hardcoded in source files, config, environment variables; copied around.	Leak to public repos, containers, logs. The Shai-Hulud pattern.
2 · Centralised secret store	Static secrets held in Vault / Secrets Manager / Azure Key Vault; applications fetch on startup.	Static secrets still long-lived; rotation often manual.
3 · Dynamic secrets	Secrets generated on demand, short TTLs; applications re-fetch as needed.	Integration complexity; legacy apps can't handle TTLs.
4 · Secretless (workload identity)	No shared secret, workload presents cryptographic attestation of identity; cloud or service mesh issues short-lived credentials.	Architectural transition cost; unevenly available in legacy environments.

The trajectory is from shared secrets to no shared secrets. Each stage reduces the credential blast radius.

Centralised secret stores, the minimum viable state

A centralised secret store is the foundation of modern secret management. The role of the store is to:

Hold credentials encrypted at rest, in one auditable location.
Authenticate and authorise applications requesting credentials.
Emit audit logs of every credential access.
Expose APIs for scheduled rotation.

The major options:

HashiCorp Vault (IBM, post-2024 acquisition), open-source and enterprise. Broadest feature surface, most extensible; steepest learning curve.
AWS Secrets Manager, cloud-native, tightly integrated with AWS IAM and rotation.
Azure Key Vault, cloud-native, integrated with Azure managed identities and certificate lifecycle.
Google Cloud Secret Manager, cloud-native, integrated with GCP IAM.
CyberArk Conjur, enterprise secret management with strong PAM lineage.
Doppler, Infisical, Akeyless, SaaS-delivered secret management with simpler adoption models.

Dynamic and short-lived secrets

Rather than a long-lived database password held in a secret store, dynamic-secret patterns have the secret store create a fresh credential each time it is requested, with a short time-to-live. The workload receives a credential that expires in minutes or hours rather than months.

The benefits are cumulative:

Credentials that leak have a short useful lifetime.
Rotation is automatic and continuous.
Credential-theft detection is easier (any credential older than the TTL is suspicious).
The audit trail is per-workload-per-session rather than per-credential.

Dynamic-secret patterns are mature for databases (HashiCorp Vault's database secrets engine, for example), cloud IAM (STS credentials in AWS), and SSH access (Vault SSH engine, Teleport). They are less mature for SaaS APIs that do not support short-lived tokens.

Secret scanning, the leakage detector

Secret scanning is the complementary detection layer. It looks for credentials in places they should not be, public and private source repositories, container images, chat logs, developer machines, Jira tickets. The category has consolidated around a small number of vendors:

GitHub Secret Scanning, native in GitHub, partner-extensible, widely adopted.
GitLab Secret Detection, native in GitLab CI.
GitGuardian, the most widely-deployed dedicated vendor. Scans across source, CI, containers, and SaaS destinations.
TruffleHog (open source) and Truffle Security (commercial).
Doppler, secret management with integrated scanning.

Secret scanning is a detective control, not a preventative one. Its value depends on remediation speed, the time between detection and credential rotation. Mature programmes target minutes, not days.

Secretless patterns, workload identity federation

The end state of secret-management maturity is the elimination of shared secrets altogether. A workload proves its identity to the authentication authority (via a cryptographic attestation from the infrastructure) and receives a short-lived credential for the actual action. No static secret is ever stored anywhere.

The patterns that implement this:

SPIFFE / SPIRE, a CNCF-graduated open-source pattern for issuing workload-bound identities (SVIDs). Covered in depth in our SPIFFE/SPIRE framework page.
Workload Identity Federation, cloud-native features (AWS IAM Roles Anywhere, Azure Federated Identity Credentials, GCP Workload Identity Federation) that accept OIDC tokens from non-cloud workloads in exchange for cloud credentials.
Service mesh identity, Istio, Linkerd, Consul mesh, all issue workload-bound identities to pods and automatically manage mTLS between services.
IETF WIMSE, the emerging standards-track protocol-level framing for this pattern. Covered in our WIMSE framework page.

Vendor landscape, quick reference

Traditional secret managers: HashiCorp Vault (IBM), CyberArk Conjur, AWS/Azure/GCP native.
Modern SaaS secret managers: Doppler, Infisical, Akeyless.
Secret scanning: GitGuardian, GitHub Advanced Security, TruffleHog.
Workload identity: SPIFFE/SPIRE, Aembit, cloud-native federation features.
Short-lived credentials in specific contexts: Teleport (SSH, database, K8s), Smallstep (certificates), Boundary (network).

Frequently asked questions

Do database credentials count as non-human identities?

Yes. A database credential held by an application is a credential software uses to authenticate to another system, which is the defining property of a non-human identity. The reason it is often missed is organisational: database credentials are usually managed by application teams inside configuration or a secrets store, and never appear in the directory that the identity team inventories.

What is the difference between secrets management and NHI governance?

Secrets management answers where a credential is stored and how it is retrieved. NHI governance answers whether the identity behind that credential should exist, who is accountable for it, and what it may reach. A vault solves storage and retrieval and can eliminate hardcoded secrets, but it will happily store a credential for an over-privileged identity nobody owns. The two are complementary and neither substitutes for the other.

What is dynamic secret issuance and why does it matter?

Rather than storing a static password and handing it out, a secrets engine mints a credential on request, scoped and time-bound, and revokes it afterwards. It matters because it changes the failure mode: a leaked static credential is valid until someone notices, whereas a leaked dynamic credential expires on its own. Storage is the interim step; dynamic issuance is the target state.

How do you find secrets that are already exposed?

Three surfaces cover most exposure: source repositories including full commit history, CI/CD logs and build artefacts, and configuration in container images. Dedicated secrets-detection tooling covers the first well. The harder problem is what to do with a finding, because rotating a credential without knowing which systems consume it causes outages, which is why ownership attribution has to precede remediation at scale.

How often should secrets be rotated?

Frequently enough that the rotation path is exercised and known to work, which in practice means the interval matters less than the automation. A credential rotated automatically every thirty days is in a far better position than one rotated manually every ninety, because the manual process will eventually be skipped. Where rotation cannot be automated, register the exception with an owner and a review date rather than quietly extending the interval.