A credential store is the system or datastore that holds secrets such as OAuth tokens, API keys, certificates, and access tokens. When it contains third-party production credentials, it becomes a high-value identity asset that needs ownership, segmentation, monitoring, and emergency invalidation paths.
Expanded Definition
A credential store is the system of record for machine-authenticating material such as API keys, OAuth tokens, certificates, session secrets, and refresh tokens. In NHI operations, it is not just a vault or database; it is an identity control point that determines who can retrieve secrets, how they are rotated, and whether access can be revoked fast enough to limit blast radius.
Definitions vary across vendors because some teams use the term to mean a secrets manager, while others mean any datastore containing active production credentials. For NHI Management Group, the meaningful distinction is operational: a credential store becomes security-critical when it contains third-party or cross-environment production credentials that enable downstream access. That is why guidance in the OWASP Non-Human Identity Top 10 and the NIST SP 800-63 Digital Identity Guidelines matters here: the store must preserve assurance, traceability, and revocation discipline, not merely confidentiality.
The most common misapplication is treating the credential store as a passive inventory system, which occurs when teams centralise secrets but fail to assign ownership, usage boundaries, and emergency invalidation procedures.
Examples and Use Cases
Implementing a credential store rigorously often introduces access choreography overhead, requiring organisations to weigh tighter control against the speed that developers and automation pipelines expect.
- A platform team stores cloud API keys for deployment agents in a central vault, but only signed workloads with approved RBAC can retrieve them for a limited time window.
- An AI Agent uses short-lived access tokens to call internal tools, while the credential store issues and revokes those tokens through JIT credential provisioning rather than static reuse.
- A CI/CD system pulls signing certificates from a protected store during release jobs, reducing secret exposure in build logs and limiting the usefulness of compromised runners. The pattern is explored in NHIMG’s CI/CD pipeline exploitation case study.
- A security team separates production secrets from development secrets to prevent secret sprawl, a failure mode described in NHIMG’s Guide to the Secret Sprawl Challenge.
- OAuth refresh tokens are stored with strict lifecycle controls so that compromise of one application does not automatically expose every dependent service account.
For operational design, the Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful because it frames when a static secret in a store should be replaced by an ephemeral credential pattern.
Why It Matters in NHI Security
Credential stores are high-value targets because they compress trust: one successful retrieval can unlock many downstream systems. If the store has weak segmentation, long-lived secrets, or broad operator access, an attacker who lands in one workload can pivot into cloud accounts, SaaS integrations, and production pipelines. The NHI risk is not only theft, but also stealthy reuse, where a valid credential looks legitimate until behaviour patterns reveal abuse.
NHI operations are still maturing. In the 2024 Non-Human Identity Security Report, 23.7% of organisations said they share secrets through insecure methods such as email or messaging applications. That is a direct signal that many credential stores are not the only problem; the surrounding handling process is often just as risky. This is also why vendor guidance around static versus dynamic secrets needs to be paired with governance, not used as a slogan.
Organisations typically encounter the real consequence only after a leaked key, exposed token, or compromised build agent forces emergency rotation, at which point the credential store becomes operationally unavoidable to fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses insecure secret storage and sprawl across non-human identities. |
| NIST SP 800-63 | Defines assurance and authenticator handling principles relevant to credential lifecycle. | |
| NIST CSF 2.0 | PR.AC-1 | Supports access control over stored credentials and least-privilege retrieval. |
Inventory stored secrets, restrict retrieval paths, and eliminate long-lived credentials where possible.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
