A per-machine credential inventory is a record of the credentials, tokens, keys, and related artefacts present on an individual device. In NHI governance, it gives security teams a testable boundary for exposure, ownership, and revocation when credentials live on endpoints rather than only in central vaults.
Expanded Definition
Per-machine credential inventory is the discipline of identifying which credentials, tokens, keys, and related artefacts exist on a specific device, then tying each item to an owner, purpose, and revocation path. It is broader than a simple secrets list because the device boundary matters: a laptop, build runner, server, or endpoint can hold long-lived material that never appears in a central vault view.
That boundary is what makes the term useful in governance. A central secret may be well managed, yet the real exposure can sit in local files, environment variables, cached sessions, browser stores, or agent configuration on a single machine. In practice, teams use the inventory to answer two questions quickly: what does this device possess, and what should be removed, rotated, or reassigned first?
For deeper control context, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping inventory discipline to control expectations around access, configuration, and monitoring. A common boundary mistake is treating endpoint-held credentials as “temporary” simply because they are not stored in a vault; temporary is a lifecycle property, not a storage location.
Examples and Use Cases
Per-machine credential inventory shows up wherever individual devices accumulate trusted access material. It is most valuable when the same machine can hold multiple credentials with different owners, lifetimes, and blast radii.
- Engineering laptops that retain cloud CLI profiles, SSH keys, and browser-stored sessions after a project ends.
- Build servers that cache deployment tokens, package registry credentials, or signing keys needed during CI/CD runs.
- Production hosts that carry service credentials in local configuration files, mounted volumes, or agent settings.
- Admin workstations that temporarily hold privileged tokens during maintenance windows and must be cleared afterward.
- Endpoint response workflows where security teams need to know which local artefacts must be revoked before a device is reimaged or reassigned.
In each case, the inventory is not just documentation, it is a practical control surface for rotation, containment, and recovery. It also exposes a tradeoff: the more automation and local caching a machine uses, the easier operations become, but the more important it is to know exactly what the machine can still use if it is lost, compromised, or repurposed.
For credential sprawl patterns, Guide to the Secret Sprawl Challenge is a useful companion reference, and OWASP Non-Human Identity Top 10 helps frame why unmanaged machine-held access material creates recurring exposure.
Security Implications
A weak per-machine credential inventory turns endpoint access material into hidden persistence. If teams do not know what lives on the device, they cannot reliably revoke it, rotate it, or prove that a cleanup actually happened. The result is stale access, orphaned secrets, and unknown privilege that survives long after the business reason for the credential has disappeared.
That creates direct operational risk. A stolen laptop, a compromised workstation, or an over-permissioned build node can become a shortcut to cloud services, internal APIs, deployment pipelines, and data stores. In practice, the failure is usually not “no inventory existed at all,” but “the inventory was incomplete, stale, or disconnected from ownership and rotation.”
There is also a visibility problem: local credential artefacts are often scattered across files, caches, environment layers, and tooling defaults, so teams underestimate exposure until an incident forces discovery. For attacker behaviour around exposed cloud access material, the NHIMG article LLMjacking: How Attackers Hijack AI Using Compromised NHIs notes that when AWS credentials are exposed publicly, attackers may attempt access within an average of 17 minutes. That speed shows why delayed inventory and delayed revocation are dangerous.
Security, Operational and Governance Implications
Per-machine credential inventory matters because it connects local device state to governance decisions about ownership, exposure, and revocation. It gives security teams a testable way to ask whether a device still has credentials it should not possess, and whether those artefacts are still within policy.
Operationally, the inventory becomes most valuable during offboarding, incident response, and endpoint reassignment. If a machine can hold secrets outside the vault, then standard account revocation is not enough, because the local artefacts may continue to authorize access until they are removed or invalidated.
Governance teams also use the inventory to separate acceptable caching from uncontrolled accumulation. That distinction matters in hybrid estates, where the same device may carry human, automation, and service access in different places and lifetimes. The practical question is not just who owns the machine, but who owns each credential on it, how it is rotated, and how quickly it can be proved absent after remediation.
For lifecycle and exposure patterns in non-human access, the The 2024 Non-Human Identity Security Report is relevant because it highlights how often organisations still struggle with consistent control over non-human access material.
Risk and Threat Considerations
Per-machine credential inventory has a material risk dimension because hidden endpoint-held credentials can widen blast radius, delay containment, and preserve access after a device is compromised or reassigned. The risk is strongest when local artefacts are long-lived, poorly owned, or distributed across many machines.
Failure mechanism: Attackers, insiders, or simple operational drift can exploit unmanaged local credentials by finding cached tokens, keys, or sessions on the endpoint and using them before rotation or revocation occurs. A weak inventory makes those artefacts hard to discover, so the compromise path can persist even after the original account is reset.
Impact: Access can extend beyond the device into cloud services, internal systems, or deployment paths, creating persistence, lateral movement potential, and a larger incident response scope. It also increases the chance that a supposedly clean device still carries active trust material when it is returned to service.
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 CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | Per-machine credential inventory supports knowing which local credentials grant access. |
| Recommendation — Track device-held credentials so you can revoke and rotate access promptly. | ||
| CIS Controls v8 | 6.3 — Data Recovery | Local credential inventories improve recovery by identifying artefacts that must be removed or reset. |
| Recommendation — Remove local secrets during recovery workflows before returning a device to service. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | The term centers on inventorying machine-held credentials and tying them to owners. |
| NHI-02 — Lifecycle and Revocation | Per-machine inventories are needed to revoke local secrets when device state changes. | |
| Recommendation — Maintain an inventory of every device-held credential and assign clear ownership. Revoke or rotate device-held credentials as soon as the device leaves its trusted state. | ||
