A secrets manager concentrates the credentials for your databases, clouds and APIs in one place, so a wildcard access policy, a long-lived root token or an audit log nobody reads turns your best control into your largest single point of compromise. This health check is a recurring, measurable review of the secrets management platform itself: its cluster or cloud service, the authentication methods machines and people use to reach it, access policies, root and recovery material, audit logging, replication and backups, and the administrators and automation that run it. It gives a platform owner, internal auditor or CISO twelve metrics with formulas and thresholds to compare quarter on quarter.
This page measures the platform. It does not explain secrets management as a discipline, nor does it measure how well secrets are handled across the whole organisation. For the discipline, read the Secrets Management Guide and the Cloud Secrets Managers Guide, and go back to them for every finding. The check is vendor-neutral: it applies to self-hosted secrets servers, cloud provider secrets services and SaaS secrets platforms.
What this health check covers
The OWASP Secrets Management Cheat Sheet sets out what a secrets platform must do well: least-privilege access so no one can read or change every secret, fine-grained policies, audit of who requested which secret and when, tamper-protected logs, high availability, automated and tested backups, and break-glass access held in a separate system. This review turns those into measurements of the platform:
- How clients authenticate: whether workloads use platform identity (cloud workload identity, container orchestrator service account tokens, certificates) or static tokens and passwords that are themselves secrets.
- Policy quality: how many policies grant broad paths, wildcard rights or administrative capabilities.
- Root and recovery material: root tokens, recovery or unseal keys, and the keys that encrypt the store.
- Visibility: whether every request reaches an audit log you can search and alert on.
- Resilience: replication, backup and restore, and how the platform behaves when it is unavailable.
Who runs it: the platform owner (often platform engineering or the identity team) collects data; security architecture reviews it; the CISO or head of platform signs off. What it is not: a programme review of secret sprawl, leaked secrets in code or rotation across every application. Those outcome measures sit in the separate secrets management programme health check, and this page shares no metrics with it. Teams searching for a "secrets manager audit checklist", "vault health check" or "secrets platform KPIs" can use the table as-is.
Key takeaways
- Secret zero decides everything. If workloads reach the manager with a static token, you have moved the secret, not protected it; measure the share of clients using platform identity.
- Policies drift wide. Count wildcard and administrative grants every quarter; the OWASP cheat sheet's test is that no single identity can read or change every secret.
- Root material should not exist day to day. Track live root tokens and who holds recovery key shares, not just whether a procedure exists.
- Audit logging is a dependency, not a feature. Measure that every node's audit events reach your SIEM, and that alerts on policy and root events are triaged.
- Prove recovery. A restore drill and a tested break-glass path are the only evidence that a platform outage will not stop deployments and incident response.
How to use this template
Copy the metrics table and findings log into your own tracker and run this Secrets manager health check at the cadence below. Collect each figure from the data sources described, score it against the bands, and record every amber or red result as a finding with an owner and due date. If you run several secrets platforms (for example one self-hosted and a cloud service per provider), score each separately and report the worst result per metric alongside each platform's figure.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Audit log flow and alert triage check | Weekly | Platform operations | Platform owner | SIEM source status, alert queue extract |
| Policy and auth method review | Monthly | Platform operations | Platform owner | Policy export, auth method list with bound roles |
| Full metrics review (this page) | Quarterly | Platform owner | CISO or head of platform | Metrics table, raw extracts, findings log |
| Administrator and recovery key holder recertification | Quarterly | Identity governance | Platform owner | Admin list, key share holder list, decisions |
| Restore and break-glass drill | Twice a year | Platform owner | CISO | Drill plan, timings, issues found |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Client" means any workload, pipeline or service identity that authenticates to the platform; "secret" means any stored or generated credential, key or certificate the platform serves.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| SMP-01 | Identity-based client authentication | Clients authenticating with platform identity (workload identity federation, orchestrator service account tokens, certificates) ÷ all active clients | Platform auth method list, authentication events in the audit log | At least 90% | 70% to below 90% | Below 70% |
| SMP-02 | Long-lived client tokens | Active client tokens or static credentials with no expiry or a maximum lifetime above 30 days ÷ active client tokens and static credentials | Platform token and credential metadata | Below 5% | 5% to 15% | Above 15% |
| SMP-03 | Broad policies | Policies or role bindings granting wildcard paths across more than one application, or administrative capabilities, to non-administrator identities ÷ all policies | Policy export, role binding export | 0 | Exceptions with approver and expiry | Any unapproved |
| SMP-04 | Environment separation | Clients from non-production that can read production secrets ÷ non-production clients | Policy export joined to client environment tags or namespaces | 0 | Exceptions with approver and expiry | Any unapproved |
| SMP-05 | Root and recovery material | Live root or equivalent all-powerful tokens plus recovery key shares held by people who have left or changed role | Platform token list, key share holder register | 0 | Not applicable: any count above 0 is red | 1 or more |
| SMP-06 | Standing administrators | Human accounts with permanent platform administrator rights ÷ human accounts with any platform role | Platform role export, PAM records, directory groups | Below 5%, all phishing-resistant MFA | 5% to 10% | Above 10%, or any without MFA |
| SMP-07 | Ownerless secret paths | Secret paths, folders or namespaces with no owner tag, or an owner group with no active members ÷ secret paths | Platform metadata export joined to directory groups | Below 2% | 2% to 10% | Above 10% |
| SMP-08 | Dormant stored secrets | Stored secrets with no read in 180 days ÷ stored secrets | Audit log read events per path, platform metadata | Below 10% | 10% to 25% | Above 25% |
| SMP-09 | Audit coverage | Platform nodes or service regions whose audit events reached the SIEM in the last 24 hours ÷ nodes or regions | Platform audit configuration, SIEM source inventory | 100% | Gaps under 24 hours | Any gap of 24 hours or more, or a single audit sink with no failover |
| SMP-10 | High-risk events triaged | Alerts for policy change, root token use, auth method change, audit device change and bulk reads triaged within 24 hours ÷ such alerts raised | SIEM alert queue, case records | 100% | 90% to below 100% | Below 90% |
| SMP-11 | Platform currency | Platform nodes, agents and client libraries on a version within the vendor's supported releases ÷ components | Node version report, agent inventory, vendor support list | 100% | 95% to below 100% | Below 95%, or any unsupported server version |
| SMP-12 | Proven recovery | Months since the last successful restore from backup into a clean environment and the last tested break-glass access; report the higher | Drill records, backup job logs | 6 months or less | Over 6 to 12 months | Over 12 months, or never tested |
For SMP-05 the amber band is intentionally empty: there is no tolerable level of unmanaged root material. Rotation and age of the secrets themselves, leaked secret counts and hard-coded secrets are programme outcomes, so they are not repeated here; How to measure secret age and rotation coverage covers that measurement.
How to collect the data
- List clients and how they log in. Export every enabled authentication method with its bound roles, then count distinct clients per method from authentication events in the last 30 days (SMP-01). A client that logs in with a token created by a person counts as static.
- Export tokens and static credentials. Take token metadata (creation time, expiry, maximum lifetime, policies attached) and any static client passwords or keys (SMP-02, SMP-05). Never export token values.
- Export policies. Parse each policy for wildcard paths, cross-application scope and administrative capabilities such as managing policies, auth methods or audit devices (SMP-03). Join client environment tags or namespaces to policy grants to find non-production clients reading production paths (SMP-04).
- Reconcile recovery material. Compare the recovery or unseal key share register with HR leaver and mover records (SMP-05). Shares must be split across people who cannot all be compromised at once, as the Cryptographic Key Management Guide describes for key custodians.
- Export administrators. List human roles with assignment type and MFA status (SMP-06).
- Read metadata and access history. Export path metadata with owner tags and join to directory groups (SMP-07). From the audit log, take the last read time per path (SMP-08). Dormant secrets are candidates for removal, not for rotation.
- Check log flow and alerts. Read audit device or log export configuration per node or region, then query the SIEM for events from each (SMP-09). Pull the alert queue for the high-risk event types (SMP-10).
- Check versions and drills. Export component versions (SMP-11) and the latest drill records (SMP-12). The Secrets Manager Resilience Guide describes what a meaningful restore test includes.
Red flags that need action now
- A root or equivalent all-powerful token that is live outside a recorded break-glass event.
- A policy granting read on every path to a pipeline, application or broad human group.
- Audit logging disabled on any node, or a single audit sink whose failure would go unnoticed.
- The platform's own bootstrap token or unseal material stored in a repository, pipeline variable or shared document.
- Non-production workloads able to read production database or cloud credentials.
- A sudden bulk read of many paths by one client, or reads from a client in a location it has never used.
- A platform administrator account without phishing-resistant MFA, or a shared administrator login.
- No successful restore in 12 months, or break-glass credentials stored only inside the platform they are meant to recover.
The Leaked secret breaches guide collects lessons from incidents where stored credentials were exposed. If a red flag suggests misuse, move to If your secrets manager is compromised.
Findings log
Record each amber or red result and each red flag. Carry open items forward.
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-SMP-01 | [e.g. 38% of CI pipelines authenticate with static tokens created by engineers] | SMP-01, SMP-02 | [High] | [Platform engineering lead] | [Date] | [Open] |
| HC-SMP-02 | [e.g. Two recovery key shares held by staff who left in the quarter] | SMP-05 | [Critical] | [Platform owner] | [Date] | [Open] |
| HC-SMP-03 | [Description] | [ID] | [Critical / High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
Suggested due dates: critical within 7 days, high within 30 days, medium within 90 days. A risk acceptance needs a named approver and an expiry date.
Remediation map
| Finding type | Where to fix it |
|---|---|
| Static client tokens, secret zero | Dynamic Secrets and Ephemeral Credentials Guide, Secrets Management Guide |
| Broad policies, environment mixing, ownerless paths | Secrets Management Policy Template, NHI Ownership Guide |
| Root material, administrators, key custody | Privileged Access Management Guide, Cryptographic Key Management Guide |
| Restore, availability, break-glass | Secrets Manager Resilience Guide |
| Rollout gaps, clients still outside the platform | Secrets manager rollout playbook |
| Platform-specific settings in the cloud | Cloud Secrets Managers Guide |
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 |
|---|---|---|---|
| Client authentication and tokens (SMP-01, 02) | PR.AA-01 | IA-5, IA-2 | Control 5, Control 6 |
| Policies and separation (SMP-03, 04, 07) | PR.AA-05 | AC-3, AC-6 | Control 3, Control 6 |
| Root material and admins (SMP-05, 06) | PR.AA-05, PR.DS-01 | AC-2, AC-6, SC-12 | Control 5 |
| Stored secret hygiene (SMP-08) | ID.AM-02 | CM-8, IA-5 | Control 3 |
| Audit and alerting (SMP-09, 10) | PR.PS-04, DE.CM-09 | AU-2, AU-6, AU-9 | Control 8 |
| Currency and recovery (SMP-11, 12) | PR.PS-02, PR.IR-03 | SI-2, CP-9 | Control 7, Control 11 |
Related guides
- Secrets Management Guide: the discipline this platform supports.
- Secrets Management Maturity Model: place the results on a maturity level.
- Identity Security Metrics Guide: how these figures roll up into identity reporting.
- If your secrets manager is compromised: when a red flag is an incident.
- Secrets manager migration playbook: when findings point to replacing or consolidating platforms.
References
- 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
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Credentials from Password Stores
- CIS: Critical Security Controls v8.1
Related NHI Mgmt Group resources: Secrets Management Guide, Cloud Secrets Managers Guide, Secrets Management Maturity Model, If your secrets manager is compromised.