Service — Fix what is broken
You have a letter. The clock is running. Most of the answer is engineering.
A cybersecurity deficiency is rarely a writing problem. When FDA asks for an updateability view, the real question is usually whether the update path is signed, atomic, and recoverable. We answer the question and change the software so the answer is true — then produce the verification evidence with it.
First: separate the writing from the building.
Some deficiencies are genuinely documentation — the control exists, the evidence exists, nobody connected them. Others are telling you the product does not do what the file claims. Those two need completely different plans, and confusing them is how teams burn the first month.
Documentation and traceability
The design is defensible; the file does not show it. Missing architecture views, no written translation from exploitability to probability of harm, a controls catalog with no verification references, an SBOM without support status, security requirements that were never written down as requirements.
Plan: reconstruct properly, trace it end to end, and be candid in the response about what is new analysis versus new evidence. Weeks, not months.
Design and implementation
The reviewer has found a real gap. The update path is unsigned or cannot roll back. Keys are stored where they should not be. A service interface has no authentication. The operating system is past support with no plan. A penetration test found something that reproduces.
Plan: engineer the fix, verify it, and document both. This is the work most cybersecurity consultancies cannot do, which is why it is the work most often deferred into the next letter.
The first week
- Read every discrete finding in the letter, separately — a numbered item often contains two or three distinct asks
- Categorize each against the statute: §524B(b)(1) postmarket monitoring, patching, and disclosure; (b)(2) secure product development framework; (b)(3) SBOM
- Map each finding to the guidance section that drives it, so the response can cite the same ground the reviewer is standing on
- Sort into Category A and Category B, and size the Category B engineering honestly
- Confirm the device meets the cyber device definition — occasionally the productive answer is a scoping argument
- Work backward from the response deadline to a dated plan with owners
Do not answer only what was asked. A reviewer who found one missing architecture view will look at the others. A response that fixes the cited item and leaves adjacent gaps untouched frequently produces a second letter, and the second one costs more than the first because the schedule has already moved.
Do not answer a design question with prose. If the update path cannot roll back, no amount of careful wording makes the updateability view correct. Reviewers read the file as a whole and inconsistency is the thing they are best at finding.
What almost nobody else in this market does
The engineering work, in your codebase.
We have been writing FDA-regulated instrument software for more than 25 years. When remediation means changing the product, the same team that found the problem can close it — under your design controls, with the verification evidence produced alongside the change rather than chased down afterward.
Secure boot and software integrity
Chain of trust from boot through application load, integrity verification, and tamper response. Documented so the updateability and global system views describe something real.
Signed, atomic, recoverable update
Signature verification, integrity checks, atomic installation, rollback, resumption after interruption, and failure handling — then tested as part of system verification, including the failure cases everyone skips.
Cryptography and key management
Algorithm and key-size selection you can defend against current standards. Key generation, storage, rotation, and destruction. Crypto-agility, so a fifteen-year instrument can move off an algorithm that ages out mid-life.
Interface hardening
LIS and middleware interfaces, service and diagnostic ports, USB and export paths, network services, wireless, and cloud APIs. Authentication, input validation, transport protection, and removal of the things that were only ever there for the factory.
Authentication, roles, and audit
Operator and service roles, credential handling, session management, and an audit trail that holds up as a regulated record — without breaking how a lab actually works at three in the morning.
Result and data integrity
The one that matters most on a diagnostic system: protecting sample identity, calibration and quality control state, and the result path from the measurement through the middleware to the LIS.
Platform and OS support tail
Hardening the instrument controller, dealing honestly with a commercial operating system past support, and building a defensible position on what gets patched, what gets compensated, and when.
Logging and detection
Security-relevant events captured, retained, and retrievable — enough to support incident response and postmarket investigation without turning the instrument into a SIEM.
Decommissioning and data handling
Sanitization at end of life, service-swap and return-to-vendor handling, and the parts of the lifecycle that threat models routinely stop short of.
Every change lands as a controlled change. Requirement, design record, code review, verification protocol and result, risk file update, traceability entry. That is not overhead we add — it is the only version of the work that is worth anything to your submission.
Assembling the response.
A deficiency response is a persuasive document with a technical file attached. Both halves have to work.
- Point-by-point response, one section per discrete finding, in the reviewer’s numbering
- Each answer states what changed, points to the evidence, and cites the guidance section it satisfies
- New and revised artifacts: architecture views, threat model updates, rescored risk assessment, regenerated SBOM, verification protocols and results
- Traceability updated so the reviewer can walk the new chain without asking again
- Adjacent gaps closed proactively, and flagged as such — volunteering a fix reads very differently from being caught
- Formatted and section-mapped for eSTAR, with your regulatory lead owning the filing
- An internal dry run before submission: someone who has not touched the work reads it as a reviewer would
- Postmarket processes confirmed live, not planned, before the device reaches the market
Tone matters more than teams expect. The response should concede what is genuinely a gap, defend what is genuinely defensible, and never blur the two. Reviewers are experienced readers. A response that argues everything is as suspicious as one that concedes everything.
Before the letter
Or have someone try to break the file first.
If you have not filed yet, the cheapest version of this service is a pressure test. We read your cybersecurity file the way a reviewer would, against the February 2026 guidance and §524B, and tell you what we would send back.
- Are all four architecture views present, and at Appendix 2 depth?
- Do the trust boundaries agree across views and with the threat model?
- Does the security risk assessment feed the ISO 14971 file, or run beside it?
- Is exploitability translated into probability of harm, in writing?
- Does the SBOM carry support status and end-of-support per component?
- Is there a documented discovery method for known vulnerabilities, including KEV screening?
- Can any threat be walked to verification evidence without leaving the file?
- Was the update path actually validated, failure cases included?
- Is the cryptographic rationale defended or merely asserted?
- Does the penetration test cover every interface, white-box, with retest of high findings?
- Are the postmarket and disclosure processes real, or aspirational?
Questions when a letter is on the table.
How fast can you start?
Triage first, and quickly — reading the letter and sizing the work is a short exercise, and it is the input every other decision depends on. Full engagements are staffed against the response deadline. Tell us the date on the letter on the first call and we will be straight with you about whether it is achievable, including if the answer is that it is not.
Can you work with the consultant who wrote the original file?
Yes, and it is often the fastest path — they have context we would otherwise rebuild. We tend to take the engineering half and the traceability, and leave the regulatory relationship where it already sits. What we will not do is quietly paper over a design gap to avoid an awkward conversation.
What if we disagree with the deficiency?
Sometimes that is the right position, and a well-argued scoping or applicability response is legitimate. It has to be genuinely well argued: grounded in the statute and the guidance, specific about your architecture, and honest about what your device does. We will help you build that case where it is real, and tell you when it is not — a weak argument costs a full review cycle and some credibility.
Do you fix the code, or tell us what to fix?
Either. Some teams want us in the codebase; some want a specification, a design review, and their own engineers doing the work with us reviewing. Both produce the same evidence. The second is often better long term, because your team ends up owning the security-critical code.
Will the fix require new verification and validation?
Almost always, and that is usually where the schedule actually goes — not the code. We scope the verification with the change so it is in the plan from the start, and we look for fixes that are surgical enough to keep the regression surface small. On a released product we also work through the change-control and, where relevant, the reportability question with your regulatory team before anything ships.
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