← All 530 filings

Medcrypt (Vidya Murthy)

IndustryStartupFiled October 15, 20261,497 words · 1 attachmentFDA-2026-N-7874-0226
LinkedInX

Themes it raises

8 of the 21 themes in the docket, each with the passage we counted, verbatim.
What makes a function high riskFDA Q1, Q2, Q5
“Q1: Add exposure to untrusted input as a risk dimension. Two devices with identical activity and consequence profiles carry very different risks if only one ingests untrusted content.”
Whether benchmark results prove anythingFDA Q9, Q10, Q16
“FDA already knows from penetration testing that a clean report is useful evidence, not proof of security. A pass rate against a fixed adversarial set has the same limit.”
Security, dependencies and what happens when they failFDA Q1, Q9, Q24
“State that adversarial manipulation (direct and indirect prompt injection, jailbreaking, conversational data extraction, and tool misuse) belongs in the cybersecurity portion of a submission.”
Controlling a device that keeps changingFDA Q22, Q23, Q24, Q25
“Q23: PCCPs should prespecify the evaluation protocol, risk assessment methodology, and acceptance criteria for an upstream model change, not the change itself.”
Devices that plan and take actionsFDA Q26
“Q26: In an agentic device, every tool is a privilege. Expect least-privilege tool permissions, model outputs treated as untrusted before high-consequence actions, human oversight checkpoints enforced by system design rather than model instructions, and tamper-evident logs.”
Records that let investigators reconstruct an eventFDA Q19, Q21, Q24, Q26
“After an incident, proving what didn't happen is only possible if trustworthy records already exist.”
Watching the device after it shipsFDA Q19, Q20
“Include security signals in degradation monitoring, such as suspected injection attempts and unusual tool activity.”
How this fits rules that already existFDA Q8, Q9, Q16, Q25
“Section 524B of the FD&C Act and the premarket cybersecurity guidance expect threat models, security risk assessments, and security testing, and many GenAI devices, especially those calling cloud-hosted models, will be cyber devices.”

FDA questions it names

Questions this filing names by number.

Q1 · The two-axis risk frameworkQ19 · Postmarket performance evaluationQ20 · Machine-based supervisory agentsQ22 · Re-benchmarking after a modificationQ23 · PCCPs for GenAI devicesQ24 · Third-party foundation model changesQ25 · Foundation Model Master FilesQ26 · Agentic devices

Machine-assisted draft, pending human review. The source text and highlighted passages appear below. Read the filing on regulations.gov ↗

The comment as filed

Comment submitted on regulations.gov. Passages we counted are highlighted.

Medcrypt, Inc. is a medical device cybersecurity company. We work with manufacturers on threat modeling, software bills of materials (SBOMs), third-party component risk, and postmarket vulnerability management. We appreciate CDRH’s request for feedback on generative AI-enabled devices.

Our full comments are attached. In short, many of the most serious GenAI failure modes are security failures, and FDA already has strong tools for those. The discussion paper treats adversarial prompting as a benchmark competency and does not otherwise address cybersecurity. We encourage CDRH to extend existing cybersecurity expectations explicitly to GenAI-enabled devices rather than rely on performance benchmarking alone. We focused on three areas:

Adversarial manipulation is a cybersecurity risk, not only a performance attribute (S.2, Q1, Q26). A benchmark is a snapshot, the harm can go well beyond a wrong answer, and indirect injection is an architecture problem that takes threat modeling to find. We recommend a dedicated cybersecurity section in future GenAI guidance.

Third-party foundation model changes are a supply chain problem with existing precedent (Q23-Q25). The SBOM, contract, and technical-control practices manufacturers already use apply directly. PCCPs should prespecify the evaluation protocol and acceptance criteria for an upstream model change, not the change itself.

GenAI postmarket monitoring should build on postmarket cybersecurity practice (Q19, Q20, Q22). Security teams have already worked through signal thresholds, alert volume, and accountability, and guardrail updates that address a new jailbreak should be treated like routine cybersecurity patches.

