Most organisations own a secrets manager, yet API keys, passwords and tokens still live in code, pipelines and chat, and nobody can say whether the programme is shrinking that exposure. This health check is a quarterly audit of the secrets management programme as a whole: ten KPIs for adoption, sprawl, rotation, ownership and response, each with a formula, a data source type and green, amber and red thresholds, plus a cadence, a findings log and a remediation map. It is run by the platform or NHI governance team, checked by internal audit or the second line, and signed off by the CISO. The programme design is covered in the Secrets Management Guide; this page tests whether it is delivering.
What this health check covers
This is the programme view: outcomes across every team, repository, pipeline and secret store. It does not measure the health of the vault platform itself (availability, unseal and backup, policy configuration) or the tuning of the scanning tool (rule coverage, false positive handling); those are product questions with their own checks. Here the question is simpler: are fewer secrets exposed, are they rotated and owned, and how quickly is a leak closed?
If you searched for secrets management KPIs, how to audit secrets management or a secret sprawl audit, this is the scorecard. The Secret Sprawl Measurement Guide explains how to build exposure counts from scanner data and How to measure secret age and rotation coverage explains the timestamp work; this page fixes the ten numbers, their thresholds and who signs them off.
Key takeaways
- Adoption is the structural number: the share of workloads reading secrets from an approved store at runtime predicts most of the other KPIs.
- Revocation time is the response number: measure from first detection to the issuer rejecting the credential, not to the alert being closed.
- Age and rotation are two different facts: a rotation policy on paper means little if the 90th percentile secret is two years old.
- Every secret needs an owner: unowned secrets are the ones nobody rotates, revokes or deletes, so ownership is measured directly.
- Fewer stores is better: the number of places secrets are kept is a KPI because each store needs its own access control, audit and rotation.
How to use this template
Copy the metrics table and the findings log into your tracker and run this Secrets Management Health Check at the cadence below. Collect each figure from the data source types listed, score it against the thresholds and record every amber or red result as a finding with an owner and a due date. Keep each completed run so you can show the trend to leadership; a steady fall in hardcoded findings and revocation time is the clearest evidence the programme works. Replace bracketed placeholders such as [Organisation] and [Team] with your own values.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Leak response review (P3) | Monthly | Security operations lead | NHI governance lead | Leak alert list with detection and revocation timestamps |
| Exposure trend (P2, P9) | Monthly | Application security lead | NHI governance lead | Scanner finding exports for repositories and CI systems |
| Full KPI run (P1 to P10) | Quarterly | NHI governance lead | CISO | KPI workbook, findings log, sign-off record |
| Ownership and retirement clean-up review (P7, P8) | Quarterly | Team leads per [Team] | NHI governance lead | Store metadata export, owner attestations, deletion records |
| Independent re-performance | Yearly | Internal audit or second line | Audit committee | Re-performed samples, variance notes |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Workloads" means applications, services, jobs and pipelines in the application inventory that use at least one credential.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| P1 | Vault adoption rate | Workloads that obtain all their secrets from an approved store or by federation at runtime / workloads that use secrets | Application inventory; secret store access logs; workload identity federation configuration | 90% or above | 70% to below 90% | Below 70% |
| P2 | Hardcoded secret findings per repository | Open, verified secret findings in source code / active repositories; reported as a trend and for the top 10 repositories | Secret scanning findings export; repository inventory | 0.05 or below | Above 0.05 to 0.2, or rising for one quarter | Above 0.2, or rising two quarters in a row |
| P3 | Mean time to revoke leaked secret | Sum of hours from first detection to confirmed revocation at the issuer / leaked secrets revoked in the period; report median and 95th percentile alongside | Scanner alert timestamps; issuer revocation or rotation records | Mean 24 hours or less; critical secrets 4 hours or less | Above 24 to 72 hours | Above 72 hours, or any critical secret above 24 hours |
| P4 | Rotation compliance | Secrets rotated within the period set by their risk tier / secrets with a rotation requirement | Secret store metadata (created, rotated dates); rotation policy by tier | 95% or above | 85% to below 95% | Below 85% |
| P5 | Secret age P90 | 90th percentile days since creation or last rotation, across all static secrets in approved stores | Secret store metadata export | 90 days or less | Above 90 to 365 days | Above 365 days |
| P6 | Dynamic secret share | Credentials issued on demand with a lease or short-lived federated token / all credentials issued to workloads in the period | Secret store lease logs; identity provider token issue logs; static secret inventory | 50% or above | 20% to below 50% | Below 20% |
| P7 | Secrets with owner | Secrets in approved stores whose owner field names an active person or team / secrets in approved stores | Secret store metadata; HR and team directory | 98% or above | 90% to below 98% | Below 90% |
| P8 | Retirement clean-up rate | Secrets revoked within 30 days of their consuming application or owning team being retired / secrets whose consuming application or owning team was retired in the period | Application and service retirement records; secret store metadata and deletion records | 95% or above | 80% to below 95% | Below 80% |
| P9 | CI secret exposure findings | Secrets found in CI logs, build artefacts, pipeline variables in plain text or images in the period / active pipelines | CI system job logs; artefact and image scan results; pipeline configuration export | 0.01 or below | Above 0.01 to 0.05 | Above 0.05, or any production cloud key exposed |
| P10 | Secret store count | Distinct systems holding production secrets (vaults, cloud secret services, CI variable stores, config servers, password managers used for machine credentials), each listed in the register | Secret store register; cloud account and CI configuration review | 3 or fewer, all registered with an owner | 4 to 6, all registered | More than 6, or any unregistered store |
Notes on the formulas
- P1 counts runtime retrieval: a workload that copies a vault secret into an environment file at deploy time counts as not adopted. The OWASP Secrets Management Cheat Sheet recommends that deployed services fetch their own secrets at runtime rather than having them passed through the pipeline.
- P2 counts verified findings only: exclude findings marked as test data or false positives, but record the exclusion rate. A sudden rise in exclusions usually means alerts are being closed rather than fixed.
- P3 ends at the issuer: closing the alert or deleting the commit does not end exposure. A leaked source control token that stayed valid for more than a year after publication shows why: see this retail developer token exposure. The Developer Secret Scanning Triage guide covers the response steps.
- P4 and P5 need a tier policy: set rotation periods by risk tier in your Secrets Management Policy Template. User credentials are generally rotated on suspected compromise rather than on a schedule, so keep them out of P4.
- P6 is the long-term fix: dynamic secrets with short leases reduce the value of anything stolen. OWASP notes that restarting an application does not revoke credentials already stolen; a lease does.
- P8 closes the loop on retirement: when an application or team goes, its secrets should go too; dormant secrets inside a single store are measured on the platform health check instead.
How to collect the data
- Build the store register first: list every system that holds production secrets, with an owner. This is P10 and the scope for P4 to P8.
- Export store metadata: for each store, the secret list with path, type, owner, created, last rotated, last read and lease settings. Never export secret values; metadata only.
- Export scanner findings: verified findings for repositories and CI systems with first detected and resolved timestamps, location and resolution reason.
- Collect revocation evidence: for each leaked secret, the timestamp at which the issuer stopped accepting it (rotation record, key deletion event or a failed validation check).
- Join to the application inventory: map workloads to the stores they read from using access logs and workload identities, to calculate P1 and P6.
- Sample: trace five secrets and five findings per KPI from source to result, and record variances.
Red flags that need action now
- A verified production cloud, payment or identity provider credential exposed in code or CI and still valid after 24 hours (P3, P9).
- Any secret store that holds production credentials and is missing from the register (P10).
- Privileged secrets with no owner (P7).
- Static secrets older than three years on internet-facing services (P5).
- Hardcoded findings rising two quarters in a row while vault adoption is flat (P1, P2).
- Alerts closed as resolved with no issuer revocation evidence (P3).
- Pipeline logs or build artefacts that print secrets in plain text (P9).
Findings log
| Finding ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-SEC-01 | [Number] leaked secrets revoked after more than 72 hours | P3 | [High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
| HC-SEC-02 | [Number] workloads in [Team] reading secrets from files or variables | P1 | [Severity] | [Role] | [Date] | [Status] |
| HC-SEC-03 | [Number] secrets past their rotation period | P4, P5 | [Severity] | [Role] | [Date] | [Status] |
| HC-SEC-04 | [Store] holding production secrets not in the register | P10 | [Severity] | [Role] | [Date] | [Status] |
| HC-SEC-05 | [Finding] | [Metric] | [Severity] | [Role] | [Date] | [Status] |
Group secrets with one root cause into one finding. Risk accepted findings carry an expiry date and the approver's name and are re-opened at the next quarterly run.
Remediation map
| Finding type | Metrics | Where the fix is explained |
|---|---|---|
| Low adoption, too many stores | P1, P10 | Secrets manager rollout playbook; Secrets manager migration playbook |
| Hardcoded and CI exposure | P2, P9 | Git Secret Scanning Guide; How to find secrets in CI logs and build artefacts |
| Slow revocation | P3 | Developer Secret Scanning Triage |
| Rotation and age | P4, P5 | Credential Rotation at Scale; Secret Rotation Outage Troubleshooting Guide |
| Static secrets where dynamic is possible | P6 | Dynamic Secrets and Ephemeral Credentials Guide |
| Unowned secrets and secrets left after retirement | P7, P8 | Secrets Management Policy Template |
Related guides
- Secrets Management Guide: the programme this health check audits.
- Secrets Management Maturity Model: map the KPI results to a level.
- Secret Sprawl Measurement Guide: deeper method for exposure counts.
- If your secrets manager is compromised: when a finding becomes an incident.
- Leaked secret breaches: incidents behind the red flags.
References
Framework anchors for the KPIs: NIST SP 800-53 IA-5 (Authenticator Management), IA-5(7) (No Embedded Unencrypted Static Authenticators), SC-12 (Cryptographic Key Establishment and Management) and SC-28 (Protection of Information at Rest); NIST CSF 2.0 PR.AA-01; OWASP Non-Human Identities Top 10 2025 NHI2 Secret Leakage and NHI7 Long-Lived Secrets; MITRE ATT&CK T1552.001 Credentials In Files.
- OWASP: Secrets Management Cheat Sheet
- OWASP: Non-Human Identities Top 10 2025
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1552.001 Credentials In Files
Related NHI Mgmt Group resources: Secrets Management Guide, Secrets Management Maturity Model, Secret Sprawl Measurement Guide, Top 10 Secrets Management Mistakes.