Secrets Management Guide: Centralise, Restrict, Shorten and Remove

Secrets are the passwords of the machine world: API keys, database passwords, tokens, private keys and certificates that let software authenticate. Every organisation has thousands of them, and most secret-related breaches come not from sophisticated attacks but from secrets stored in the wrong place, shared too widely or left valid for years. This guide covers the practice: how to centralise secrets, restrict who can read them, shorten their lives, remove them where platforms can issue identity instead, solve "secret zero", deliver secrets safely to applications and AI agents, detect secrets outside the manager, and run the whole effort as a measured programme. It is written for platform, DevOps, application security and identity teams.

Key takeaways

• Four principles do most of the work. Centralise, restrict, shorten and remove: put secrets in a manager, limit who can read them, make them short-lived and eliminate them where the platform can issue identity instead.
• A vault solves storage, not sprawl. Pair it with scanning, ownership, metadata and rotation, or it becomes one more place secrets hide.
• Dynamic and secretless are the target state. Credentials generated per use, or workload identity with no stored secret at all, limit the damage of any leak to minutes or hours.
• Secret zero needs platform identity. Authenticating to the secrets manager with a master token in a config file only moves the problem.
• Deleting a leaked secret is not remediation. Revoke and rotate first: of the Docker Hub publishers Flare saw remove a leaked secret, 75% did not revoke the key.

What counts as a secret

A secret is any value that lets its holder authenticate, sign, decrypt or call an API as someone or something else. OWASP's NHI2 Secret Leakage names "API keys, tokens, encryption keys, and certificates"; in practice the list is longer.

Cryptographic keys bring extra discipline. NIST SP 800-57 defines a cryptoperiod as "the time span during which a specific key is authorized for use" and says a suitably defined one "limits the amount of exposure if a single key is compromised". See the Cryptographic Key Management Guide, the API Key Management Guide and the SSH Key Management Guide.

Where secrets end up without management

Platform-held environment variables are exposed too: the Railway breach saw an attacker decrypt customer variables with stolen CI credentials. The figures are vendor research, but consistent. GitGuardian's State of Secrets Sprawl 2026 reports 24,008 unique secrets exposed in MCP configuration files, says internal repositories are six times more likely than public ones to contain hard-coded secrets, and puts about 28% of incidents outside code repositories, in collaboration and productivity tools. In the Docker Hub Secrets Leak 2025, Flare found 10,456 images uploaded in one month exposing keys, many of them AI model keys, and in the tj-actions/changed-files Compromise 2025 CISA warned that the action exposed access keys, GitHub personal access tokens, npm tokens and private RSA keys. See the Top 10 Secrets Management Mistakes.

Principle 1: Centralise

• Approve a small set of managers: typically a cloud-native service per cloud and possibly one cross-platform vault, never one per team. OWASP's cheat sheet accepts that standardising "can mean that you use multiple secret management solutions", provided lifecycle, authentication and auditing are standardised across them.
• Migrate in risk order: move secrets from code, configuration and CI/CD variables into the manager, starting with production, privileged and externally exposed secrets.
• Record metadata with every secret: owner, consuming application, environment, type, creation and rotation dates, and who to contact. OWASP notes that without this metadata you "increase the probability of vendor lock-in" and cannot move or rotate secrets safely.
• Plan for outage: back up the manager, test restores and keep break-glass credentials in a secondary system, as OWASP recommends. See the Break-Glass Account Guide.

For product selection, see the Secrets Management Buyer's Guide.

Principle 2: Restrict

• One identity per application: grant each application access only to the secrets it needs, using its own identity, not a shared token.
• Separate by environment and team: use paths, namespaces or separate vaults so a test workload cannot read production secrets (OWASP NHI8).
• Keep people out: OWASP says engineers "should not have access to all secrets in the secrets management system". Most people should never need to see a production secret.
• Mind indirect access: Kubernetes warns that "A user who can create a Pod that uses a Secret can also see the value of that Secret", even without read permission on the Secret itself. Restrict list and watch on Secrets to system components, and enable encryption at rest, since Secrets are "stored unencrypted by default" in etcd.
• Audit every read: log who requested which secret, whether it was approved, when it was used, failed attempts and use of expired secrets.

Principle 3: Shorten

• Rotate static secrets automatically: on a schedule proportionate to risk and immediately after exposure. OWASP describes gradual, rapid and scheduled rotation strategies and a four-step pattern for automated rotation: create, set, test and finish.
• Use dynamic secrets: the manager creates a unique credential per request with a short lease and revokes it automatically. HashiCorp's database secrets engine documentation, for example, notes that unique credentials per service make it possible to trace questionable data access "to the specific instance of a service".
• Know the limits: OWASP cautions that restarting an application "does not itself revoke stolen credentials"; they remain usable until the backing service expires or revokes them.

See the Secrets Rotation Runbook Template for a step-by-step rotation procedure.

Principle 4: Remove

The most secure secret is one that does not exist. Replace stored secrets with platform-issued identity wherever you can:

• Cloud workloads: IAM roles, managed identities and attached service accounts. See the Cloud Workload Identity Guide.
• CI/CD and cross-cloud: workload identity federation. GitHub's documentation says OIDC means "You won't need to duplicate your cloud credentials as long-lived GitHub secrets"; the cloud issues a token valid for a single job. See the Workload Identity Federation Guide.
• Kubernetes: projected service account tokens mapped to cloud identities.
• Service to service: SPIFFE identities and mTLS. SPIFFE issues short-lived X.509 or JWT SVIDs and advises X.509 "whenever possible", because tokens are susceptible to replay.

