MedCrypt

Deliberate C, and the honest grade despite prominent AI marketing. The core of Helm is a rules engine plus curated third-party exploitability data: component matching via an alias rules engine, lifecycle rules automating end-of-support tracking, and severity and exploitability drawn from EPSS, CISA KEV, ExploitDB, Metasploit, NVD and CWE Top 25. Those are external feeds and deterministic matching, not models.

The genuine AI is narrower than the marketing implies: automated detection of which technology stacks a vulnerability affects, false positive suppression, and machine learning based risk mitigation recommendations. Real, but a layer on top. The actual moat is regulatory expertise and the medical-device-specific framing of general software supply chain tooling, which is why the company competes on being purpose-built for manufacturers rather than on model quality. Same principle applied to Reveleer, the credentialing lane and Censinet.

Automates assessment and scoring while leaving remediation decisions with the manufacturer's product security and regulatory teams. Auto-rescoring continuously monitors changes in vulnerability exploitability and fixability, with a reported reduction in assessment time of at least 90 percent, and bulk rescoring and bulk remediation import operate across a product portfolio.

That bulk operation model is the notable autonomy feature and also the risk worth naming: applying a rescore or remediation decision across many device versions at once is efficient but concentrates the consequence of a wrong judgement. Graded B rather than A because no confidence threshold or human review gate is described for the AI-generated stack detection and recommendations.

The strongest transparency position in the cybersecurity lane, earned by naming its data sources precisely rather than describing proprietary intelligence. Helm's exploitability assessment is explicitly built on EPSS, CISA KEV, ExploitDB, Metasploit, NVD and CWE Top 25, all publicly identifiable sources a buyer can evaluate independently, and it supports CVSS 2, CVSS 3.x and EPSS scoring.

The rules engine behaviour is documented publicly, including alias rules for component matching and lifecycle rules for end-of-support automation, and the company maintains public product documentation rather than gated materials. Naming your inputs allows a customer to reason about what the tool can and cannot know, which almost no vendor in this lane permits.

This is the clearest instance in the index of a vendor naming its inputs individually rather than describing proprietary intelligence, and the effect is exactly what this axis exists to reward. The exploitability assessment is built on publicly identifiable sources, each named: an exploit prediction scoring system, a government catalogue of known exploited vulnerabilities, public exploit databases, the national vulnerability database and a published ranking of common weaknesses, with support for the recognised vulnerability scoring standards.

A customer can go and read every one of them. The rules engine behaviour is documented publicly too, including alias rules for component matching and lifecycle rules for end of support automation, and product documentation is open rather than gated behind a sales process. Naming your inputs lets a customer reason about what the tool can and cannot know, which is a stronger form of disclosure than describing what it does, and almost no vendor in this lane permits it.

The structural position reinforces it: customers are device manufacturers and the material processed is software bills of materials, component inventories and vulnerability records, so there is no protected health information in the chain at all. Two residuals worth asking rather than assuming: how quickly source updates propagate into assessments, and what a customer is told when a source itself changes methodology.

All performance evidence is vendor generated. The company publishes case studies stating Helm outperforms commercial and open source competitors on speed and accuracy, and claims at least 90 percent reduction in assessment time, but no independent benchmark, named customer result or disclosed methodology was located. Competitive case studies authored by the vendor comparing itself to unnamed competitors are the weakest evidence form in this index. That said, the regulatory analysis the company publishes, including work on FDA premarket deficiency trends, is substantive industry contribution even though it is not product evidence.

Structurally the cleanest PHI position of any vendor in this index, and it is worth stating why rather than treating it as absence of risk. MedCrypt's customers are device manufacturers, and the data it processes is software bills of materials, component inventories and vulnerability records. It does not touch patient data, hospital networks or clinical systems at all. There is no PHI surface to steward.

Note one genuine security consideration the company itself raises, which is unusually candid: it warns that while the FDA recommends SBOMs be shared with customers for transparency, disclosure creates additional attack surface by revealing component details to threat actors, and states manufacturers must weigh that trade-off. Flagging the downside of a regulator's own recommendation is an admission against the compliance-tooling interest.

Converted from Not Rated, and the grade reflects a genuine category non application rather than a gap.

The health privacy rule does not reach this relationship. The customers are medical device manufacturers, and the data held is software composition, vulnerability findings, cryptographic key material and device behaviour telemetry. 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 here would penalise a business model for failing to hold an instrument that does not apply to it, which this index has ruled against elsewhere when an axis mismatches a vendor's position.

One thing is creditable and easy to overlook. The company does not claim health privacy compliance it does not need. A great many vendors in adjacent positions assert it as a trust signal regardless of applicability, and this index has recorded the resulting imprecision repeatedly. Declining to overclaim is the correct behaviour.

What replaces it is contractual rather than statutory, and a buyer should look there. The confidentiality obligation covering a complete map of a manufacturer's device software and its known weaknesses is whatever the agreement says, with no regulatory floor beneath it.

One edge case worth resolving before deployment: the device behaviour monitoring product captures telemetry from fielded devices, and whether that stream can incidentally carry patient data is not addressed publicly. If it can, the analysis above changes.

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

Converted from Not Rated, and confirmed by a second differently phrased search using the company's own product names.

No SOC 2 report of either type, no ISO 27001, no HITRUST, no trust centre and no penetration testing statement was retrieved for the company itself. A marketplace listing with a major cloud provider exists, which requires passing that provider's listing process, and that is not a security attestation.

This index has an established finding that none of the cybersecurity vendors it holds publishes an attestation of its own, and this record is the sharpest instance of it. The reason is what the company holds. Across its products it accumulates complete software bills of materials for its customers' devices, the vulnerability findings against them, the remediation status of each, cryptographic provisioning and key management for fielded devices, and behavioural telemetry from those devices in the field.

