Any access path that depends on a secret such as a password, token, API key, or certificate rather than a federated identity assertion. It remains governable only when the organisation can discover where the credential is used, who owns it, and how it can be revoked.
Expanded Definition
Credential-based access describes any authorisation path that depends on a secret, such as a password, token, API key, or certificate, rather than a federated identity assertion. In NHI environments, the term covers both human-managed secrets and machine-issued credentials when they are stored, rotated, distributed, and revoked outside an identity fabric. That distinction matters because a credential can prove possession, but it does not by itself prove ownership, intended workload, or current business need.
In practice, credential-based access is broader than “a login.” It includes long-lived service account passwords, CI/CD tokens, embedded certificates, and API keys used by agents or automated jobs. Guidance varies across vendors on whether short-lived tokens count as credential-based access or a transitional control on the path to federation, so teams should define the boundary explicitly. The most common misapplication is treating a secret as governed access when the organisation cannot discover all places it is copied, stored, or reused.
For baseline identity terminology, NIST SP 800-63 Digital Identity Guidelines helps distinguish authenticators from identity proofing, while OWASP Non-Human Identity Top 10 frames the NHI risk surface around secret handling and workload access.
Examples and Use Cases
Implementing credential-based access rigorously often introduces rotation and inventory overhead, requiring organisations to weigh operational simplicity against the cost of secret lifecycle control.
- A production database is reached through a static username and password stored in an application config file. This is credential-based access because the application authenticates with a reusable secret, not a federated assertion.
- A GitHub Actions pipeline uses a cloud API key to deploy workloads. The access is functional, but it remains credential-based until the key is replaced with a narrowly scoped, short-lived mechanism.
- An AI agent calls internal tools with a bearer token stored in its runtime environment. The token becomes a credential to govern, rotate, and revoke, especially if the agent is autonomous.
- A certificate pinned into an edge device enables mutual TLS to a control plane. The certificate is a credential, and its lifecycle must be tracked like any other secret in the NHI estate.
- A third-party integration uses a shared API key across multiple services. This is a common example of credential sprawl documented in NHIMG research, including the Guide to the Secret Sprawl Challenge and breach analyses such as 52 NHI Breaches Analysis.
Security teams also use credential-based access to compare current state against more controlled patterns like federation, as discussed in Ultimate Guide to NHIs - Static vs Dynamic Secrets. The external pattern is similar to what NIST SP 800-63 Digital Identity Guidelines treats as authenticator-based access, but NHI operations add inventory and ownership requirements.
Why It Matters in NHI Security
Credential-based access becomes dangerous when secrets outlive the workload, move outside approved vaulting, or cannot be mapped to a specific owner. That is how access survives deprovisioning, how automation continues after a team has forgotten it exists, and how attackers turn one exposed secret into broad lateral movement. NHIMG research shows 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which makes discovery and revocation materially harder.
The risk is not theoretical. In the LLMjacking: How Attackers Hijack AI Using Compromised NHIs report, attackers attempted access to exposed AWS credentials within an average of 17 minutes. That kind of speed means a credential is not just an access mechanism, but a live attack surface the moment it is copied into the wrong place. Organisations often discover the operational impact only after a breach, at which point credential-based access becomes unavoidable to trace, rotate, and replace.
For mature governance, teams should map every credential to a workload owner, classify whether it is static or ephemeral, and align it with OWASP Non-Human Identity Top 10 controls and the broader lessons in Ultimate Guide to NHIs.
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 | Covers secret exposure, sprawl, and unmanaged workload credentials. |
| NIST SP 800-63 | Separates authenticators from identity assurance for credential-based access. | |
| NIST CSF 2.0 | PR.AA-05 | Supports identity and access governance for service and machine identities. |
Treat each credential as an authenticator and define assurance, renewal, and revocation rules.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org