A guide to API key management

Non-human identities (NHIs) outnumber human users by 144 to 1 in enterprise environments, according to The NHI & Secrets Risk Report H1 2025, up 56% from 92:1 a year earlier. API key management should account for this scale because service accounts, automated pipelines, and third-party integrations all carry credentials. A large share of those credentials are API keys, static strings that often don't expire by default, slip into source code, and escape access reviews.

Human accounts get joiner-mover-leaver workflows and periodic certification. Developers usually create API keys in developer consoles and paste them into config files. The keys then remain in place until something breaks or improper offboarding exposes the gap.

Effective credential governance covers machine credentials across generation, storage, rotation, monitoring, and revocation. Applying those controls to every non-human identity closes the long-lived key risk and strengthens security posture, operational visibility, and cyber resilience.

What is API key management?

API key management is the discipline that governs a machine credential from generation through revocation, covering storage, distribution, rotation, and monitoring. An API key itself is a static, opaque string that an application transmits with an API request, typically in a Hypertext Transfer Protocol (HTTP) header, to identify the calling application, service, script, or pipeline. It functions as a bearer-style credential because possession alone is sufficient to use it.

Request for Comments (RFC) 6750 defines the same property for OAuth 2.0 bearer tokens: anyone in possession of the token can use it without proving possession of cryptographic key material. That bearer-style property is exactly why a standard API key doesn't authenticate a principal. It only proves possession of a string value, not identity.

Why API keys are a growing attack surface

Developers committed 28,649,024 new hardcoded secrets to public GitHub repositories in 2025, according to GitGuardian's The State of Secrets Sprawl 2026. That total represents a 34% year-over-year increase and the largest single-year jump the report has recorded. Several structural properties drive that sprawl. Many API keys don't expire by default, so long-lived key exposure can persist for years, and the same plain-string value that works in an HTTP header works equally well in a config file, a continuous integration and continuous delivery (CI/CD) variable, or a chat message.

Overprivileged NHIs also receive broader permissions than their tasks require, and those permissions often outlive the task itself. Every new cloud service, pipeline, and third-party integration increases the inventory security teams must govern. According to the Netwrix 2026 Data and Identity Security Report, 75% of incident-based data exposures begin with a compromised identity or misconfigured permissions.

A historical example shows the operational impact of weak lifecycle controls. In November 2023, a threat actor accessed Cloudflare's self-hosted Atlassian environment through exposed valid credentials.

The actor used one access token and three service-account credentials exposed in the October 2023 Okta compromise, which Cloudflare never rotated afterward. Cloudflare described them as "mistakenly believed to be unused." Remediation required broad production credential rotation and machine reimaging across Cloudflare's global network.

That attacker authenticated with valid credentials throughout the incident, and the Netwrix 2025 Cybersecurity Trends Report found that 27% of organizations estimated attack damage of $50,001 or more, underscoring the financial case for lifecycle controls that reduce avoidable response and remediation work. Continuous inventory, ownership, and rotation reduce that recovery burden and improve cyber resilience.

The API key lifecycle

Open Worldwide Application Security Project (OWASP) secrets guidance organizes effective key management around five stages: generation, storage and distribution, rotation, monitoring and auditing, and revocation.

Generation

Every key should come from a cryptographically secure random source and carry scope restrictions from creation. For a key that functions as a National Institute of Standards and Technology (NIST) SP 800-63B-4 look-up secret or a directly analogous credential, use a minimum security strength of 112 bits as an entropy benchmark; NIST requires that look-up secrets come from an approved random bit generator with that minimum strength, applied specifically to look-up secrets and directly analogous credentials.

Apply key restrictions at issuance, specifying which APIs the key may call and which applications may present it. Assign each key the minimum privileges its task requires, and create ownership records at the same moment. On what keys should authenticate, OWASP API guidance is clear that API keys should authenticate API clients, not end users.

Two related credential types differ from API keys. The OAuth 2.0 standard, an authorization framework, defines access tokens that authorization flows issue. Client authentication requirements, scopes, and lifetimes depend on the grant type and provider configuration; in Microsoft's client credentials flow, typical token lifetimes are often around an hour.

