Service — Get through review
The cybersecurity content of your submission, built to be read by a reviewer.
510(k), De Novo, PMA, or IDE. A complete artifact set derived from your actual architecture, traceable end to end, and written so a reviewer can follow the argument from a threat to the evidence that it was controlled.
Cybersecurity deficiencies are boringly predictable.
Which is good news: nearly all of them are avoidable before you file. These are the patterns FDA’s February 2026 guidance is most specific about, and therefore the ones a reviewer is most likely to hold you to.
One block diagram where four views belong
The guidance asks for a global system view, a multi-patient harm view, an updateability/patchability view, and security use case views — diagrams and explanatory narrative, with trust boundaries, data classification, and authentication points annotated. A single architecture figure lifted from the design document does not answer it.
Two risk files that disagree
A security risk assessment running parallel to the ISO 14971 file instead of feeding it, with no written translation from exploitability to probability of harm, and residual risk stated inconsistently between the two. Reviewers read both.
An SBOM that is only an inventory
Machine-readable and complete, but missing the two elements the guidance calls out beyond the NTIA minimums: level of support per component and end-of-support date. Often missing transitive dependencies, cloud back-end components, and companion app components as well — plus any account of how known vulnerabilities were discovered.
No traceability spine
Every artifact present, none of them connected. Nothing runs requirement → threat → control → verification evidence → residual risk → harm. This is the single artifact that most determines whether a reviewer believes the rest of the file.
An update path that was never validated
The device can be updated, but nothing demonstrates signature verification, integrity checking, atomic installation, rollback, and failure handling in the field. Updateability is a required architecture view and a core postmarket control, so this one gets found twice.
Cryptography asserted rather than justified
Algorithms and key sizes are named but not defended: no rationale against current standards, no account of where keys are generated, stored, rotated, and destroyed, and no plan for moving off an algorithm that ages out during a fifteen-year instrument lifetime.
An Additional Information letter puts your submission on hold while you assemble what should have been in it. The cost is rarely the consulting fee — it is a delayed launch, a revenue plan that moves, and an engineering team pulled off the next product to answer questions about the last one.
The artifact most often underbuilt
All four security architecture views, at the depth the guidance asks for.
FDA is unusually specific here, and Appendix 2 of the guidance sets the level of detail. Each view must identify security-relevant elements and their interfaces, define security context, domains, boundaries, and critical user roles, align to your security objectives, and trace back to security requirements.
Views must stay consistent with each other, with the threat model, and with your design documentation — a trust boundary that moves between diagrams is a finding. Where a view genuinely does not apply to your device, the guidance allows you to leave it out and explain why. We write that explanation rather than padding the file.
The full artifact set.
Scoped to your device — documentation breadth scales with cybersecurity risk, and FDA says so explicitly. A single-interface product does not need what a networked instrument with cloud services needs.
Analysis and design
- Cybersecurity management plan: scope, roles, activities, and the artifact list for this submission
- Threat model — STRIDE per element in the Microsoft Threat Modeling Tool, with scope statement, asset inventory, stated assumptions, and explicit exclusions
- Threat coverage for supply chain, deployment, service, and decommissioning — not just runtime
- All four security architecture views, diagrams plus narrative
- Security requirements written to be verifiable, traced to the threats that motivate them
- Controls catalog typed to FDA’s categories, each control with an implementation reference and verification evidence
- Cryptographic rationale: algorithm and key-size justification, key lifecycle, and crypto-agility plan
Risk, evidence, and closeout
- Cybersecurity risk assessment scored in CVSS v4.0, initial and residual, with exploitability translated to probability of harm
- Linkage into your ISO 14971 risk file, with acceptability decisions and benefit-risk rationale where needed
- Machine-readable SBOM in CycloneDX or SPDX with NTIA minimum elements, transitive dependencies, cloud and companion components, support status, and end-of-support dates
- Vulnerability assessment with CISA KEV screening, documented discovery method, and safety and security impact per finding
- Cybersecurity test plan and test summary report
- Penetration test scoping, tester management, threat-model handoff, finding triage, and retest of high and critical findings
- Unresolved anomalies assessment with security rationale at release
- Traceability matrix across the whole file
- Measures and metrics, defined and baselined
- Cybersecurity labeling and customer security documentation
- Postmarket monitoring, patching, and coordinated vulnerability disclosure plans per §524B(b)(1)
- Consolidated cybersecurity risk management report
The spine
Traceability is what makes the file credible.
Any competent team can produce the individual documents. The submissions that clear cleanly are the ones where a reviewer can pick any threat and walk it to the evidence without leaving the file.
- Security requirement — verifiable, and owned by a design control
- Threat — the STRIDE entry that motivates the requirement, on the element it applies to
- Control — what was implemented, where, and why that control was chosen
- Verification — the test, the result, the record, the date
- Residual risk — scored after the control, with the acceptability decision
- Patient harm — the ISO 14971 hazard the residual risk connects to
Built as the work happens, not reconstructed afterward. Reconstructed traceability has a texture reviewers recognize: controls that map to nothing, tests that verify requirements nobody wrote, and residual risk that appears without a scoring step.
How the engagement runs.
Roughly sequential, substantially overlapped. The order matters more than the calendar: the threat model gates the architecture views, the views gate the risk assessment, and the risk assessment gates what is worth testing.
Architecture immersion
We learn your device properly — interfaces, middleware, deployment, service model, operating system support tail, and how the lab or clinic really uses it. Design documents plus engineer conversations. Assumptions get written down here so they can be challenged.
Model and views
Threat model and the four architecture views, developed together so trust boundaries stay consistent. Reviewed with your engineers, because the fastest way to a wrong model is to build it from documentation alone.
Risk and evidence
Scored risk assessment, controls catalog, SBOM and vulnerability analysis, security requirements, test plan. Findings that need engineering work get flagged now, while there is still time to fix rather than justify.
Verification and assembly
Test execution and summary report, penetration test management and retest, unresolved anomalies, traceability closeout, and the consolidated risk management report — formatted and mapped to the submission sections your regulatory team is filling.
Start earlier than feels necessary
The cybersecurity file is not a document you write at the end. The threat model changes the design, the architecture views expose interfaces nobody had inventoried, and the risk assessment routinely surfaces work the engineering team needs weeks to do — a signed update path, a key management change, a hardened service interface.
Teams that engage during design spend the effort once. Teams that engage at filing spend it twice, and the second time is on the FDA’s clock rather than theirs.
Pre-submission and Q-submission support. If there is a genuine question about scope, applicability, or how far a view needs to go for your architecture, the cheapest place to resolve it is with FDA before you file. We help frame the question, draft the supporting material, and translate the response into the file.
Working alongside your regulatory team. We produce the cybersecurity content and map it to the submission structure. Your regulatory lead owns the filing and the correspondence. Nobody wants two organizations both believing they own the submission.
Questions about premarket work.
How early should we bring you in?
Design phase, if you have the choice. The threat model and architecture views routinely surface design work — a signed update path, key storage that has to move, an interface that needs authentication it does not have. Discovering that during design is a sprint. Discovering it at filing is a schedule change; discovering it in a deficiency letter is a schedule change on someone else’s clock.
That said, most engagements start later than that, and the work still gets done. We would just rather you knew the tradeoff.
Can you use our existing threat model?
Often, yes. We assess it first: scope statement, asset inventory, whether STRIDE or a comparable methodology was applied per element, whether trust boundaries are consistent, and whether the harm scenarios describe your device rather than a generic one. If it is sound we extend it. If it was written for a therapy device and your product is a diagnostic system, we will say so — that is a rebuild, and pretending otherwise costs you more later.
Do you write the submission itself?
We produce the cybersecurity content and map it to the submission sections it belongs in, so your regulatory team can drop it into the filing. We do not take over the filing or the FDA correspondence. If you need that too, we will work with your regulatory consultant rather than duplicating them.
What if the risk assessment finds something serious?
Then you have found it at the cheapest possible moment. We will tell you plainly, score it, and lay out the options: engineer the fix, apply a compensating control with a documented rationale, or accept the residual risk with a benefit-risk justification. All three are legitimate outcomes if they are argued properly. What is not legitimate is a file that does not mention it.
If you want the fix built, that is our secure design and remediation work — same engineers, same codebase.
Our device uses AI or machine learning. Does that change the package?
It adds to it. Model integrity, training and inference data protection, the boundary between the model and the rest of the system, and how a predetermined change control plan interacts with your security controls all need to be addressed explicitly. We scope those items in rather than treating the model as just another software component.
How do you handle the penetration test?
We scope it against the threat model so it exercises every interface — firmware, hardware, wireless, service ports, USB, APIs, middleware, cloud — using a white-box methodology rather than an external scan. We hand the tester the model and the views, then triage findings into your risk file and implement the fixes. We do not test our own remediation work; independence is part of what makes the report worth submitting.
Start with a conversation about your device.
Thirty minutes with a senior medical device software expert who understands both the regulatory requirements and the business realities of bringing software to market. Bring your architecture, your submission type, and your timeline. You will leave knowing which artifacts you are missing and what it takes to close them.
- Submission type and target date — 510(k), De Novo, PMA, IDE, or a postmarket change
- A block diagram or architecture sketch, however rough
- Your interface list: network, LIS, USB, wireless, cloud, service ports
- Whatever cybersecurity documentation exists today, including nothing at all
- Any FDA correspondence you have already received