FDA cybersecurity, done properly, without holding up your submission.

In scope: every cybersecurity document the eSTAR template asks for, from the architecture views and threat model through to the SBOM, the vulnerability assessment, the pen test, the labeling, and the final security risk management report. Plus answering FDA if they come back with cybersecurity questions.

Not in scope: writing the code. We name the controls, draft them early so your engineers can start, and verify them after, but your team builds them. We also do not cover the rest of your submission, though we can.

Yes. It is part of the job, not a second project you have to scope, buy, and manage.

The threat model drives what gets tested, so it targets what actually worries FDA rather than running a generic checklist, and the findings come back ready for the submission. Retesting after you fix something is covered.

Almost never. We quote the full job whether or not you have a head start.

Everyone asks, and we get why. Your team put real money and months into this. But we tried picking up part-done work for a while, and every time it was slower and more expensive than starting clean.

The effort nearly always went into the software design spec, because that is the document engineers find easiest to write, and FDA barely reads it. The SOPs usually come from a generic template that was never meant for software as a medical device, so we have to fix those first. And we have to work out why your team did what they did, then change it without insulting anyone, which is slow.

It costs more than starting fresh. So we say no to the discount. It is not what anyone wants to hear, but the discount would have cost you more.

Often, yes. A SaMD can usually be shaped so that much less of it falls inside the pen test.

The biggest lever is defining your external connections by an interface contract rather than by one deployment. If the device reads DICOM files from a bind mount and writes a report back out, the PACS, the cloud gateway, and the routing service become external systems rather than parts of the device. Narrowing the device boundary helps too, since software that does not perform a medical device function can often sit outside it.

Most teams do not know how their software will be deployed when they submit. On premise, in the cloud, through an AI marketplace: the market usually settles that later. Threat modeling one setup you are going to change anyway is wasted work, and much of what would have been security controls in that surrounding infrastructure turns into labeling and interface tests.

The catch is that these are design decisions. Raised during architecture they are nearly free. Raised after the software is frozen they are usually gone. Our article Everything Outside the Binary Is a Guess goes deeper.

Because inflating scope is how a cybersecurity specialist grows an account, and we are not one.

Cybersecurity is one of several things we do here. Most of our work is regulatory strategy, submissions, QMS, and software development, often with the same clients over years. Talking you into more security work than your device needs would cost us the next job.

In practice that means we argue for less: a narrower device boundary, fewer controls where the risk does not justify them, documentation scaled to what the device actually is. FDA does not reward a thicker package, and neither do we.

If your device has software, chances are it is a cyber device. FDA reads the term very broadly, and most teams hoping to fall outside it do not.

The main exception we see in practice is firmware on custom hardware with no exposed ports. Almost everything else lands inside, including instruments on a local network with no route to the internet and systems that are air-gapped at launch.

Settle it early rather than assuming either way, but plan on being a cyber device unless you have a specific reason to think otherwise.

Yes, and it is common. We are often brought in as the cybersecurity specialist on a submission somebody else is leading, including by regulatory consultants who send us their own clients for this part.

We work inside your quality system, and the documents drop into the rest of the submission without reformatting. Your consultant keeps the FDA relationship and the plan.

Plan on up to three one-hour meetings a week with engineers who can explain the architecture and the existing controls, plus a guided walkthrough of the code on a screen share.

The bigger commitment is building. We draft the controls early so your team can start while we keep writing, but someone has to write that code, run the manual test protocols, and fix what the pen test finds. That window is the main variable in your real calendar.

Yes, on purpose. Clients have matched our proposal line by line against the eSTAR attachment list, which is fair enough, and we welcome it.

Each document is named and organized to upload straight into the current template. Where eSTAR splits something we deliver as one artifact, we break it out so the mapping is one to one.

It helps, but it is not required.

With access we move faster and ask fewer questions. Without it we need more engineer time in design talks to reach the same understanding, which usually costs more of your team’s hours than it saves in access reviews. A guided screen share is often enough.

We fix them at no extra cost. That is the guarantee, and it is in writing.

On top of that, part of the fee is not due until FDA responds without major cybersecurity deficiencies. If major ones do come back, that payment waits until the submission goes through, or until it fails for reasons unrelated to cybersecurity. We are paid in full when the work has done its job.

Not the whole package. FDA spells out a subset of the cybersecurity documentation that an IDE requires, which is meaningfully less than what a marketing submission needs. We scope to that subset when the IDE is what you are working toward.

Nothing to buy. The right tool depends on your stack, and we have built SBOMs by hand where no good automated option existed.

For ongoing work we usually suggest off-the-shelf vulnerability monitoring such as Dependabot or Snyk, both with usable free tiers, and we can set up your CI/CD to emit an FDA-compatible SBOM on every build so it never goes stale.

One scoping note: your SBOM should cover the whole deployed artifact, including system libraries in the container, not just your own dependencies. Narrow SBOMs are a steady source of FDA questions.

We almost always work inside your quality system, and we bring our own cybersecurity SOP.

If you do not have one of your own, which is common, we can hand ours over for you to adopt, or build it into your QMS as separate work. We can also supply resumes for everyone on the project, since most supplier controls procedures ask for them.

Expect to. FDA usually recommends an annual pen test retest, and we have sometimes negotiated every two years depending on the device and how fast it changes.

This is an ongoing cost whoever you work with, so it belongs in your operating budget, not your submission budget. We automate the test where we can, which makes each later round faster and cheaper than the first.

Remediation is the biggest of four. The others:

Scoping. Where the device boundary is genuinely unsettled, we do a short paid review of your architecture and existing documents first, so the scope is built on something real rather than a guess.

Support. For teams still building. We work with your engineers during design so the controls are built in rather than retrofitted, and the documents pile up as you go. Cheaper over the life of the program, and only open to you if you start early enough.

AINN and hold letter response. You submitted, FDA came back with cybersecurity deficiencies, and you have a clock. We scope what closes the letter and write the response.

All four are sold on their own. You do not need to buy a regulatory strategy engagement to get cybersecurity work from us, and we will not try to turn a small one into a large one. We also do the rest: regulatory strategy, submissions, QMS, and software development. Plenty of clients start here and bring us the next thing, which is a better outcome for us than padding this one.

A fair question, and we use these tools ourselves.

Models are good at telling you what the guidance says. What they cannot tell you is how a review division has behaved lately: which architecture choices shrink the scope, what reviewers ask for beyond the written requirement, where the unwritten expectations sit. None of that is published.

The other half is doing it. Knowing the document list does not produce a defensible threat model, a pen test FDA will accept, or a traceable risk assessment. That is the part FDA reviews.

When the device is hardware-first and the software is incidental. We do not take on implantables, catheters, surgical instruments, orthopedic hardware, or the electrical and mechanical work on capital equipment. We work on combination products where the software is the substance of the device, and we partner for the hardware.

When the problem is an end-of-life operating system on complex electromechanical equipment. We have handled that as a letter-to-file question, not as the center of a first submission, and we will say so and point you to someone better placed rather than learn on your schedule.

When you need CE Mark or other non-US submissions as the main goal. We are a US FDA firm.

When you want a light review or hourly consulting. We add the most value when we are playing a major role, so if you want a second set of eyes, we are not the right fit.