Continuous product security evidence is replacing checkpoint audits

At a glance

What this is: This is Finite State’s case for continuous product security evidence in connected devices, with the core finding that checkpoint-based programs do not keep pace with modern firmware and regulatory demands.

Why it matters: It matters to security and identity practitioners because device integrity, firmware assurance, and post-shipment vulnerability management increasingly intersect with broader governance, compliance, and operational resilience decisions.

Context

Connected devices are no longer simple hardware-plus-firmware assets. They are systems of systems with multiple cores, multiple firmware stacks, and runtime decisions that can affect safety, compliance, and operational continuity after shipment.

The governance gap is that many product security programmes still behave like audit response functions. They collect evidence at release time, while frameworks such as EU CRA, FDA 524(b), ISO 21434, and IEC 62443 assume evidence is maintained continuously across the product lifecycle.

Key questions

Q: What breaks when connected-device security relies on checkpoint reviews?

A: Checkpoint reviews fail when the shipped product no longer matches the evidence collected at design or release. In multi-stage firmware environments, the attack surface evolves as code is compiled, linked, packaged, and updated. Security teams then end up proving intent instead of proving what actually shipped, which weakens both remediation and audit defensibility.

Q: Why do connected devices need continuous evidence for compliance?

A: Because regulators increasingly expect proof that is maintained through the lifecycle, not reconstructed after an incident or audit request. Continuous evidence aligns security, engineering, and compliance around the same artefacts, reducing disputes about version scope, exploitability, and control ownership. It also shortens the time between a flaw being found and a defensible response being issued.

Q: How should security teams decide whether to trust a third-party SBOM?

A: Security teams should trust a third-party SBOM only when they can verify provenance, ownership, and reviewability of the fields they care about. If citations are missing, cryptography is vague, or patent claims are untraceable, the document should be treated as incomplete evidence rather than a final control artifact.

Q: What should manufacturers do when an actively exploited vulnerability appears in a supported product?

A: They should rapidly confirm product scope, assess reachability, document the decision, and determine whether the finding triggers the CRA notification duty to ENISA. The key is to contain uncertainty before it becomes a reporting and customer-communication problem.

Technical breakdown

Why checkpoint security breaks down in multi-stage firmware environments

A checkpoint model assumes product risk can be assessed at a few fixed moments, usually before release and again when an auditor asks for evidence. That assumption fails when a device includes multiple firmware stacks, mixed operating environments, and components that only become visible after compilation or integration. In that world, the attack surface changes as the product moves from source to build to shipped image, so a static SBOM or one-time scan quickly becomes incomplete. Continuous evidence generation is the only way to keep the record aligned with the artefact that actually ships.

Practical implication: Treat firmware assurance as a lifecycle control, not a release checklist.

How ground truth SBOMs differ from declared design inventories

A declared SBOM reflects what teams intended to build, while a ground truth SBOM reflects what was actually compiled, linked, and shipped. That distinction matters because source-code analysis misses vendored libraries, transitive components, and build-time differences that only binary analysis can see. In embedded and connected-device environments, those hidden dependencies are where unexpected exposure often lives. If the inventory is not derived from the shipped binary, vulnerability management and compliance reporting will rest on assumptions rather than evidence.

Practical implication: Use binary-derived inventory as the control baseline for shipped-device assurance.

Why post-shipment vulnerability management has become operational, not episodic

Once a product ships, the security problem does not end. Regulators expect active exploitation reporting, postmarket monitoring, and ongoing vulnerability management across every supported version in the field. That means PSIRT is now an operating capability tied to live SBOM correlation, product-version identification, and coordinated disclosure. The practical challenge is scale: teams cannot manually assemble the evidence, triage the affected versions, and map obligations every time a new flaw emerges. Continuous correlation and release-linked documentation turn that response into a repeatable process.

Practical implication: Build post-shipment correlation and disclosure workflows into steady-state operations.

Threat narrative

Attacker objective: The attacker’s objective is to exploit shipped device flaws before defenders can correlate the issue to affected versions and contain exposure.

1. Entry begins when a vulnerability exists in a shipped product and becomes visible through vulnerability research or public disclosure.
2. Escalation occurs when the flaw can be turned into a working exploit faster than many teams can identify affected firmware versions and product variants.
3. Impact is realised when compromised devices affect safety, availability, or regulated operations in the field.

Breaches seen in the wild

