TL;DR: Supplier declarations can satisfy paperwork while revealing nothing about what connected vehicle firmware actually contains, according to Block Harbor, because attestations often rest on supplier belief rather than independently verified inventory. In practice, integrity has to come from synthesising attestation data with firmware scans, not from signatures alone.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Block Harbor's blog post: Supplier attestations for connected vehicles can be empty when they are not backed by independent firmware inventory and verification.
Why it matters: OEM and supplier teams need evidence that an attestation matches the firmware itself, because signature-based compliance without inventory leaves integrity risk unresolved.
Context
A supplier attestation is only as strong as the inventory behind it. When a signer cannot map firmware, subcomponents, and software origins to a specific asset, the declaration captures belief rather than evidence.
That gap matters in connected vehicle programmes because compliance, product cybersecurity, and supply-chain governance all depend on knowing what is actually embedded in the system. Where suppliers do not maintain that mapping, the OEM inherits uncertainty instead of assurance. The starting position described here is typical, not exceptional.
Key questions
Q: How should OEMs verify supplier software attestations?
A: OEMs should verify supplier attestations by cross-checking the signed statement against independent evidence from firmware, SBOMs, and asset inventory. A declaration is only useful when the buyer can compare what the supplier believes with what the binary actually contains. Where those sources conflict, the result needs human review before any compliance filing or release decision.
Q: Why do supplier letters fail as proof of software provenance?
A: Supplier letters fail as proof of software provenance because they are self-declared statements, not independently verified evidence of code origin, build integrity, or component lineage. Provenance normally needs verifiable controls such as signed build artefacts, SBOMs, cryptographic hashes, source-to-binary traceability, and controlled release records that can be checked against the delivered package.
Q: How does firmware scanning support connected vehicle compliance?
A: firmware scanning supports connected vehicle compliance by identifying embedded software versions, known vulnerable components, and unexpected modules inside ECUs, infotainment units, and other embedded systems. It gives evidence for inventory, vulnerability management, and patch assessment when regulators or internal controls require proof of what firmware is actually deployed.
Q: What should teams do when a component cannot be reverse-engineered?
A: When a component cannot be reverse-engineered, teams should treat it as opaque third-party software and rely on supplier documentation, SBOM data, signed attestations, sandboxed testing, and contract controls for assurance. If those evidence sources are missing, the item should be restricted, replaced, or formally risk-accepted because its internal behaviour and dependencies cannot be verified.
Technical breakdown
Why supplier attestations become unenforceable without asset inventory
An attestation is a control statement, not proof. In supply chains, it depends on the signer having a defensible view of component composition, software origin, and upstream dependencies. If the supplier cannot trace subcomponents deeply enough, the declaration becomes an assertion about belief rather than an evidence-backed statement. That is why the same signed letter can be compliant on paper and useless for risk decisions. In connected vehicle environments, this problem is amplified because firmware, ECU content, and software dependencies evolve across build cycles and suppliers. See the ISO/IEC 27036 Supplier Relationships Guide.
Practical implication: Treat attestation as a claim that must be corroborated by an independent asset inventory before it is used for compliance sign-off.
How firmware scanning turns a declaration into a testable claim
Firmware scanning reverse-engineers a binary image into a software bill of materials, even when the supplier never provided one. That gives the buyer a second data source that can be compared with supplier letters and upstream SBOMs. The control value is not in the scan alone, but in the mismatch it exposes. When the declared origin and the observed contents diverge, the issue shifts from paperwork to evidence handling and escalation. This is especially relevant for connected vehicles, where a single component can be reused across many shipped units.
Practical implication: Use binary analysis to validate supplier claims before the declaration is signed, renewed, or used in regulatory filings.
Why human review still matters in software-origin determinations
Country-of-origin attribution is a synthesis problem. The result comes from combining scan output, supplier attestations, SBOMs, and other context against the same asset record, then flagging the outcome for review. That design matters because a single scan rarely provides enough certainty to make a legal or regulatory declaration on its own. Human owners remain accountable for resolving ambiguous results, especially when null findings or conflicting signals appear. In practice, the system is there to surface disagreement early enough for review, not to replace judgment.
Practical implication: Keep a human approval step for contested or incomplete findings so legal declarations are made from a defensible evidence set.
NHI Mgmt Group analysis
Empty attestations are a governance failure, not a documentation failure. The central problem is that the declaration can be complete while the underlying evidence is missing. That shifts risk from paperwork quality to source-of-truth quality, which is the real control gap in connected vehicle supply chains. Practitioners should treat attestation as an evidence chain that must be independently grounded, not as a finished control.
Connected vehicle compliance exposes a broader integrity gap in product cyber programmes. The issue is not simply whether restricted-region software exists, but whether anyone can prove what is inside a shipped system at the level of firmware and embedded software. That makes inventory discipline a prerequisite for any defensible declaration. Connected vehicle security work now depends on provenance evidence, not just supplier trust.
Verified attestation is the right concept for this problem. A letter from a supplier becomes useful only when it is cross-checked against a second source that can contradict it. This is a strong example of why product cybersecurity governance has to separate belief, evidence, and final determination. Practitioners should design for disagreement, because disagreement is what reveals where the assurance boundary actually is.
The null result is itself an operational signal. When firmware cannot be reverse-engineered enough to support attribution, the right response is not to certify it green but to route it for escalation. That creates a useful distinction between components that can be independently verified and components that still depend on supplier testimony. Practitioners should build escalation paths for unresolved images rather than treating uncertainty as acceptance.
What this signals
Provenance governance will become a first-class control in connected systems. Once declarations must stand up to independent inspection, the programme needs a stable way to link firmware, supplier claims, and asset records. That makes evidence management part of product cyber operations, not an audit afterthought.
Absence of attribution should be handled as a workflow state, not a verdict. When scanning cannot prove what a binary contains, the right control response is escalation and re-evaluation, not a green light. That distinction will matter increasingly as connected products and physical AI systems depend on software that can no longer be trusted on signature alone.
For practitioners
- Require an evidence-backed declaration workflow Make every supplier attestation contingent on a traceable firmware or component inventory tied to the exact asset being declared.
- Cross-check supplier claims with binary analysis Run firmware through independent scanning so the software bill of materials can be compared with the supplier's statement before sign-off.
- Escalate contradictions before filing Route any mismatch between attestation, SBOM, and firmware content to the product cyber owner for review before the declaration is used.
- Treat unresolved images as open risk Keep non-attributable firmware in an escalation queue and do not mark it approved until there is enough evidence to support a defensible determination.
Key takeaways
- Supplier declarations can be formally correct while still failing to prove what is inside connected vehicle firmware.
- The core weakness is not fraud but ungrounded belief, which makes inventory quality the real assurance problem.
- Independent binary analysis and human review are the controls that turn an empty attestation into a defensible one.
Related NHI Mgmt Group resources: ISO/IEC 27036 Supplier Relationships Guide · Connected and Autonomous Vehicle Security Guide · AI Model Provenance and Watermarking Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Supplier attestations only matter when risk decisions are grounded in evidence, not belief. |
| Recommendation — Link declaration sign-off to an evidence-based risk strategy and escalate unresolved provenance gaps. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article is about governance over supplier access and accountability in the evidence chain. |
| Recommendation — Track supplier accountability for each component and revoke trust when evidence cannot be substantiated. | ||
| MITRE ATT&CK | TA0007;TA0009 — Discovery; Collection | The article centres on discovering what is actually inside firmware and collecting evidence for attribution. |
| Recommendation — Map firmware visibility work to discovery and collection so provenance findings are repeatable and reviewable. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | A defensible declaration depends on knowing the exact components and embedded software present in the asset. |
| Recommendation — Maintain a complete component inventory before using supplier declarations for compliance sign-off. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier declarations and verification are part of controlling third-party risk across the supply chain. |
| Recommendation — Apply supplier-relationship controls to require evidence, verification, and escalation for ambiguous declarations. | ||
Key terms
- Supplier Attestation: Supplier Attestation is a supplier’s formal statement about a product, component, or process. In security and software supply chains, it usually claims provenance, build integrity, vulnerability status, or compliance, but it is still declarative evidence unless backed by independent verification, cryptographic signing, or traceable artefacts.
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Firmware Scanning: Firmware scanning is the analysis of device firmware for known vulnerabilities, embedded secrets, outdated components and suspicious code. It is used on routers, servers, IoT devices and other embedded systems, often by extracting images and comparing them against signatures or inspecting them statically for dangerous functions and hard-coded credentials.
- Connected Vehicle Security: Connected vehicle security is the set of controls that protect vehicles which exchange data with cloud services, suppliers, mobile apps, and remote management systems. It extends beyond in-vehicle hardening to cover update trust, telemetry integrity, and command authorization across the full operating lifecycle.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org