Finite State

Deliberate B, and the reasoning matters because the marketing invites a higher grade than the evidence supports. The analytical depth here is real and considerable: binary unpacking across 130-plus formats and 30-plus architectures, software composition analysis extracting control flow graphs and symbols from compiled binaries, static analysis of decompiled code, and reachability analysis over call graphs.

But those are program analysis techniques, sophisticated and algorithmic rather than machine learning, and the company's more recent AI-native execution and Product Security OS language is newer positioning layered over that foundation rather than a description of the core method. Graded B because the computation is genuinely the product and cannot be done manually at scale, but not A because no machine learning model is identified as doing the decisive work. Higher than MedCrypt at C, whose core is a rules engine over curated public feeds.

Automated analysis producing evidence for engineering and regulatory decisions, embedded into the release workflow rather than acting independently. The reachability determination is the consequential automated judgement: classifying a vulnerability as unreachable and therefore not-affected in a VEX document is a decision a manufacturer will defend to a regulator, and it is generated by the platform.

The company frames output as defensible justifications and traceable reports, which is the right posture, and a customer quote describes using it to focus on validating what is truly exploitable rather than accepting findings blindly. Graded B rather than A because no confidence threshold or human review gate governing the not-affected determination was located.

The most technically specific disclosure of any vendor in this category. Named methods rather than claimed outcomes: binary SCA decomposing images into subcomponents by extracting function names, control flow graphs and symbols; binary SAST analysing decompiled code for unsafe function calls with named consequence classes including denial of service, privilege escalation and full system takeover; reachability analysis over call graphs and entry points.

Quantified scope at 130-plus binary formats and 30-plus architectures, and named output standards in SPDX, CycloneDX and VEX. A security engineer can evaluate whether this approach would work on their firmware from the description alone, which is the standard the index's category editorial asks for and which almost nothing else in this lane meets.

The methods are described at a level that lets a security engineer evaluate the approach before buying it, which is what this axis asks for and what almost nothing else in this lane provides. Binary composition analysis is described as decomposing images into subcomponents by extracting function names, control flow graphs and symbols; static analysis is described as examining decompiled code for unsafe function calls with the consequence classes named; and reachability analysis is described as operating over call graphs and entry points.

Scope is quantified at more than one hundred and thirty binary formats and more than thirty architectures, and the output standards are named, so a buyer can establish whether their own firmware is in scope and whether the results will fit their existing tooling. The chain itself is short and clean: customers are device manufacturers and the material analysed is firmware, binaries and source code, so no protected health information is involved at any point.

One asset in the chain deserves naming because it is easy to overlook while thinking about patient data. The platform holds complete decompositions of customers' proprietary firmware, including the hard coded secrets and cryptographic misuse it exists to surface, which is commercially sensitive intellectual property and a high value target in its own right. Ask how those decompositions are retained and segregated, and what happens to them at contract end.

Specific performance claims but no independent validation. Reported reductions of up to 80 percent in false positives and up to 90 percent in noise from reachability analysis are attributed to customer experience, with a named Product Security Lead quoted on the 80 percent figure, and G2 reviews corroborate depth of firmware and supply chain visibility. But no methodology, sample or independent benchmark supports the figures, and the phrasing up to is doing real work.

A Health-ISAC partnership offering free SBOM and risk assessment for three products is credible third party association rather than measured performance. Same standard applied to MedCrypt, whose competitive case studies were similarly vendor-authored. Note G2 reviewers also flag effort required to reach the first useful result, which the company acknowledges directly rather than disputing.

Structurally clean for the same reason as MedCrypt, and worth stating rather than treating as absence of risk. Customers are device manufacturers and the data analysed is firmware, binaries and source code, so no protected health information is involved at any point.

The sensitive asset here is different but real: the platform holds complete decompositions of customers' proprietary firmware including hard-coded secrets and cryptographic misuse it surfaces, which is commercially sensitive intellectual property and a high-value target in its own right.

Converted from Not Rated, and this is a genuine category non application rather than a gap.

The health privacy rule does not reach this relationship. Customers are connected device manufacturers, and the inputs are software artefacts: firmware images, binaries, software bills of materials and vulnerability findings. There is no covered entity in the chain and no protected health information changing hands, so no business associate agreement would ordinarily be required. Grading C would penalise a business model for lacking an instrument that does not apply, which this index has ruled against and applied consistently to the two comparable device security vendors it holds.

The company also does not claim health privacy compliance it does not need, which is worth crediting for the same reason it was credited on those peers.

What replaces the statutory floor is contractual, and here the confidentiality stakes are unusually high even without patient data. Binary first analysis means customers upload shipped firmware, including proprietary and encrypted components, and the platform decomposes it to reveal file systems, libraries and hard coded secrets. That is a manufacturer's product internals in a form its competitors and attackers would both value.

One edge case is worth closing before deployment, as with the peers. Firmware from a clinical device could in principle contain embedded patient data or configuration referencing it. If it can, the analysis changes.

Ask what the confidentiality and breach terms are, and whether uploaded artefacts can contain patient data.