We would welcome the chance to discuss these points further.

Attachment

Attachment, text extracted from the filed document. Passages we counted are highlighted.

Medcrypt Comment on Docket
FDA-2026-N-7874
Re: Considerations for the Regulation of Generative AI-Enabled Medical Devices, Discussion
Paper and Request for Feedback

Medcrypt, Inc. is a medical device cybersecurity company based in Solana Beach, California.
We work with manufacturers on threat modeling, software bills of materials (SBOMs), third-party
component risk, and postmarket vulnerability management. We focused our comments on three
areas where that work is most relevant:

1.​ Adversarial manipulation is a cybersecurity risk, not only a performance attribute (S.2,
Q1, Q26).
2.​ Third-party foundation model changes are a supply chain problem with existing
precedent (Q23 to Q25).
3.​ GenAI postmarket monitoring should build on postmarket cybersecurity practice (Q19,
Q20, Q22).

1. Adversarial manipulation is a cybersecurity risk (S.2,
Q1, Q26)
The paper rightly calls for testing against prompt injection and adversarial prompting, but treats
these as benchmark competencies scored alongside clinical knowledge. Cybersecurity is not
otherwise addressed. That framing leaves real risk on the table:

●​ A benchmark is a snapshot. FDA already knows from penetration testing that a clean
report is useful evidence, not proof of security. A pass rate against a fixed adversarial set
has the same limit.
Attackers adapt, and new techniques appear after a test set is
frozen.
●​ The harm goes beyond a wrong answer. A successful injection can expose patient
data in the model's context, trigger actions through connected tools, alter records, or
take the device offline. The two-axis framework doesn't capture these outcomes.
●​ Indirect injection is an architecture problem. Malicious instructions can arrive through
documents, EHR fields, retrieved content, or connected systems. Finding those paths
takes threat modeling.

FDA already has the right tools. Section 524B of the FD&C Act and the premarket cybersecurity
guidance expect threat models, security risk assessments, and security testing, and many
GenAI devices, especially those calling cloud-hosted models, will be cyber devices.
FDA's
January 2025 draft guidance on AI-enabled device software functions already treats data
poisoning, model evasion, model inversion, and data leakage as cybersecurity threats. The
GenAI framework should stay consistent with these pre-existing sources.

Recommendations:

●​ State that adversarial manipulation (direct and indirect prompt injection, jailbreaking,
conversational data extraction, and tool misuse) belongs in the cybersecurity portion of a
submission.
S.2 results support, but don't replace, a threat model and security testing.
●​ Add a dedicated cybersecurity section to future GenAI guidance, cross-referencing the
premarket cybersecurity and AI-enabled device software functions guidances.
●​ Q1: Add exposure to untrusted input as a risk dimension. Two devices with identical
activity and consequence profiles carry very different risks if only one ingests untrusted
content.

●​ Q26: In an agentic device, every tool is a privilege. Expect least-privilege tool
permissions, model outputs treated as untrusted before high-consequence actions,
human oversight checkpoints enforced by system design rather than model instructions,
and tamper-evident logs.
After an incident, proving what didn't happen is only possible if
trustworthy records already exist.

2. Foundation model changes are a supply chain problem
(Q23, Q24, Q25)
Q24 describes what our customers deal with every day: a component changes because
someone else changed it. FDA already addresses this through SBOM and postmarket
vulnerability management expectations, and the same lessons apply here as well. Know what
you depend on, get supplier commitments in writing, detect changes yourself, and decide in
advance how you'll evaluate them.

Q24, detecting and responding to upstream changes:

