A registration approach where asset metadata is created from code, deployment or orchestration events rather than manual entry. It reduces drift by making the inventory reflect the same system that actually ships and runs in production.
Expanded Definition
Capture-at-Source is the practice of creating NHI asset records from the system events that actually produce them, such as code commits, deployment pipelines, orchestration controllers, or cloud provisioning logs. That makes the inventory reflect operational reality rather than a stale spreadsheet or manually typed form.
In NHI governance, this approach is especially useful for service accounts, workload identities, API keys, certificates, and other secrets that are born, rotated, or revoked through automation. It aligns closely with the visibility and control expectations described in the NIST Cybersecurity Framework 2.0, because the inventory becomes part of the control plane rather than a separate recordkeeping exercise. Definitions vary across vendors on whether capture-at-source includes passive discovery, but NHIMG treats the term as a registration model anchored to the authoritative system of creation.
The most common misapplication is treating a later scan or manual spreadsheet import as capture-at-source, which occurs when teams record assets after deployment instead of at the event that creates them.
Examples and Use Cases
Implementing capture-at-source rigorously often introduces workflow coupling, requiring organisations to weigh inventory accuracy against the friction of integrating registration into CI/CD, IaC, and orchestration tooling.
- A CI/CD pipeline emits a registration event whenever a new workload identity is created, so the NHI inventory is updated before the service reaches production.
- An infrastructure-as-code change that provisions a secret, certificate, or service account also creates the asset record, reducing the lag between deployment and governance review.
- A cluster manager registers ephemeral workload identities at pod start, which is especially useful when identities exist for minutes rather than days.
- A cloud account creation event is captured directly from the provider control plane and linked to ownership, scope, and rotation policy.
- NHIMG analysis of the Microsoft Midnight Blizzard breach and the Salt Typhoon US telecoms breach shows why delayed visibility into identities and credentials creates operational blind spots; capture-at-source is one way to close that gap.
For implementation guidance, teams often pair this model with source-of-truth controls described in NIST-aligned identity governance and with provisioning standards such as SCIM protocol operations when identity systems can emit machine-readable lifecycle events.
Why It Matters in NHI Security
Capture-at-source matters because most NHI failures begin with missing, delayed, or incomplete inventory. If an identity or secret is not registered when it is created, then ownership, rotation timing, privilege review, and offboarding can all drift out of sync. That is how “unknown” service accounts, orphaned API keys, and unmanaged certificates persist long after the application that created them has changed. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, while 96% store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes source-linked registration more than a bookkeeping improvement.
Used well, capture-at-source supports faster remediation, stronger Zero Trust enforcement, and cleaner audit evidence. It also helps security teams correlate a running workload with the exact deployment or pipeline event that created its identity footprint, which is essential when investigating misuse or over-privileged access. It supports the visibility objectives in NIST Cybersecurity Framework 2.0 and helps translate governance intent into machine-enforced registration. Organisations typically encounter the cost of missing capture-at-source only after a breach, at which point identity inventory reconstruction becomes 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-01 | Source-linked registration reduces unseen NHIs and inventory drift. |
| NIST CSF 2.0 | ID.AM-1 | Asset management requires inventories that reflect production reality. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero Trust depends on knowing which identities exist and how they are issued. |
Register NHIs at creation events and keep ownership tied to the authoritative source.
