Most organisations own a vault, yet most of their secrets still live in code, configuration files, pipeline variables and people's heads. Buying a secrets manager is a step, not a level of maturity. This model uses NHI Mgmt Group's five levels, Ad hoc to Optimised, to describe how secrets management progresses from hard-coded credentials to short-lived, automatically issued and rotated ones. It is for platform, DevOps and identity teams who need to score where they are, agree a realistic target and plan the next step. For the programme itself, tooling and rotation procedures, see the linked guides rather than this page.
Key takeaways
- The five levels are Ad hoc, Developing, Defined, Managed and Optimised, scored separately across seven capability areas.
- Coverage decides the level. A vault holding 20 percent of production secrets is Level 2, however good the vault is.
- Level 3 is the first sensible target: secrets centralised, owned, scanned before commit and covered by a written leak response.
- Level 4 changes the model, from storing and rotating static secrets to issuing short-lived and federated credentials so there is less to store.
- Measure outcomes, not tools: age of static secrets, share of secrets in a managed store, and time from leak report to revocation.
The five levels
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad hoc | Secrets are hard-coded in source, stored in .env and config files, shared over chat and baked into images. Nobody knows how many exist. Leaks are found by outsiders or attackers. |
| 2 | Developing | A vault or cloud secrets manager exists and some teams use it. Secret scanning runs on some repositories, often after the fact. Rotation is manual and happens after incidents. |
| 3 | Defined | A secrets standard says where secrets live, who owns them, maximum lifetimes and how they are retrieved. Production secrets are centralised, push protection blocks new leaks, and a leak response playbook is in use. |
| 4 | Managed | Rotation is automated and tested. CI/CD and cloud workloads use federation or dynamic credentials instead of stored keys. Secret access is logged and alerted on, and metrics are reported monthly. |
| 5 | Optimised | Static secrets are the exception, each with a documented reason. Credentials are issued per workload with short leases, revoked automatically on anomaly, and the root secrets that remain are held in HSM-backed or managed key services. |
Capability areas
Score each area separately. The OWASP Secrets Management Cheat Sheet section numbers show where the underlying practice is described.
| Capability area | Level 1 Ad hoc | Level 3 Defined | Level 5 Optimised |
|---|---|---|---|
| Discovery and inventory | No inventory; secrets found by accident | Scanning of repositories, history, images and CI logs; inventory of production secrets with owner and purpose | Continuous discovery across code, SaaS, tickets and endpoints, reconciled with the store |
| Storage and centralisation (OWASP 2.2) | Code, files, chat, personal password vaults | All production secrets in an approved store with per-secret access policy | Few stored secrets remain; most credentials are minted on request |
| Prevention (OWASP 8.x) | None | Pre-commit hooks and push protection on all repositories, with bypass limited to a delegated group | Prevention in IDE, commit, CI and registry, with every bypass reviewed |
| Delivery to workloads (OWASP 3.x, 5.1) | Hard-coded or environment variables set by hand | Runtime retrieval or mounted files; no secrets in images or pipeline logs | OIDC federation and workload identity; no long-lived secret in the pipeline |
| Rotation and lifetime (OWASP 2.7) | Never rotated; no expiry | Maximum lifetime per secret type; scheduled rotation for high-risk secrets | Dynamic credentials with short leases; rotation automated and tested for the rest |
| Monitoring and audit (OWASP 2.6) | No logs of secret access | Store audit logs kept and protected; alerts on unusual reads | Behavioural baselines per workload with automated revocation |
| Response (OWASP 9.2) | File deleted, secret left valid | Playbook: revoke, rotate, then remove, with log review over the exposure window | Revocation in minutes, triggered automatically from scanner findings |
The model maps to these framework controls, confirmed against the official catalogues:
| Framework | Control | What it asks for |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-5, IA-5(7) | Authenticator management; no embedded unencrypted static authenticators |
| NIST SP 800-53 Rev. 5 | SC-12, SC-28 | Cryptographic key establishment and management; protection of information at rest |
| NIST SP 800-53 Rev. 5 | AC-6 | Least privilege, applied to who and what can read each secret |
| NIST CSF 2.0 | PR.AA-01, PR.DS-01, DE.CM-03 | Credentials for services managed; data at rest protected; technology usage monitored |
| MITRE ATT&CK | T1552.001, T1552.004 | Credentials In Files and Private Keys, the techniques that Levels 1 and 2 leave open |
Self-assessment questions
Answer for production first. A control that exists on paper but covers a fraction of the estate scores Level 2.
- Inventory: could you list every secret that grants access to your most critical system, with an owner for each, within a day?
- Storage: what share of production secrets is in an approved store, and how many still sit in
.envfiles, CI variables or personal vaults? - Prevention: is push protection on for every repository, and who can bypass it? In the CISA Private-CISA GitHub leak, a contractor had turned it off.
- Delivery: do your pipelines still hold static cloud keys, or do they use OIDC federation tied to repository and environment?
- Lifetime: how many static secrets are older than 90 days, and do any have no expiry at all?
- Signing keys: where do your token signing and code signing keys live? At Coupang, signing keys were kept on developer computers and not rotated after a developer left (Coupang breach).
- Response: when a secret leaks, do you revoke first? Deleting the file does not invalidate the key.
- Audit: would you notice a secret being read by a workload that has never read it before?
Moving up: roadmap
From Ad hoc to Developing
- Scan all repositories and their full history, container registries and CI logs; revoke and rotate live findings first. The 230 Million AWS Cloud Environments campaign shows what exposed
.envfiles yield: 1,185 AWS access keys among more than 90,000 variables. - Stand up one approved store per platform and move the highest-risk production secrets into it.
- Turn on push protection for new repositories. See the Git Secret Scanning Guide.
From Developing to Defined
- Publish a secrets standard: approved stores, owner and purpose for every secret, maximum lifetime per type, approved retrieval methods.
- Enable push protection on every repository, restrict bypass to a delegated group and review "I'll fix it later" bypasses weekly.
- Remove long-lived cloud keys from personal password vaults; the LastPass breach began with keys held in one engineer's vault.
- Adopt the Leaked Credential Response Playbook and run one exercise.
From Defined to Managed
- Move CI/CD to OIDC federation so pipelines receive a token valid for a single job instead of stored keys. The Codecov breach showed how much a tampered CI step can read from environment variables. See the Workload Identity Federation Guide.
- Automate rotation for the static secrets that remain. Pilot on one non-critical database, keep the previous credential valid until consumers have switched, and keep a manual rollback path. Use the Secrets Rotation Runbook Template.
- Forward store audit logs to your SIEM and alert on first-time readers and bulk reads.
From Managed to Optimised
- Replace static database and cloud credentials with dynamic ones on short leases; HashiCorp Vault's database engine, for example, defaults dynamic roles to a one-hour TTL and 24-hour maximum.
- Rotate root and bootstrap credentials so only the secrets platform knows them, and move signing keys to HSM-backed or managed key services in line with NIST SP 800-57.
- Wire scanner findings to automatic revocation for supported secret types.
Metrics that show movement: share of production secrets in an approved store; number of static secrets older than 90 days; repositories with push protection on; pipelines still holding static cloud keys; median time from leak report to revocation; bypasses per month.
Practitioner checklist
- Score all seven capability areas and pick the weakest high-risk area as the first target.
- Scan full Git history, images and CI logs, and revoke live findings before cleaning them up.
- Enforce push protection on every repository with a small delegated bypass group.
- Give every production secret an owner, a purpose and a maximum lifetime.
- Take long-lived cloud keys out of personal password vaults and laptops.
- Move the top ten pipelines to OIDC federation with tight subject conditions.
- Automate and test rotation for remaining static secrets, with a rollback path.
- Report the six metrics monthly and re-score the model every six months.
Standards and references
- OWASP: Secrets Management Cheat Sheet
- NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- OWASP: Non-Human Identities Top 10 2025
- GitHub Docs: About push protection
- GitHub Docs: OpenID Connect
- HashiCorp: Vault database secrets engine
Related NHI Mgmt Group resources: Secrets Management Guide · Secrets Management Buyer's Guide · Top 10 Secrets Management Mistakes · NHI Governance Maturity Model · Top 10 NHI Risks