API Key Management Standard Template: Rules for Issuing, Scoping, Storing and Rotating Keys

A secrets policy says API keys must be protected, but engineers still ask the practical questions: who may create a key, how narrow it must be, where it may live, how long it may last and what a key we issue to customers should look like. This template is the technical standard that sits beneath a secrets management policy and answers those questions for API keys specifically. It covers keys your organisation consumes from third parties and cloud providers, and keys your own products issue to customers and partners. It is for security architects, platform teams and product engineering leads who need rules they can enforce and audit. The lifecycle reasoning behind each rule is in the API Key Management Guide; this page gives you the editable standard.

How to use this template

• Replace text in square brackets, such as [Organisation], [Platform Security Lead], [approved vault] and [90 days], with your own terms. Bracketed values are NHI Mgmt Group suggested defaults, not external requirements.
• "Must" is mandatory. "Should" is recommended practice where a documented exception may be justified.
• Reference this standard from section 4 of your secrets policy. If you do not have one yet, start with the Secrets Management Policy Template.
• Section 4.7 applies only if your products issue API keys. Delete it if they do not.
• Where a provider's documentation sets a limit (key expiry options, restriction types, scopes), follow the provider and confirm the current value in its documentation.

1. Purpose

This standard sets the minimum technical requirements for creating, scoping, storing, using, rotating, monitoring and revoking API keys at [Organisation], so that any single leaked key has limited reach, a known owner and a short useful life.

2. Scope

• In scope: API keys, application keys, access tokens issued as static bearer strings, webhook signing secrets and similar static credentials used by applications, pipelines, scripts and AI agents to call internal or external APIs.
• Also in scope: API keys that [Organisation]'s products issue to customers, partners and integrations (section 4.7).
• Out of scope: human passwords, OAuth client secrets and certificates (covered by [Secrets Management Policy]), and short-lived tokens issued through OAuth or workload identity federation, which this standard prefers wherever available.

3. Roles and responsibilities

4. Standard

4.1 When an API key may be used

• Teams must use a federated or short-lived credential (workload identity, OAuth client credentials with short-lived tokens, cloud roles) where the provider supports one. An API key is permitted only where it does not, or where the [Platform Security Lead] approves an exception.
• API keys must not be the only control protecting sensitive, critical or high-value resources. OWASP advises against relying exclusively on API keys for such resources.
• Personal keys tied to an individual's account must not be used by production workloads.

4.2 Issuance

• Every key must be created through [request process or ticket type] and recorded in the [key register] before first use.
• The register must hold at least: key identifier or prefix (never the value), provider and account, owning team, purpose, consuming workload, environment, scopes and restrictions, creation date, expiry or next rotation date, and the vault path. These fields draw on the metadata OWASP recommends recording for each secret, such as purpose, consumers and rotation dates; the full field list is our recommendation.
• One key per consuming workload and environment. Keys must not be shared between applications or between production and non-production.
• Where the provider allows a key to be generated by an automated pipeline directly into the vault, that method should be used so no person sees the value.

4.3 Scoping and restriction

• Each key must have the narrowest scope the provider offers: specific APIs or endpoints, read-only where writes are not needed, and specific resources or projects.
• Where the provider supports usage restrictions, keys must apply them: source IP ranges, referrers, application identifiers or allowed API lists. Google Cloud, for example, describes restrictions as a way of limiting the impact of a compromised key.
• Keys should carry provider-side quotas or spend limits set to [expected peak plus margin], so abuse is capped and visible.
• Administrative or account-wide keys must be held by no more than [two] named owners, stored in the [privileged vault] and used only for break-glass or provisioning tasks.

4.4 Storage and use

• Keys must be stored only in the [approved vault] or the platform's native secret store for the consuming service, and injected at runtime.
• Keys must not appear in source code, container images, client-side code, mobile apps, URLs, logs, tickets, chat or documents.
• Keys must be sent in a request header, not a URL query parameter, wherever the provider supports it, because URLs are recorded in logs and proxies.
• Calls that need a key must be made server side. A browser or mobile client must call [Organisation]'s back end, which adds the key.
• Repositories must run secret scanning with push protection enabled. See the Push Protection Guide.

