Workload discovery is the process of finding and cataloging running services, applications, and infrastructure components so security teams can understand what exists and how it connects. In identity security, it must capture runtime relationships, ownership, and change over time, not just static asset records or registration data.
Expanded Definition
Workload discovery is the disciplined process of finding services, containers, VMs, serverless functions, and supporting components so they can be identified as identities, not just assets. In NHI security, the goal is to map runtime presence, ownership, communication paths, and lifecycle change, which is broader than a CMDB snapshot or cloud registration record.
Definitions vary across vendors, but the practical standard is whether discovery can answer four questions: what is running, where it runs, who owns it, and what it is allowed to talk to. That distinction matters because a workload can be technically present yet still invisible to identity governance if its credentials, certificates, or trust relationships are not captured. The SPIFFE workload identity specification is useful here because it frames workloads as first-class subjects with verifiable identity, not just endpoints. NHI Management Group also treats discovery as the front door to lifecycle control, as reflected in the NHI Lifecycle Management Guide.
The most common misapplication is treating workload discovery as a one-time inventory exercise, which occurs when teams record assets at deployment but fail to track runtime churn, ephemeral instances, or ownership changes.
Examples and Use Cases
Implementing workload discovery rigorously often introduces telemetry and reconciliation overhead, requiring organisations to weigh broader visibility against added engineering and operational cost.
- Discovering microservices in Kubernetes by correlating pod metadata, service accounts, and east-west traffic so each service account is tied to a live workload identity.
- Identifying unmanaged API backends in cloud accounts where infrastructure-as-code exists, but the actual runtime services have drifted from the original registration state.
- Mapping ephemeral CI/CD runners to their issued tokens and certificates so short-lived execution nodes do not become invisible trust endpoints.
- Using workload discovery to validate certificate scope and expiration across service meshes, especially when NHI risk gaps already show weak visibility and delayed remediation.
- Aligning discovered workloads to Guide to SPIFFE and SPIRE patterns so identity can be issued, rotated, and verified consistently across dynamic environments.
These use cases matter because discovery is only useful when it captures change over time. A service discovered in dev may later be promoted, cloned, or replaced without a matching update to its identity records. Without that runtime correlation, security teams cannot tell whether an observed connection belongs to an approved workload or an orphaned one.
Why It Matters in NHI Security
Workload discovery is foundational because every downstream NHI control depends on knowing what exists. Secrets review, certificate rotation, ownership assignment, and zero trust policy enforcement all fail when inventories are incomplete. NHI Management Group reports that 57% of organisations lack a complete inventory of their machine identities, and 53% have already experienced a security incident directly related to machine identity management failures. That gap is not academic: if the security team cannot see a workload, it cannot validate its credentials, constrain its privileges, or retire it when it is no longer needed.
Discovery also exposes governance drift. Workloads often outlive the teams that created them, inherit overbroad access, or continue operating with stale certificates and hard-coded secrets. The Top 10 NHI Issues page is a useful reminder that visibility failures and poor ownership discipline are usually coupled problems. Once discovery reveals shadow workloads, orphaned identities, or untracked runtime dependencies, those findings become the basis for policy enforcement rather than a documentation exercise.
Organisations typically encounter certificate sprawl, orphaned access, or unexplained service-to-service trust only after an outage, audit failure, or incident response event, at which point workload discovery 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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Discovery and inventory are core to identifying and governing non-human identities. |
| NIST CSF 2.0 | ID.AM-1 | Asset management requires knowing physical and virtual assets, including workloads. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust depends on knowing each workload before allowing connections and policy decisions. |
| NIST AI RMF | AI systems require identification of model-serving workloads and their dependencies. | |
| CSA MAESTRO | MAESTRO emphasizes securing autonomous workloads and their orchestration context. |
Continuously discover workloads and reconcile them to authoritative inventory and ownership records.
