Secrets Audit

A secrets audit is the systematic discovery and review of where credentials exist, how they are used, and whether they are exposed or obsolete. It helps organisations find hidden risk in codebases, developer machines, and shared systems. The audit provides the baseline needed to prioritize rotation and remediation.

Expanded Definition

A secrets audit is more than a one-time scan for hardcoded values. In NHI security, it is a structured review of where secrets live, who or what can access them, whether they are still needed, and whether their storage or distribution creates exposure. That includes API keys, service account credentials, tokens, certificates, and other machine-readable access material.

The term is used alongside controls for inventory, rotation, and access review, but it is narrower than general security assessment because it focuses on credential sprawl and lifecycle risk. Guidance varies across vendors on whether an audit must include validation of vault policies, CI/CD references, developer endpoints, and collaboration tools. NHI Management Group treats those sources as in scope when they can reveal active credential exposure. This aligns with the intent of the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, both of which emphasize finding and reducing identity-related attack paths.

The most common misapplication is treating a secrets audit as a scanner-only exercise, which occurs when teams ignore stale copies in tickets, build logs, and local tooling.

Examples and Use Cases

Implementing a secrets audit rigorously often introduces operational friction, because teams must balance visibility into credential locations against the time cost of reviewing legitimate development and deployment workflows.

• A platform team scans source repositories and discovers API keys embedded in test fixtures, then traces whether those keys also appear in build artifacts or container layers.
• A security team reviews collaboration tools for pasted tokens and confirms whether exposed values are active, duplicated, or already rotated, using lessons reflected in the Guide to the Secret Sprawl Challenge.
• A DevOps group audits CI/CD variables and runner logs after a pipeline compromise, then replaces long-lived secrets with tighter issuance practices informed by the CI/CD pipeline exploitation case study.
• An application owner validates whether service credentials are still tied to one workload or are shared across multiple apps, using the identity-and-secrets patterns highlighted in the 2025 State of NHIs and Secrets in Cybersecurity.
• A cloud engineer reviews Dockerfiles and environment variable handling after following the exposure patterns discussed in the State of Secrets Sprawl 2025.

These reviews are most useful when paired with the credential governance expectations described in NIST Cybersecurity Framework 2.0, especially where systems need repeatable inventory and remediation.

Why It Matters in NHI Security

Secrets audits matter because compromised machine credentials often bypass interactive controls entirely. If a token, key, or certificate is duplicated, embedded in code, or left active after offboarding, the resulting access can look legitimate even when no human login occurs. That is why secrets review is a core NHI control discipline, not just a hygiene task.

NHIMG research shows the scale of the problem: 62% of all secrets are duplicated and stored in multiple locations, and 44% of NHI tokens are exposed in the wild, often through chat tools, tickets, pages, or code commits. Those patterns create long-lived blast radius when one credential is discovered. They also map closely to the control expectations in OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls, where access review, least privilege, and configuration monitoring intersect.

Organisations typically encounter the operational need for a secrets audit only after a leaked token, breached pipeline, or offboarding failure, at which point the audit becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Secrets Inventory
• Who is accountable when an audit finds unmanaged service accounts or secrets?
• Why do fragmented vault and secrets manager deployments create access and audit risk at scale?
• What breaks when secrets are managed outside the same policy and audit model as privileged access?