TL;DR: Roughly a third of first-wave DORA Register of Information submissions returned invalid or missing LEI codes, while blank sub-outsourcing templates were common, showing that manual, scanner-led inventories still fail when institutions must map dependency chains and vendor-of-vendor relationships, according to Kusari. The real issue is not filing quality but governance blindness across source, build, and supplier data.
At a glance
What this is: Kusari shows that first-wave DORA register submissions failed in predictable ways because institutions could not assemble complete dependency and sub-outsourcing chains from scanner-built inventories.
Why it matters: This matters because IAM, NHI, and cloud governance teams need inventories that reflect real ownership, provenance, and supplier dependency, not just what a scanner can infer from manifests.
Context
DORA register failures expose a common governance gap: organisations often have a software or service inventory in fragments, but not a defensible dependency graph. Scanner-built inventories are useful for discovery, yet they frequently stop at the manifest and miss transitive components, supplier chains, and the provenance data that regulators now expect.
The identity angle matters because these inventories increasingly describe machine-to-machine and vendor-to-vendor trust relationships, not just systems on a list. When legal entity identifiers, sub-outsourcing links, and asset ownership data are missing, teams cannot prove who is responsible for access, resilience, or offboarding across the chain.
Kusari's account is therefore not about one filing defect. It is a signal that many institutions are trying to satisfy regulatory mapping requirements with tooling designed for detection, not governance.
Key questions
Q: What are the best practices for handling legal entity identifiers in regulated inventories?
A: Keep legal entity identifiers attached to the asset or service record, not in a separate spreadsheet, and validate them before filing. If LEI data is missing or invalid, the register cannot reliably identify the counterparty behind the service chain.
Q: Why do sub-outsourcing chains matter for resilience and accountability?
A: They show which vendors sit behind material services, so the organisation can trace dependence, ownership, and failure paths. Without that chain, incident response and recovery planning stop at the contract boundary and miss the operational reality underneath.
Q: How do source-built inventories improve third-party risk governance?
A: They reconcile source, build, and supplier data into one evidence chain, which makes it easier to prove composition, provenance, and ownership. That gives third-party risk teams a defensible record instead of a best-effort reconstruction from scanner output.
Q: What is the difference between a manifest and a provenance record?
A: A manifest says what a package claims to contain, while a provenance record shows how that package was built, signed, and released. In regulated environments, provenance is the stronger control because it can expose drift or tampering that a manifest will never show on its own.
Technical breakdown
Why scanner-built inventories stop at the manifest
A scanner usually inspects a finished artifact and reads the manifest to infer what is inside it. That works for the first layer or two of dependencies, but deeper transitive components often disappear into the report rather than being marked as unresolved. The result is a clean-looking inventory that is structurally incomplete, which is dangerous when the regulator asks for supplier chains, component provenance, or material sub-outsourcing detail. In governance terms, the tool tells you what was declared, not what is actually present across the build graph.
Practical implication: Treat scanner output as discovery input, not a compliance-grade inventory of record.
Why transitive dependencies change the control problem
Transitive dependencies are components brought in by other components, which means the control problem is no longer just 'what did we choose?' but 'what did our suppliers choose on our behalf?' That makes asset inventories, SBOMs, and vendor registers interdependent. If the organisation cannot reconcile source, build, and supplier data, the inventory cannot support ownership, risk classification, or resilience decisions. For identity teams, this is the same pattern seen in non-human identity estates: the critical question is not just what exists, but who owns it, who can change it, and where it sits in the trust chain.
Practical implication: Build a governed dependency model that links source, build, and supplier records before you rely on any inventory for audit or resilience work.
Why provenance checks matter as much as completeness
A complete list is still not enough if the distributed artifact has diverged from the source that supposedly produced it. Provenance controls compare what was built, signed, and shipped against the source and build evidence, so drift and tampering are visible. That matters when a package or component has been altered outside the expected repository path. Machine-readable formats such as SPDX and CycloneDX help with composition, but provenance attestation is what lets a third party verify that the inventory matches the released artifact rather than a best-effort reconstruction.
Practical implication: Pair component inventories with provenance attestation so reviewers can verify both completeness and integrity.
Threat narrative
Attacker objective: The practical objective is to hide risk inside untracked dependencies and trusted supplier chains so governance, remediation, and disclosure all start from incomplete data.
- Entry occurs through an incomplete or scanner-built inventory that captures only the first layers of the dependency graph.
- Credentialed trust in the manifest and supplier declarations allows hidden transitive components and vendor-of-vendor relationships to remain unreviewed.
- Escalation happens when institutions must file DORA, PCI, or NYDFS records without enough provenance to reconcile ownership, location, and sub-outsourcing.
- Impact is regulatory non-compliance, weak resilience planning, and slow incident response because teams cannot quickly tell what is affected.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Scanner-built inventory is not governance-grade inventory. Discovery tooling is valuable, but it is designed to observe artefacts, not to prove lineage, ownership, or sub-outsourcing depth. Once regulators ask for vendor-of-vendor relationships and material dependencies, the control boundary moves from visibility to evidence. Practitioners should treat scanner output as a feed into governed records, not as the record itself.
Dependency graphs are now an identity problem as well as a software problem. The register errors expose a trust chain issue: organisations cannot answer who owns each node, who can act on it, and which external parties sit behind it. That is the same governance failure pattern NHIs create when service accounts, tokens, and supplier access are left outside a lifecycle model. The practitioner takeaway is to align asset, supplier, and identity governance in one chain of accountability.
Provenance closes the gap that manifests cannot. A manifest can describe intent, but it cannot prove that the shipped artifact still matches the source or build evidence. This is why source-built inventories and attestations matter when the environment includes software supply chains and regulated records. The control gap is not just missing data, but unverified data, and that distinction now matters for audit, resilience, and incident response.
Regulatory pressure is forcing a move from periodic documentation to always-available inventory. DORA's on-request register requirement makes quarterly manual assembly obsolete, and similar expectations are spreading across resilience and software assurance regimes. The field is heading toward continuous evidence, not annual reconciliation. Practitioners should expect governance teams to demand machine-verifiable lineage instead of spreadsheet summaries.
Governance blindness is the right named concept here. These failures happen when institutions can enumerate assets in theory but cannot assemble the dependency, supplier, and provenance picture quickly enough to stand behind it. The result is not just filing defects. It is an inability to govern the real trust structure of the environment, which is now the operational problem.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Governance teams should expect inventory quality to become a standing control, not a filing scramble. If a register cannot be assembled quickly from source, build, and supplier data, then the organisation does not really own the dependency graph it is reporting. That changes audit preparation, third-party oversight, and incident readiness in the same direction: evidence has to exist before the question arrives.
Scanner outputs are still useful, but only as one input to a broader evidence chain. The more the environment depends on supplier ecosystems, the more the inventory becomes a control over trust relationships rather than a catalog of software names. Practitioners should align inventory design with the broader governance problem, not just the tooling workflow.
Governance blindness means the record exists somewhere in fragments, but not in a form that can be defended. Organisations that close that gap will be better placed to meet DORA-style on-demand requests, explain ownership, and support faster incident scoping when the dependency chain matters most.
For practitioners
- Replace scanner-only inventories with governed source-built records Capture source, build, and supplier data in one inventory process so the record can support DORA, PCI, and resilience reporting without manual reconstruction.
- Track sub-outsourcing chains to the material-supplier level Map vendor-of-vendor dependencies explicitly, including the contractual and service relationships that sit behind material sub-contractors.
- Add provenance attestation to inventory workflows Use signed build evidence and artifact verification so teams can compare released software against the source that produced it.
- Record legal entity and ownership data with each asset Attach LEI, owner, location, classification, support expiration, and recovery objectives to the asset record rather than keeping them in separate documents.
Key takeaways
- Scanner-led inventories can miss the dependency and supplier-chain detail that DORA now expects.
- The operational issue is not just missing fields but an inability to assemble a defensible dependency graph on demand.
- Source-built inventory models with provenance give security and compliance teams a better basis for ownership, resilience, and audit response.
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 MITRE ATT&CK 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party and vendor-of-vendor chains are central to the register failure pattern. |
| NHI-08 — Environment Isolation | Incomplete inventory and provenance gaps expose weak separation between build, source, and supplier environments. | |
| Recommendation — Map supplier-linked identities and credentials to NHI-03 before you rely on them in regulated inventories. Separate build, source, and supplier evidence paths so inventory data cannot blur across environments. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Hidden dependency chains and trusted artifacts are a common path for credential-enabled supply-chain abuse. |
| Recommendation — Map supply-chain exposure to TA0006 and TA0008 when hidden dependencies expand attacker reach. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article turns on knowing who and what is authorised across service and supplier chains. |
| Recommendation — Use PR.AA-05 to keep access and entitlement records aligned with the inventory you report. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Software and component inventory quality is the core control issue described here. |
| Recommendation — Implement CIS-2 to maintain an authoritative software and component inventory with ownership data. | ||
Key terms
- Dependency graph: A dependency graph maps the systems, services, and workflows that rely on a non-human identity. It helps responders understand blast radius and operational impact before disabling an identity, which is critical when service accounts or tokens are embedded in production processes.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
- Sub-outsourcing Chain: A sub-outsourcing chain is the sequence of downstream providers used by a vendor to deliver a service. It matters because accountability, resilience obligations, and data or access risks do not stop at the first supplier. Regulators increasingly expect organisations to understand the whole chain.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity lifecycle control to the broader security programme they are accountable for.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org