A certificate-based credential using mutual Transport Layer Security (mTLS) and X.509 uses proof-of-possession instead. The client proves control of a private key that remains on the client, so per RFC 8705, only the party in possession of the private key corresponding to the certificate can use the associated token.

Storage and distribution

Keep keys out of source code and retrieve them at runtime from a dedicated secrets store. Hardcoded credentials in source code are dangerous; the fix is a secret manager that CI/CD pipelines and applications can use to retrieve secrets securely.

Environment variables that remain outside the application's source tree are the floor; a centralized secrets manager with access controls and audit logging is the standard. Distribute keys only over Hypertext Transfer Protocol Secure (HTTPS), and never place them in URLs, since query strings end up in web server logs.

Rotation

Manual rotation processes introduce errors and leave stale credentials active, which is why automation matters. For long-lived Google Cloud service-account keys, cloud provider guidance recommends rotation at least every 90 days. The Center for Internet Security (CIS) Amazon Web Services (AWS) benchmark similarly calls for rotating AWS Identity and Access Management (IAM) access keys every 90 days or less.

For zero-downtime rotation, use dual-credential rotation. Maintain two valid credential sets, cut applications over to the new one, then retire the old. Trigger event-driven rotation after suspected exposure, an ownership change, or a project ending. The cost of skipping this stage compounds. GitGuardian found that 64% of secrets it had detected four years earlier remained active and exploitable when retested.

Monitoring and auditing

Create key-use logs for every credential and review those logs for keys that have gone quiet. CIS Controls v8 requires at least 90 days of audit log retention, and CIS cloud benchmarks call for teams to disable credentials after 45 days of inactivity. Dormancy is a useful signal.

Audit the creation and use of service principal credentials, and watch for unusual application usage, such as dormant applications suddenly active again. Mask secret values in log output; secrets should never appear in plaintext logs.

Revocation

Treat any exposed key as compromised the moment you learn of it, and build the revocation path before you need it. Follow a safe rotation sequence. Generate a replacement key for the same service account, move workloads onto it, verify functionality after the migration, then delete the old key.

Deleting the secret from code alone leaves the credential active; follow repository cleanup guidance by revoking first, then scrubbing repositories, configuration, and logs. Finish with a blast-radius review of the key's usage history. What did it access while exposed, and did the actor use it to create new keys, roles, or policies?

What to look for in an API key management approach

A working governance program combines vault deployment with operational controls, so evaluate approaches against operational criteria.

• Centralized inventory and discovery: The approach should find keys across cloud providers, CI/CD pipelines, repositories, configuration files, and Software as a Service (SaaS) platforms, and record who owns each one. A practical registry for non-human credentials should capture the identity, owning team, business purpose, systems accessed, privilege scope, and expiration or review date.
• Least-privilege scoping and just-in-time issuance: Look for per-key, per-workload scoping and the ability to issue short-lived credentials on demand and revoke them automatically after use.
• Automated rotation without downtime: Both scheduled and event-driven rotation, with dual-credential support so applications remain available during cutover.
• Audit-ready logging: Every retrieval, rotation, revocation, and administrative action should create audit-ready records with an attributable identity and timestamp for export to your security information and event management (SIEM) system. That record provides audit evidence and the forensic trail incident responders need.
• Integration with identity governance: Identity Governance and Administration (IGA), Privileged Access Management (PAM), and Cloud Infrastructure Entitlement Management (CIEM) should work together to manage identities and entitlements consistently across all environments. A vault that shares inventory and ownership data with your IGA program can include keys in the certification process. The IGA buyer's guide outlines further governance capabilities for evaluating identity management tools.

Where API key management fits into non-human identity governance

Many governance programs break down at ownership. Silverfort's Insecurity in the Shadows 2025 found that 40% of non-human identities have an unknown owner, and only 5.7% of security leaders report complete visibility across their NHIs.