●​ Inventory. Record the model like any component: provider, version or snapshot, hosting,
system prompt and configuration version, fine-tuning, and retrieval sources. CISA's 2026
SBOM minimum elements, developed with 13 international partners, already extend to
AI software and require component hashes, which let a manufacturer prove which model
was running. Such SBOM would define the software baseline supporting the AI system.
As a logical extension and at a higher level, a specific AI-BOM would curate the specific
elements that constitute the complete AI solution, including applied models, used
datasets, security properties, and key performance indicators.
●​ Contracts. The HSCC Joint Security Plan (JSP2) Model Contract Language (MC2)
already sets supplier expectations for vulnerability disclosure, incident reporting, and
SBOM sharing. Model agreements should add advance notice of changes and
retirements, minimum support windows, and change logs.
●​ Technical controls. Pin model versions where possible, run automated regression
against a premarket benchmark subset on a schedule and on any detected change, and
keep a defined rollback path.

Q23: PCCPs should prespecify the evaluation protocol, risk assessment methodology, and
acceptance criteria for an upstream model change, not the change itself.
That's how secure
patching works today. We've helped manufacturers build PCCPs with secure update plans, and
the specific patch is never known in advance. The process for assessing it is.

Q25: FDA's incentive concern matches our experience. Suppliers disclose consistently when
contracts require it and the expected content is standard and cheap to produce. Retirement
dates show why this matters. Most open-source projects never publish end-of-life dates, and
foundation models are retired on far shorter timelines, forcing unplanned changes onto devices
built for infrequent updates. We recommend FDA keep accountability with the manufacturer, as
with SBOMs, and define minimum MAF content that includes version history, retirement dates
and support windows, a red-team testing summary, known classes of injection weakness, and a
coordinated vulnerability disclosure policy.

3. Postmarket monitoring should build on cybersecurity
practice (Q19, Q20, Q22)
Q19: GenAI monitoring will hit the same problems postmarket security teams already know:
signal thresholds, alert volume, subjective decision making (at scale), and accountability. In our
experience, alert volume is often the biggest obstacle, because real issues get missed when
teams are buried in findings that don't apply. Security teams address this with exploitability
statements (VEX) that say whether a known vulnerability actually affects a product. We
recommend FDA:

●​ Encourage manufacturers to fold GenAI monitoring into existing postmarket
cybersecurity processes.
●​ Include security signals in degradation monitoring, such as suspected injection attempts
and unusual tool activity.

●​ Consider a VEX-style statement for documenting whether a newly published jailbreak or
injection technique affects a device as configured.
●​ Expect adversarial test sets to be refreshed. AI is lowering the cost of finding new
attacks. In 2026, attackers reportedly used an AI model to find a previously unknown
authentication flaw, work that until recently required skilled researchers.

Q20: A generative supervisory agent can be manipulated too, possibly by the same content that
compromises the primary model. Supervisory agents belong in the threat model, should be
independent of the primary model where feasible, should be tested regularly with known-bad
inputs, and should write to tamper-evident logs.

Q22: Changes that alter the attack surface, including system prompt changes, should trigger
security re-assessment. And since FDA already treats routine cybersecurity patches as
generally not requiring premarket review, it should confirm the same for guardrail updates that
address a new jailbreak, with re-benchmarking to confirm no clinical regression.

Closing
Many of the most serious GenAI failure modes are security failures, and FDA has already built
strong tools for those. We encourage CDRH to extend them explicitly to GenAI-enabled devices
rather than rely on performance benchmarking alone. We'd welcome the chance to discuss
these points further.

Respectfully submitted,​
Vidya Murthy, COO​
Medcrypt, Inc.

References
●​ FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of
Premarket Submissions.
●​ FDA, Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management
and Marketing Submission Recommendations, draft guidance, January 2025.
●​ FDA, Postmarket Management of Cybersecurity in Medical Devices.
●​ CISA, Minimum Elements for a Software Bill of Materials, 2026 update.
●​ Health Sector Coordinating Council, Medical Device and Health IT Joint Security Plan,
version 2 (JSP2) Model Contract Language (MC2).