When a secret leaks, the first three questions are always the same: where else does this value live, who owns it, and what breaks if we rotate it now, and most organisations cannot answer any of them quickly. This template gives [Organisation] a register with one record per secret: API keys, database passwords, client secrets, tokens, signing and encryption keys, and the credentials held in pipelines and SaaS integrations. Each record captures where the value is stored and copied, the accountable owner, every consumer that reads it, and how and when it is rotated. It is written for platform, security and identity teams who run secrets managers or are planning a migration into one, and for auditors who need evidence that secrets are known and controlled. Service accounts themselves belong in the Service Account Inventory Template and certificates in the Certificate Inventory Register Template; this register links to both.
How to use this template
- One row per logical secret, not per copy: a database password stored in a secrets manager, a CI/CD variable and a Kubernetes Secret is one record with three location entries. Duplicates hide the blast radius.
- Never record the secret value: the register holds metadata only. It is still sensitive, because it maps where credentials live and what they unlock, so restrict access to [Secrets platform team], [Security team] and auditors.
- Populate from tools first: pull identifiers, dates and rotation state from secrets manager APIs and scanners. People supply owner, purpose and consumer fields, and confirm them at review.
- Required and Recommended: Required fields answer the three leak-response questions. Recommended fields support migration, risk scoring and audit.
- Use fixed values: drop-downs for type, storage location, environment, rotation method and status, so you can count and filter (section 9).
- Replace bracketed text: [Organisation], team names and the bracketed thresholds take your own values. Thresholds shown are NHI Mgmt Group suggestions.
1. Purpose
1.1 This register records every secret that [Organisation] systems use to authenticate, sign or encrypt, so that each secret has an accountable owner, known storage locations, a complete list of consumers and a defined rotation and expiry approach.
1.2 It is the authoritative source for leak response, rotation planning, offboarding and migration into a central secrets manager. It evidences NIST SP 800-53 Rev. 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management and CM-8 System Component Inventory, and NIST CSF 2.0 PR.AA-01 and ID.AM-07. The Secrets Management Policy Template makes keeping it current mandatory.
1.3 The fields follow the minimum metadata the OWASP Secrets Management Cheat Sheet says a secrets management solution should hold: when a secret was created, consumed, rotated and deleted, by whom and by what, who to contact, its intended consumers and purpose, its type, and when it must be rotated if rotation is manual.
2. Scope and secret types
| Secret type | Examples | Primary discovery source | Register notes |
|---|---|---|---|
| API keys and tokens | SaaS API keys, personal access tokens used by automation, webhook signing secrets | Secrets manager, Git and CI scanners, SaaS admin consoles | Record the issuing platform and the account it acts as |
| Database and service passwords | Application database users, message broker credentials, LDAP bind passwords | Secrets manager, configuration management, database user lists | Link to the service account record |
| OAuth client secrets | App registration secrets, integration client credentials | Identity provider app registrations | Record expiry from the identity provider; prefer federation where supported |
| Cloud access keys | Long-lived cloud user access keys, service account key files | Cloud IAM credential reports, scanners | Treat as high risk by default (OWASP NHI7:2025 Long-Lived Secrets) |
| Cryptographic keys | HMAC keys, symmetric data keys, SSH private keys, signing keys | Key management service, HSM inventory, host scans | Record algorithm and where key material is held |
| Pipeline and platform secrets | CI/CD variables, Kubernetes Secrets, serverless environment variables | CI/CD platform APIs, cluster inventory, cloud function configuration | Usually copies of a secret held elsewhere: add as locations, not new rows |
| Dynamic credentials | Short-lived database or cloud credentials issued per lease | Secrets engine configuration | Register the issuing role or policy with its lease time-to-live, not each credential |
2.1 Out of scope: human user passwords (managed by the identity provider and the password manager), and X.509 certificates (certificate register). The OWASP cheat sheet notes that user credentials are excluded from regular rotation and rotated on suspicion of compromise, so mixing them into this register distorts rotation metrics.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Register owner [Secrets platform lead] | Runs discovery and reconciliation, maintains fixed values, reports metrics |
| Secret owner | Accountable for one secret: purpose, consumers, rotation and revocation; must be a named person, with a team as backup |
| Consumer owner | Confirms that their application or job reads the secret and from which location |
| Issuing system administrator | Maintains the system that issues the credential (database, SaaS tenant, identity provider) and confirms revocation works |
| Security operations | Uses the register during leak response; feeds scanner findings back as new records |
4. Identification fields
| Field | Required | Description and allowed values |
|---|---|---|
| Secret ID | Required | Stable register ID, for example SEC-000123. Never reuse. |
| Name | Required | Human-readable name following [naming convention], for example prod/payments/db-app-user |
| Secret type | Required | Fixed value from section 2 |
| Purpose | Required | One sentence: what the secret unlocks and why it exists |
| Issuing system | Required | The system that accepts the secret: database instance, SaaS tenant, cloud account, API |
| Identity it acts as | Required | The service account, app registration or user the secret authenticates as; link to its inventory record |
| Privilege tier | Required | [Tier 0 to Tier 3]; Tier 0 for secrets that grant administrative or tenant-wide access |
| Environment | Required | Production, Staging, Development, Shared. A secret used in more than one environment is itself a finding (OWASP NHI8:2025 Environment Isolation) |
| Data classification reached | Recommended | Highest classification of data the secret gives access to |
| Algorithm or format | Recommended | For keys: AES-256, HMAC-SHA256, RSA-3072, Ed25519; for others: the format, for example JWT or opaque token |
5. Location fields
5.1 Record every place the value is stored, including copies. One sub-row per location.
| Field | Required | Description and allowed values |
|---|---|---|
| Location type | Required | Secrets manager, Key management service or HSM, CI/CD variable, Kubernetes Secret, Environment variable or configuration file, Password manager vault, SaaS integration setting, Other |
| Location reference | Required | Path, ARN, resource ID or URL of the stored item, for example the secret ARN or the Vault mount and path |
| Authoritative copy | Required | Yes for the single source that rotation writes to; No for synchronised or manual copies |
| Sync method | Required for copies | Automated sync (name the operator or integration), Injected at runtime, Manual copy. Manual copies are a finding |
| Region or replica | Recommended | Regions or clusters where the item is replicated |
| Encryption key | Recommended | The key that protects the stored value, for example a customer-managed key ID |
| Access policy reference | Recommended | The policy, role or ACL that grants read access at this location |
5.2 Locations found by scanners in source code, chat, tickets, logs or images are not storage locations: they are leaks. Record them as findings against the secret, trigger rotation, and link the leak ticket. See the Git Secret Scanning Guide.
6. Owner fields
| Field | Required | Description |
|---|---|---|
| Secret owner | Required | Named person accountable for the secret |
| Owning team | Required | Team that takes over if the owner leaves; the register must never show a leaver as sole owner |
| Escalation contact | Required | Who to contact out of hours during a leak |
| Created by | Recommended | Person and process that created the secret |
| Last attested | Required | Date the owner last confirmed purpose, consumers and locations |
6.1 When an owner leaves, the owning team lead must accept or reassign every secret in the leaver workflow. Unowned secrets are a direct route to OWASP NHI1:2025 Improper Offboarding. See How to assign owners to orphaned service accounts.
7. Consumer fields
7.1 Consumers are the workloads, jobs and people that read the secret. This is the field most often missing and the one that decides whether a rotation causes an outage.
| Field | Required | Description |
|---|---|---|
| Consumer name | Required | Application, service, pipeline, function or integration that reads the secret |
| Consumer identity | Required | The workload identity or role the consumer uses to read the secret from its location |
| Read location | Required | Which location from section 5 it reads |
| Retrieval pattern | Required | Fetched at each use, Cached with refresh [interval], Read at start-up only. Start-up-only consumers need a restart after rotation |
| Consumer owner | Required | Team to notify before rotation |
| Last observed access | Recommended | From secrets manager access logs or API metadata |
7.2 A secret with more than one consumer application is shared. Shared secrets make it hard to trace the source of a leak and force coordinated rotation; record them as findings and plan to split them (OWASP NHI9:2025 NHI Reuse).
8. Rotation and expiry fields
| Field | Required | Description and allowed values |
|---|---|---|
| Rotation method | Required | Automated (native), Automated (custom function), Manual, Dynamic (per lease), Not rotatable (record exception ID) |
| Rotation interval | Required | Target interval in days from policy, for example [90] for Tier 2, [30] for Tier 0 |
| Last rotated | Required | Date of last successful rotation, taken from the secrets manager where available |
| Next rotation due | Required | Calculated; flag any date in the past |
| Expiry date | Required where the issuer supports it | Hard expiry set at the issuing system or secrets manager |
| Rotation runbook | Required for Manual | Link to the runbook; see the Secrets Rotation Runbook Template |
| Revocation tested | Recommended | Date the team last confirmed that the old value stops working after rotation |
| Status | Required | Active, Pending rotation, Rotating, Revoked, Retired, Exception |
8.1 Rotation and expiry are different controls. The OWASP cheat sheet recommends creating secrets to expire after a defined time where possible, so that an expiry date set at the secrets manager forces rotation even if the schedule fails. Record both.
9. Mapping native secrets manager metadata
9.1 Fill technical fields from the platform's own metadata rather than by hand. Platforms are listed alphabetically.
| Platform | Native fields that fill the register | Where owner and consumer fields go |
|---|---|---|
| AWS Secrets Manager | DescribeSecret returns CreatedDate, LastChangedDate, LastAccessedDate, LastRotatedDate, NextRotationDate, RotationEnabled, RotationRules, KmsKeyId, PrimaryRegion and ReplicationStatus. NextRotationDate can be in the past when a rotation failed, which is a useful alert | Tags on the secret, for example owner, owning-team and register-id |
| Azure Key Vault | Each secret version carries created and updated, plus settable exp (expiry), nbf (not before), enabled and contentType | Tags, up to 15 per secret with names and values up to 512 characters |
| Google Cloud Secret Manager | Rotation schedule fields next_rotation_time and rotation_period. Secret Manager sends a SECRET_ROTATE message to the secret's Pub/Sub topics on schedule; your subscriber creates the new version | Labels and annotations on the secret |
| HashiCorp Vault (KV version 2) | Metadata returns created_time, updated_time, current_version, oldest_version and a versions map with created_time, deletion_time and destroyed per version | custom_metadata, a string-to-string map on the secret's metadata |
9.2 Use the same three tag keys on every platform: owner, owning-team and register-id. A consistent key set lets one reconciliation job join platform data to the register. Platform detail is in the AWS Secrets Manager, Azure Key Vault Security Guide, Google Secret Manager Security Guide and HashiCorp Vault Guide pages.
10. Review and reconciliation
- Weekly, automated: pull metadata from every secrets manager and CI/CD platform; flag new items with no register ID, records whose next rotation date has passed, and records whose secret no longer exists.
- Weekly, automated: match scanner findings (Git, CI logs, container images, chat) against the register; every match is a leak ticket and a rotation.
- Quarterly, owner attestation: each owner confirms purpose, consumers and locations for their secrets and updates Last attested. Tier 0 secrets [monthly].
- On events: update the record on owner departure, application decommission, migration between stores, and any leak.
- Retire properly: when a consumer is decommissioned, revoke the secret at the issuing system before deleting it from storage, then set status Retired.
10.1 Reconciliation between platform data and the register is the same discipline as for other non-human identities; see NHI Inventory Reconciliation.
Implementation guidance
- Start with Tier 0 and production: build records for administrative and production secrets first. A complete register of the top 200 secrets is more useful than a partial register of 20,000.
- Seed from the secrets manager, then hunt copies: export platform metadata to create the first rows, then use scanners and CI/CD exports to find the copies and the secrets that never entered a manager. See the Secret Sprawl Measurement Guide.
- Expect these first-run findings: shared secrets across applications, production secrets also used in development, manual copies in CI/CD variables, leavers as sole owners, and rotation schedules that report enabled but have not succeeded.
- Use the register to retire secrets: records where the issuer supports federation or workload identity are candidates for removal rather than rotation.
- Where identity fits: every secret authenticates as an identity. Linking the Identity it acts as field to the service account inventory lets one offboarding event revoke both the account and its secrets.
- Metrics to report monthly: percentage of secrets with a named owner and owning team; percentage with at least one consumer recorded; percentage rotated within interval; secrets past expiry or next rotation date; shared secrets; manual copies; unregistered secrets found by reconciliation and median time to register. See How to measure secret age and rotation coverage.
| Framework | Reference | How the register supports it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, CM-8 System Component Inventory, AU-2 Event Logging | Lifecycle, ownership and rotation evidence for every authenticator and key |
| NIST CSF 2.0 | PR.AA-01, ID.AM-07, ID.AM-08 | Credentials for services managed by the organisation, data inventories with metadata, life cycle management |
| CIS Controls v8.1 | Safeguard 3.2 Establish and Maintain a Data Inventory | Secrets treated as sensitive data with owners and locations |
| ISO/IEC 27001:2022 Annex A | A.5.9 Inventory of information and other associated assets, A.5.17 Authentication information, A.8.24 Use of cryptography | Inventory with owners, management of authentication information and keys |
| OWASP Non-Human Identities Top 10 2025 | NHI1 Improper Offboarding, NHI2 Secret Leakage, NHI7 Long-Lived Secrets, NHI8 Environment Isolation, NHI9 NHI Reuse | Owner, location, rotation, environment and consumer fields each address one risk |
| MITRE ATT&CK | T1552.001 Credentials In Files, T1555.006 Cloud Secrets Management Stores | Locations and access policies show where an attacker would look |
Standards and references
- OWASP: Secrets Management Cheat Sheet
- OWASP: Non-Human Identities Top 10 2025
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- AWS: Secrets Manager DescribeSecret API reference
- Microsoft Learn: About Azure Key Vault secrets
- Google Cloud: Secret Manager rotation schedules
- HashiCorp: KV secrets engine version 2 API
Related NHI Mgmt Group resources: Secrets Management Guide · OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide · API Key Leak Response Playbook · SaaS Misconfiguration Data Exposure Playbook