• HPE Aruba Instant On hard-coded credentials: Hard-coded admin credentials in HPE Aruba Instant On access point firmware let anyone bypass login (CVE-2025-37103); no exploitation reported.

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

Continuous evidence is now the real control plane for product security. Checkpoint programmes assume the useful security record can be assembled after the fact. In connected devices, that assumption fails because the evidence that matters is created across design, build, release, and field operations. The practical conclusion is that product security governance has to shift from reconstruction to continuous provenance.

Ground truth matters more than declared inventory in firmware-heavy environments. A design-time SBOM can be directionally useful, but it is not enough when build outputs differ from source intent. Binary analysis and shipped-artifact correlation are what make vulnerability management defensible, especially when third-party components are hidden until compilation or linkage. Practitioners should treat shipped inventory as the authoritative record.

Regulatory pressure is collapsing the gap between compliance and operations. The article’s own references to EU CRA, FDA 524(b), ISO 21434, and IEC 62443 point to the same direction: continuous evidence, continuous monitoring, and continuous accountability. That pushes product security away from annual certification habits and toward operating models that can sustain lifecycle proof. Teams that still separate compliance from engineering will struggle to prove control effectiveness.

AI-enabled products widen the assurance problem because the device is now making decisions, not just running code. When AI is embedded into physical systems, product security is no longer only about software defects or firmware provenance. It also becomes about runtime trust, update integrity, and the consequences of machine decisions in safety-critical contexts. That is a governance problem as much as a technical one, and it belongs in the same continuous assurance model.

Audit readiness is becoming a by-product of operational discipline, not a project milestone. The strongest programmes will not be the ones that scramble best before a submission. They will be the ones that can show evidence was created at the cadence of development and preserved through release and field operation. Practitioners should build for defensibility first, because defensibility is what auditability now depends on.

What this signals

Continuous product evidence is becoming the practical boundary between defensible governance and reactive reporting. Teams that still assemble artefacts after the fact will keep finding that the record is technically complete but operationally unconvincing.

Parallel proof across engineering and compliance is now the differentiator. The programmes that will cope best are the ones that preserve shipping velocity while generating release-ready evidence at the same cadence.

For connected devices, the control question has shifted from whether a scan was run to whether the shipped artefact can still explain itself. That is the standard product security teams need to prepare for.

For practitioners

• Build continuous evidence generation into the development lifecycle Map design, build, release, and post-shipment outputs so evidence is produced at each stage rather than assembled at the end.
• Use binary analysis as the inventory source of truth Base the shipped SBOM on firmware binaries and release artefacts, not only on declared source components, so hidden dependencies and build-time drift are visible.
• Link postmarket monitoring to live product versions Correlate vulnerability intelligence against the live shipped SBOM and product-version matrix so triage, disclosure, and remediation are version-specific.
• Map compliance obligations to operating workflows Translate EU CRA, FDA 524(b), ISO 21434, and IEC 62443 expectations into recurring operational controls, ownership, and evidence retention.

Key takeaways

• Checkpoint-based product security cannot keep pace with modern connected devices because the artefacts that matter are created across the lifecycle, not at one audit moment.
• Binary-derived inventory and live version correlation are the controls that make firmware vulnerability management defensible in the field.
• Continuous evidence generation turns audit readiness into an operating outcome instead of a last-minute reconstruction exercise.

Key terms

• Ground Truth SBOM: A ground truth SBOM is the component inventory derived from the shipped binary or final release artefact, not from design intent alone. It captures what was actually compiled and packaged, which makes it more reliable for vulnerability triage, version matching, and compliance evidence.
• Continuous Evidence: Continuous evidence is operational proof that identity controls are working now, not just at the time of an audit. It replaces one-off snapshots with current signals about ownership, rotation, access, and usage, which is essential when identities change too quickly for periodic review alone.
• Product Security Trilemma: The product security trilemma is the trade-off between staying secure, staying compliant, and staying competitive at the same time. The article argues that checkpoint-based programmes usually achieve only two of those goals, while continuous assurance is designed to preserve all three.
• Postmarket Vulnerability Management: Postmarket vulnerability management is the ongoing process of tracking, assessing, and responding to vulnerabilities after a product has shipped. It depends on live product-version data, affected-asset correlation, and repeatable disclosure workflows so field exposure can be contained without guessing.

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 the course if your programme needs a stronger foundation in governed access, lifecycle control, and machine identity risk.