Stated plainly, that is a consolidated inventory of exactly which weaknesses exist in which medical devices, which of them remain unpatched, and which are deployed where. It is difficult to construct a more attractive target in this sector, and it exists because customers were persuaded to centralise it.

The asymmetry is worth naming without treating it as hypocrisy: the company's entire proposition is that manufacturers should be able to demonstrate their security posture with evidence, and its own posture is not evidenced publicly.

Ask for the attestation, its type and period, and for the incident response and breach notification terms.

Not itself an FDA regulated product, but graded A because regulatory alignment is the entire product proposition and it is executed with unusual precision. The offering maps directly to enforceable obligations: FDA Secure Product Development Framework implementation, SBOM generation and maintenance meeting NTIA minimum elements plus level of support and end-of-support dates per component, per-vulnerability safety and security risk assessments including CISA Known Exploited Vulnerabilities, postmarket monitoring for device lifetime, VEX and VDR reporting, the 12-document requirement for eSTAR submissions, and CISA incident reporting readiness.

The company correctly frames the 2025 shift from guidance to enforceable statutory mandate under Section 524B and the Refuse to Accept policy, and publishes analysis of actual FDA premarket deficiency patterns. Few vendors in this index demonstrate this depth of regulatory literacy, and here it is the substance rather than a compliance claim.

Converted from Not Rated. The prior analysis was correct and the company's own marketing now sharpens it considerably.

No governance framework, model evaluation, validation methodology or third party review was retrieved.

The relevant risk is not demographic bias. It is false negatives, and specifically the suppression of a real vulnerability. If automated technology stack detection concludes that a published vulnerability does not affect a given device, that finding disappears from the manufacturer's view. It does not appear in the remediation queue and it may not appear in a regulatory submission, and the company's own analysis identifies undisclosed vulnerabilities as a leading cause of premarket deficiencies.

What makes this more than a theoretical concern is that suppression is the marketed benefit. The product is sold on minimising false positives through intelligence that detects affected technology stacks, on bulk rescoring of vulnerabilities, and on letting manufacturers focus only on what poses real risk. Every one of those is a reduction in the list, and reducing the list is precisely what customers are paying for. The commercial incentive and the safety risk point in the same direction.

No false negative rate is published, no validation of the suppression logic is described, and nothing states what a manufacturer sees about why a vulnerability was ranked down or excluded.

Ask for the false negative rate, how suppression decisions are surfaced and reversible, and whether a human reviews exclusions before a submission.

Two things carry this grade and both are forms of honesty rather than commitment. The first is structural limitation disclosure: because the input sources are individually named, a customer can work out what the tool cannot know.

A vulnerability absent from the national database or the exploited catalogue is invisible to the assessment, and naming the sources makes that derivable rather than hidden, which is a more durable form of limitation statement than a list of caveats because it survives every product change that does not change the sources. The second is a warning published against the company's own commercial interest.

It notes that while the regulator recommends software bills of materials be shared with customers for transparency, disclosure creates additional attack surface by revealing component details to threat actors, and that manufacturers must weigh that trade off. A compliance tooling vendor flagging the downside of the very recommendation that drives demand for its product is an admission against interest, and this index should credit it. Held at C because nothing is measured or promised.

No accuracy figure for component matching or exploitability assessment was located, no false positive rate, and no warranty, indemnity or remediation commitment. Component matching accuracy is the number that matters here, since a mismatched component means a vulnerability missed or invented. Ask for it, and for source update latency.

EHR integration is irrelevant to this buyer; the meaningful surface is the manufacturer's development toolchain. Helm offers an API and integration options to continuously ingest SBOM updates, supports manual creation and upload, and provides one-click generation of FDA-ready SBOM, VEX and VDR reports, with bulk remediation import across a device portfolio.

Graded B rather than A because no named CI/CD, build system or product lifecycle management integrations were located, and continuous SBOM ingestion in a regulated development environment depends heavily on those connections.

Converted from Not Rated. The integration architecture is documented in detail and the hosting position is not.

What is published is the developer facing side, and it is specific. The platform ingests software bills of materials through an application programming interface, a source control action and a build pipeline extension, so it embeds directly in a manufacturer's development workflow rather than sitting beside it. Bills of materials can also be uploaded or created manually. Exports are standards based, in the two common bill of materials formats plus vulnerability exchange and disclosure reports, with historical snapshots retained for audit. Standards based export matters more than usual here, because it means a manufacturer's own compliance evidence is portable rather than trapped in the tool.

The platform is listed on a major cloud marketplace and described there as deployed on that provider's infrastructure.

What is not published is where anything runs. No region, no tenancy model, no statement of whether customer environments are separated, no subprocessor list, no retention schedule and no backup posture. One ambiguity is worth resolving directly: a marketplace listing can mean software delivered from the vendor's own environment or software deployed into the customer's account, and those are entirely different exposure profiles for data this sensitive.

Ask which of the two applies, in which region, and whether tenancy is isolated.

No pricing published and no pricing basis disclosed; the site routes to a demo request. The natural pricing unit would be per device or per product line under management, which matters because a manufacturer with a broad portfolio faces very different economics than one with a single device, and none of that is public.

Deep within a single well-defined buyer type rather than broad. Serves medical device manufacturers across R&D and engineering, quality and regulatory affairs teams handling 510(k), PMA and De Novo submissions, and product security and risk functions, spanning premarket submission through postmarket lifetime monitoring. The portfolio covers cryptography, SBOM and vulnerability management, and device monitoring.

Graded B rather than A because coverage is confined to the manufacturer side with no health system or clinical deployment, and the index grades it on the same scale as vendors serving multiple settings.