Converted from Not Rated, and this is the sharpest instance of a finding this index has now confirmed across the whole category.

No SOC 2 of either type, no ISO 27001, no HITRUST, no trust centre and no penetration testing statement was retrieved.

The standing observation is that none of the security vendors this index holds publishes an attestation of its own. This pass has now checked six of them individually and the finding survives every check. Companies whose product is assessing whether others are secure do not evidence their own posture.

What makes this the sharpest case is the specificity of the holding. Binary first analysis works by unpacking the shipped artefact: more than 130 binary formats across dozens of architectures, decomposing encrypted and proprietary firmware without source access, extracting function names, control flow graphs and symbols, and running static analysis on decompiled code to find unsafe calls enabling privilege escalation or full system takeover. Hard coded secrets surface as a matter of course.

Stated plainly, the platform holds a decomposed map of exactly how a manufacturer's fielded devices can be compromised, assembled across many manufacturers, and produced precisely because customers could not obtain that visibility themselves. There is no more attractive target in this segment.

Reachability analysis makes it more concentrated still, since knowing which vulnerable paths are actually executable is the attacker's question too.

Ask for the attestation, its type and period, and how uploaded firmware is segregated and retained.

Not itself FDA regulated, but graded A because regulatory mapping is built into the analysis rather than bolted on as reporting. Findings map automatically to FDA Section 524B of the FD&C Act and to IEC 62304, the medical device software lifecycle standard, and the platform generates audit-ready VEX documents with defensible not-affected justifications, which is the artifact a manufacturer actually needs when a reviewer asks why a known CVE in an SBOM component was not remediated.

Coverage extends beyond FDA to the EU Cyber Resilience Act, which matters for manufacturers shipping into both markets and is a genuine advantage over US-only tooling. The reachability capability is what makes the regulatory position substantive rather than procedural: it converts an unmanageable CVE list into a defensible position on which vulnerabilities actually matter.

No governance framework or validation disclosure located, and there is a specific exposure worth naming. Reachability analysis is used to justify NOT remediating vulnerabilities, so a false negative here does not merely miss a finding, it produces a documented regulatory justification for leaving an exploitable vulnerability in a shipped medical device. That is a higher-consequence error mode than over-alerting.

No published false negative rate, validation of the reachability determination, or independent audit of the not-affected justifications was located, and that is the single most important assurance question for this product class.

The disclosure here supports a form of self assessment that substitutes for a published accuracy figure without fully replacing it. Because the analysis methods are named specifically rather than described as proprietary intelligence, and because the supported formats and architectures are enumerated, a security engineer can reason from the description whether the approach would work on their own firmware and where it would struggle.

Static analysis of decompiled binaries has known limits, and a buyer who knows that is what they are getting can judge the fit rather than trusting a score. Naming the consequence classes the analysis flags, including denial of service, privilege escalation and full system takeover, is also a form of scope disclosure, since it tells a buyer what the tool is looking for and by omission what it is not. Held at C because nothing measures the result.

No detection rate, false positive rate or validation of the reachability analysis was located, and reachability is where this class of tool most often overstates, since a vulnerability reported as reachable that is not wastes engineering effort and one reported as unreachable that is not leaves a real exposure unaddressed. No warranty, indemnity or remediation commitment was found. Ask for false positive and false negative rates on reachability specifically, and how the analysis is validated against known firmware.

EHR integration is irrelevant to this buyer; the relevant surface is the manufacturer's development and supply chain toolchain, and coverage there is strong. The platform ingests and aggregates data from a reported 120-plus external sources, imports and enriches supplier-produced SBOMs alongside those it generates itself, reconciles results across all scans, and supports the three standard exchange formats in SPDX, CycloneDX and VEX.

It embeds into the release workflow rather than sitting alongside it, and a partnership with Somos integrates its binary analysis into an external IoT asset registry, demonstrating the platform functions as a component other systems build on.

Cloud platform embedded into the release workflow, with the significant deployment advantage that it requires no source code access, so it can analyse third-party and off-the-shelf components a manufacturer cannot otherwise inspect. That removes the dependency that blocks conventional application security tooling in this domain.

Graded B rather than A because no hosting architecture or data residency terms were located, which matters given customers upload proprietary firmware, and because G2 reviewers note effort required to reach the first useful result.

No pricing published and no pricing basis disclosed. The Health-ISAC offer of free SBOM generation and firmware risk assessment for three products is a genuine trial route for healthcare organisations and the only concrete commercial term located, but it is a member benefit rather than a pricing disclosure.

Broad across both artifact types and industries. Analyses firmware, compiled binaries and source code within one workflow, covering libraries, open source, third-party components, embedded software and drivers, with 50-plus instruction set architectures supported.

Serves connected device manufacturers across medical devices and automotive, and functional span runs from threat modelling of product architecture through SBOM generation, vulnerability analysis, reachability determination, release evidence packaging and continuous post-release monitoring as risks change. Covering design through post-market from a single system of record is materially wider than MedCrypt's SBOM and vulnerability management focus.