4.5 Rotation and expiry

• Keys must be created with an expiry date where the provider supports one. "No expiry" requires an exception.
• Rotation must follow the overlap pattern: create the new key, deploy it, confirm traffic has moved, then delete the old key. See the Secrets Rotation Runbook Template.
• Keys unused for [60 days] must be disabled, and deleted after a further [30 days] unless the owner justifies them.

4.6 Monitoring, leaks and revocation

• Provider usage logs for each key should be collected into [SIEM] and alert on calls from outside expected sources, new APIs, volume above [threshold] and use after the planned rotation date.
• A key found in any unapproved location must be treated as compromised, revoked or rotated within [4 hours] for production and [1 working day] otherwise, and reviewed for misuse. Deleting the file or commit is not sufficient. Follow the Leaked Credential Response Playbook.
• Keys must be revoked when the consuming workload is retired, when the provider relationship ends, or when the key fails the quarterly register review.

4.7 Keys [Organisation] issues to customers and partners

• Format: keys must use a unique, documented prefix, a high-entropy random body and a checksum, the format GitHub recommends for its secret scanning partner programme, so scanners can find them with few false positives.
• Storage: [Organisation] must store only a salted hash or keyed hash of each key and show the full value to the customer once, at creation.
• Customer controls: customers must be able to create multiple keys, set scopes, set an expiry, see last-used dates and revoke keys themselves.
• Abuse controls: every request to protected endpoints must require a key, rate limits must return HTTP 429, and keys used in breach of the terms must be revoked, in line with OWASP REST guidance.
• Leak reporting: [Organisation] should register its key format with public secret scanning programmes, treat any reported key as public and compromised, and notify the affected customer within [24 hours].

5. Exceptions

Exceptions must be requested through [exception process], state the rule, the reason, compensating controls (such as IP restriction or spend limit) and an end date of no more than [6 months]. The [Platform Security Lead] approves exceptions and the register records them.

6. Compliance and monitoring

• The [key register] is reconciled quarterly against provider consoles and the vault. Keys found in a provider but not in the register are investigated as unmanaged.
• Metrics reported to [Security Steering Group]: number of keys, percentage with an owner, percentage past rotation date, keys without restrictions, time from leak detection to revocation.
• Breaches of this standard are handled under [disciplinary or engineering escalation process].

7. Review and approval

Implementation guidance

• Start with the register: export key lists from your highest-risk providers (cloud, payments, AI model providers, source control) and assign owners before enforcing rotation dates.
• Find unmanaged keys: run secret scanning across repositories, CI logs and images to discover keys the register does not know about. See the Generic API Key Detection Guide.
• Enforce in order of blast radius: admin keys first, then production write keys, then everything else. Apply restrictions and spend limits before rotation, because they reduce risk immediately.
• Automate where providers allow it: OWASP recommends automating rotation and favouring dynamic secrets; manual rotation of hundreds of keys tends to stall.
• Decide token type first: if a provider offers OAuth or federation, migrating is usually better than tightening a key. See the API Keys vs OAuth Tokens Guide.

Framework mapping

• NIST SP 800-53 Rev. 5: IA-5 Authenticator Management, AC-6 Least Privilege, AC-2 Account Management.
• NIST CSF 2.0: PR.AA-01 (identities and credentials for services are managed) and PR.AA-05 (access permissions follow least privilege).

Standards and references

• OWASP: Secrets Management Cheat Sheet
• OWASP: REST Security Cheat Sheet
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• Google Cloud: Best practices for managing API keys
• GitHub Docs: Secret scanning partner program

Related NHI Mgmt Group resources: API Key Management Guide · Secrets Management Policy Template · Secrets Rotation Runbook Template · Leaked Credential Response Playbook