A bearer secret is a credential that grants access to whoever presents it, without needing additional proof of identity. GitHub tokens, SSH keys, API keys, and many session artifacts behave this way, which is why exposure on a developer machine can quickly become broad enterprise access.
Expanded Definition
A bearer secret is a credential whose power lies entirely in possession: if an attacker can present it, they can usually act as the associated identity without an extra step of proof. In NHI security, that makes bearer secrets especially sensitive because they collapse authentication and authorization into one reusable artifact. GitHub tokens, API keys, SSH private keys, and many session tokens behave this way, although the exact enforcement model varies across vendors and protocols.
That distinction matters because not every secret is equally dangerous in practice. Some systems bind a token to a device, client certificate, or short-lived exchange, while others treat the secret as a stand-alone bearer capability. Guidance in the OWASP Non-Human Identity Top 10 treats this as a core exposure pattern: the risk is not only theft, but also overlong validity, weak scoping, and poor revocation. NHI Management Group also distinguishes bearer-style secrets from stronger dynamic credentials in the Ultimate Guide to NHIs: Static vs Dynamic Secrets, where the security gap is driven by persistence and portability rather than naming alone.
The most common misapplication is treating a bearer secret like a harmless configuration value, which occurs when teams copy it into code, tickets, or shared logs without recognising that possession alone grants access.
Examples and Use Cases
Implementing bearer secrets rigorously often introduces operational friction, because teams must balance fast machine-to-machine access against tighter controls on storage, rotation, and leakage detection.
- A CI/CD job uses an API key to publish artifacts. If the key appears in build logs or pipeline variables, any party that retrieves it can reuse the same access until it is revoked.
- A developer stores an SSH private key on a laptop. If the laptop is compromised, the key can be replayed from another host unless additional binding or short-lived issuance exists.
- A SaaS integration uses a long-lived GitHub token to read repositories. This is a classic bearer pattern because the token itself is the proof, not the device or user session behind it.
- A cloud workload receives a session artifact that expires quickly. This is still a bearer secret, but its reduced lifetime narrows the blast radius compared with static credentials.
- In supply-chain incidents such as the Reviewdog GitHub Action supply chain attack, exposed tokens can be harvested from automation contexts and reused immediately across connected systems.
For broader context on how bearer-style exposure becomes systemic, the Guide to the Secret Sprawl Challenge shows how secrets spread beyond vaults into code, config, and CI/CD tooling, while the OWASP guidance helps separate bearer risk from ordinary secret inventory concerns.
Why It Matters in NHI Security
Bearer secrets sit at the center of NHI risk because they are both highly reusable and frequently overexposed. NHI Management Group reports that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. That pattern is especially dangerous for bearer credentials, since one copied value can unlock multiple services, automation paths, or cloud resources before defenders notice. The problem is magnified when teams assume that “hidden” means “safe,” even though bearer secrets remain valid wherever they are accepted.
Governance should therefore focus on scope, lifetime, storage location, detection, and revocation speed. The NHI lifecycle also intersects with third-party and pipeline risk, as shown in cases like the CI/CD pipeline exploitation case study and the Shai Hulud npm malware campaign, where secret theft turns into downstream access abuse. Strong handling also supports zero trust, because possession-only credentials undermine confidence in who or what is actually acting. Organisations typically encounter the severity of bearer secrets only after a leak, at which point the credential has already become operationally unavoidable to address.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Bearer secrets are the exact artifact class behind secret sprawl and improper secret handling. |
| NIST CSF 2.0 | PR.AC-1 | Bearer secrets grant access by possession, so access control must account for stolen credentials. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes credentials can be compromised and should not be trusted by possession alone. |
Classify bearer secrets, reduce standing exposure, and enforce rotation plus revocation controls.