A Gartner survey of 335 IAM leaders, published in Gartner Identifies the Top Cybersecurity Trends for 2025, found that IAM teams are responsible for only 44% of an organization's machine identities; the rest sit with development, platform, and business teams. Clear identity ownership creates accountability for reviews, rotation, and retirement.

Compliance frameworks already expect this discipline. Payment Card Industry Data Security Standard (PCI DSS) least privilege requirements cover application and system accounts (Req. 7.2.5). Organizations must periodically review access for those accounts at a frequency defined in their targeted risk analysis. PCI DSS Req. 7.2.5.1 took effect March 31, 2025. PCI DSS also establishes hard-coded password controls for scripts, configuration files, and source code (Req. 8.6.2).

The Health Insurance Portability and Accountability Act (HIPAA) Security Rule scopes access controls to persons or software programs with access rights, so machine credentials touching protected health information (PHI) fall squarely within it.

For the Sarbanes-Oxley Act (SOX), complete access populations support reliable control testing. SOX access governance should include service accounts and integration keys in access listings. Across frameworks, consistent audit evidence includes discovery reports, ownership records, rotation logs, decommissioning records, and dated reviews with named sign-offs.

The analyst consensus has moved to the same place. Vaulting secrets supports governance, but governance extends beyond vaulting. Organizations increasingly expect IGA platforms to govern both human and NHIs consistently through flexible lifecycle policies, continuous reconciliation, and clear ownership models.

In practice, every API key needs the same lifecycle treatment as a human account. That means creating it with an owner and documented purpose, certifying it on a cadence, and offboarding it when its task ends. Offboarding remains the widest gap; the Open Worldwide Application Security Project (OWASP)'s NHI Top 10 includes improper offboarding among common failure modes and reports that 51% of organizations have no formal process to offboard or revoke long-lived API keys. Since teams continuously create and abandon keys, the governance model requires continuous reconciliation to maintain visibility and posture as the population changes.

Best practices for managing large API key inventories

A scalable program turns lifecycle policy into repeatable technical and governance controls:

• Least-privilege policy templates: Define approved API, resource, and operation scopes for common workloads, apply default-deny enforcement, and detect drift from those templates.
• Migration from static keys: Where platforms support workload identity federation, managed identities, or temporary session credentials, use them instead. National Cyber Security Centre (NCSC) guidance advises avoiding long-term access keys that may grant indefinite access if compromised.
• Rotation orchestration: Connect credential issuance, application cutover, validation, and retirement so teams can automate credential rotation, as NCSC guidance recommends.
• Vault-to-discovery reconciliation: GitGuardian found that 5.1% of repositories using secrets managers still leaked secrets in 2024; compare stored credentials with repository, pipeline, cloud, and SaaS inventories to find gaps.
• Incident-response kill switch: Maintain the ability to revoke any key within minutes, with a pre-tested replacement path. The SANS Internet Storm Center (SANS ISC) observed threat actors moving from validating stolen secrets to active discovery operations inside compromised cloud environments within 24 hours.
• Named-owner reviews: CIS Safeguard 5.5 requires a service-account inventory with department owner, review date, and purpose, reviewed at least quarterly; fold API keys into the same review.

How Netwrix helps you govern API keys and machine credentials

API keys are one credential type inside a larger non-human identity governance challenge, and most organizations lack complete visibility into that population. Netwrix supports adjacent PAM and IGA controls as part of its identity-centric security approach for mid-market organizations running Microsoft-heavy hybrid environments.

For privileged access workflows, Netwrix Privilege Secure applies a zero-standing-privilege model that creates task-scoped ephemeral accounts for a single session and destroys them when it ends. Eastern Carver County Schools eliminated standing privileged access across network switches, VMware, and security cameras protecting 9,300 students' data, replacing it with just-in-time access and completing the rollout in days instead of months. Netwrix Identity Manager supports access certification and automated offboarding for the identities those credentials belong to.

14,000+ customers, including approximately 25% of the Fortune 500, rely on Netwrix to manage identity and data security together.

Request a demo to see how Netwrix Privilege Secure eliminates standing privileged access with task-scoped credentials that expire automatically.