Removal does not end token hygiene: federation still issues tokens that must be protected, scoped by audience and kept short-lived. See the NHI Authentication Guide.

Solving "secret zero"

An application needs a credential to fetch its other credentials from the secrets manager. If that first credential is a static token in a configuration file, the problem has only moved. Better approaches:

• Platform identity: authenticate to the manager with cloud IAM, Kubernetes service account tokens or CI/CD OIDC tokens, so the bootstrap credential is issued and rotated by the platform.
• Agents and sidecars: a sidecar authenticates with platform identity and writes secrets to a shared in-memory volume, as in OWASP's Kubernetes pattern, so the application never handles the bootstrap credential.
• Constrained bootstrap secrets: where one is unavoidable, make it single-use, short-lived and bound to a specific host or workload, and alert on reuse.

Delivering secrets to applications

Whatever the method, design applications to pick up rotated secrets without a restart and never to log them. Kubernetes reminds developers that an application must still avoid "logging the secret data in the clear" after reading it.

AI agents and MCP servers need the same care. The MCP security best practices warn against token passthrough, where a server forwards tokens not issued for it: controls that depend on the token audience are bypassed, audit trails blur, and "a malicious actor in possession of a stolen token can use the server as a proxy for data exfiltration." Give agents their own scoped, short-lived credentials from a manager rather than keys in prompts, memory or configuration files. See the MCP Security Guide and the LLMjacking Guide.

Detection: finding secrets outside the manager

• Shift left: scan in the IDE and pre-commit hooks, and block at push time. GitHub's push protection, for example, blocks secrets in command-line pushes, web commits and file uploads before they reach the repository.
• Scan history and artefacts: cover repository history, CI/CD logs, container registries, infrastructure-as-code, wikis, tickets and chat. Pattern-based detectors struggle with generic secrets such as passwords and custom tokens, so combine more than one detector, as OWASP suggests.
• Prioritise, but not only by validity: a live secret is urgent, yet GitGuardian reports that many critical secrets have no validation checker, so unvalidated findings still need triage.
• Watch the manager: alert on unusual read volumes, reads from new identities, concurrent reads of many secrets and attempts to use revoked secrets.
• Plant canaries: decoy keys in likely leak locations alert when used.
• Respond in order: OWASP's containment sequence is revocation, rotation, deletion from the exposed system, then using logs to establish who had access and when. Route findings to the owner with a deadline. See the Cloud Credential Compromise Playbook.

Running secrets management as a programme

Secrets work spans development, platform and security teams, so it needs an owner, a policy and a phased plan. The roadmap below is the implementation plan.

For CI/CD specifics, see the CI/CD Pipeline Identity Security Guide.

Common failure patterns

• Delete without revoke: the secret is removed from the image or commit but stays valid. Of the Docker Hub publishers Flare saw remove a leaked secret, 75% did not revoke it, and GitGuardian reports valid secrets from 2022 still active four years later.
• Third-party code with access to secrets: a compromised CI action or package reads every secret in the runner. CISA's tj-actions alert told users to treat exposed secrets as compromised and rotate them immediately.
• Developer machines as vaults: secrets in shells, IDEs and MCP configs. GitGuardian's analysis of the Shai-Hulud npm Worm 2025 found 59% of compromised machines were CI/CD runners rather than personal workstations.
• The vault as a new silo: secrets moved into a manager without owners or metadata, so nobody can rotate them safely.
• Static master token: secret zero solved with a long-lived token in a config file that unlocks everything.
• Rotation that breaks production: dependencies unmapped, so teams stop rotating after the first outage.
• Private repository complacency: treating internal repositories as safe, although GitGuardian finds them six times more likely than public ones to contain hard-coded secrets.

Framework mapping

This is an indicative NHI Mgmt Group alignment. IDs were checked against the NIST CSF 2.0 text, the SP 800-53 Rev. 5 catalogue, the ISO/IEC 27001:2022 Annex A control list and the CIS Controls assessment specification (safeguard numbers unchanged in v8.1).

Metrics that show progress

Practitioner checklist

• Approve a small set of secrets managers and migrate secrets into them with owners and metadata.
• Give each application and AI agent its own identity to the manager, scoped to its secrets.
• Solve secret zero with platform identity, not a static master token.
• Rotate static secrets automatically; adopt dynamic secrets for databases and cloud access.
• Replace secrets with workload identity and OIDC federation wherever the platform supports it.
• Turn on push protection and scan history, CI/CD, images and collaboration tools.
• Revoke and rotate leaked secrets before deleting them, and record who had access.
• Encrypt Kubernetes Secrets at rest and restrict who can create Pods that mount them.
• Log and monitor every read; alert on unusual volume and use of revoked secrets.
• Back up the manager and test break-glass access.
• Track programme metrics monthly and report progress.

Standards and references

• OWASP: Non-Human Identities Top 10 2025
• OWASP: Secrets Management Cheat Sheet
• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• SPIFFE: SPIFFE Concepts
• Kubernetes: Good practices for Kubernetes Secrets
• GitHub Docs: OpenID Connect
• GitHub Docs: Push protection
• Model Context Protocol: Security Best Practices
• CISA: Supply Chain Compromise of Third-Party tj-actions/changed-files and reviewdog/action-setup@v1
• GitGuardian: The State of Secrets Sprawl 2026
• BleepingComputer: Over 10,000 Docker Hub images found leaking credentials, auth keys

Related NHI Mgmt Group resources: Secrets Management Buyer's Guide · Top 10 Secrets Management Mistakes · API Key Management Guide · Secrets Rotation Runbook Template · Service Account Security Guide