FD&C Act §524BFDA Final Guidance, Feb 3 2026QMSR
Cybersecurity built by the people who build the instrument software.
FDA now gates clearance on your cybersecurity file. Plenty of firms can write the documents. Fewer understand a diagnostic analyzer. Almost none can change the code. The RND Group does all three — because we have been writing FDA-regulated instrument software for more than 25 years.
- 25+ years of FDA-regulated software development
- In vitro diagnostics and connected instruments
- Software as a Medical Device
- LIS, HL7, and middleware integration
- Cybersecurity quality system in production use
Cybersecurity now decides whether FDA accepts your file.
Three changes did it: a statute that gives FDA refusal authority, a final guidance that names exactly what it wants, and a quality system regulation that pulls all of it into your design controls.
FDA can refuse to accept the submission
Section 524B of the FD&C Act gives FDA explicit authority to refuse to accept a premarket submission for a cyber device that does not meet its cybersecurity requirements: postmarket monitoring, patching, and coordinated vulnerability disclosure under (b)(1); a secure product development framework under (b)(2); and a software bill of materials under (b)(3). This is not a review comment. It is admissibility.
The final guidance is specific about what it wants
FDA’s February 3, 2026 final guidance sets named expectations that a general security report will not satisfy: four security architecture views — global system, multi-patient harm, updateability/patchability, and security use case — each with diagrams and narrative; a consolidated cybersecurity risk management report; traceability running the length of the file; and an SBOM carrying per-component support status and end-of-support dates.
Your quality system is now in scope
With 21 CFR Part 820 incorporating ISO 13485:2016, cybersecurity activities are design controls with records an auditor can ask for. A cybersecurity file assembled once for one submission, outside your QMS, is a finding waiting to happen.
Every documentation requirement has a design requirement underneath it.
This is the part that surprises teams. A deficiency asking you to “provide an updateability view” is usually telling you something harder: that the update path is not signature-verified, not atomic, and cannot roll back. A question about cryptographic rationale usually means the keys live somewhere they should not. A narrow penetration test finding is a real defect in a real interface.
You cannot write your way out of any of those. Somebody has to change the software, verify the change, and land the evidence in the design history file. That is the work we do.
A team hires a security consultancy, gets a thorough report, and files. The response letter comes back asking for depth the report cannot supply, because the report described the device as documented rather than as built. Now the clock is running, the consultancy cannot touch the firmware, and the engineering team that can is mid-sprint on something else.
The cheapest version of this problem is the one you solve before you file.
Three things that are true of us and rare elsewhere.
We are a diagnostics software house first
Not a security firm that added a medical vertical. Our engineers have spent careers on analyzer control software, instrument middleware, LIS interfaces, and SaMD. When we build your threat model, the assets, interfaces, and harm scenarios describe a diagnostic instrument — because we have shipped them.
We close the finding, not just report it
Signed and resumable update paths. Key generation, storage, and rotation that survives a cryptographic rationale review. Hardened LIS and service interfaces. Operator authentication and audit trails that hold up. We write it, verify it, and hand you the evidence — in your codebase, under your design controls.
The quality system already exists
Not a template pack. Working procedures for cybersecurity risk assessment, cybersecurity management, and cybersecurity testing and verification, with a CVSS v4.0 risk assessment workbook, STRIDE threat import, SBOM vulnerability analysis with CISA KEV screening, and a controls catalog typed to FDA’s categories.
Where generalists get diagnostics wrong
A diagnostic instrument is not a small implant with Wi-Fi.
Most medical device cybersecurity practice was built around therapy delivery devices. Apply those assumptions to an analyzer and the threat model describes the wrong device — convincingly enough to pass internal review and not FDA’s.
Four ways to work with us.
Most teams start with whichever one is on fire, then keep going. Each engagement is scoped to a defined artifact list and schedule before any work begins.
Cybersecurity Quality System Framework
A working cyber quality system installed inside your QMS — procedures, templates, the risk assessment workbook, and the training to run it yourselves.
- Cybersecurity risk assessment, management, and verification procedures
- CVSS v4.0 risk workbook with initial and residual scoring
- Adapted to your document numbering and approval workflow
- Gap assessment against the February 2026 guidance
FDA Premarket Cybersecurity Package
The complete submission content, built on your architecture and traceable end to end — assembled the way a reviewer reads it.
- Threat model and all four security architecture views
- Security risk assessment linked into your ISO 14971 file
- SBOM with support status, end-of-support, and KEV screening
- Cybersecurity risk management report and traceability matrix
Deficiency Response & Secure Design
You have a letter, or a finding, or a design that will not survive one. We answer the question and change the software so the answer is true.
- Deficiency triage mapped to §524B subsections and guidance sections
- Secure boot, signed update, rollback, and key management work
- Interface hardening: LIS, service ports, USB, network, cloud
- Verification evidence produced with the fix, not after it
Managed Postmarket Cybersecurity
The obligation that does not end at clearance. Monitoring, triage, disclosure, and patch decisions, run as a standing service against your deployed fleet.
- Continuous SBOM and vulnerability monitoring with KEV triage
- Coordinated vulnerability disclosure intake and response
- Documented patch decisions with safety rationale
- Records that stand up in an audit and in the next submission
What you actually receive.
FDA’s February 2026 guidance names the documentation it expects in a premarket submission. Here is that list against what we produce. Section references are to the guidance.
| FDA-recommended documentation | What we deliver |
|---|---|
| Cybersecurity risk management reportSections V, VI.B | One consolidated, reviewable narrative that ties the threat model, risk assessment, controls, verification results, and residual risk conclusion together — signed, dated, and defensible. This is the document that makes the rest of the file legible to a reviewer. |
| Threat modelSection V.A.1 | STRIDE-per-element analysis built in the Microsoft Threat Modeling Tool against your real architecture, with a written scope statement, asset inventory, stated assumptions, and explicit out-of-scope declarations. Supply chain, deployment, and decommissioning included. |
| Security architecture viewsSection V.B, Appendix 2 | All four views — global system, multi-patient harm, updateability/patchability, and security use case — as diagrams plus explanatory narrative, annotated with trust boundaries, data classification, authentication points, and external interfaces, kept consistent across views and with the threat model. |
| Cybersecurity risk assessmentSection V.A.2 | CVSS v4.0-scored assessment with initial and residual risk per threat, exploitability translated explicitly into probability of harm, acceptability decisions with rationale, and linkage into your ISO 14971 safety risk file rather than running parallel to it. |
| Software bill of materialsSections V.A.4, VI.A | Machine-readable SBOM (CycloneDX or SPDX) with the NTIA minimum elements, transitive dependencies, cloud and companion-app components, plus the two things most SBOMs are missing: per-component level of support and end-of-support date. |
| Vulnerability assessment and software supportSection V.A.4 | Known-vulnerability analysis including CISA KEV screening, a documented discovery method so the assessment reads as robust, and a safety and security impact evaluation per finding with device and system effects. |
| Security requirementsSection V.B.1, Appendix 1 | Security requirements written as verifiable requirements, traced to the threats that motivate them and to the design controls that implement them. |
| TestingSection V.C | Cybersecurity test plan and test summary report covering requirement verification, threat mitigation testing, and vulnerability scanning — plus scoping and management of independent penetration testing across every interface, not just the web tier. |
| Unresolved anomalies assessmentSection V.A.5 | Documented evaluation of every open anomaly at release with a security and safety rationale for shipping it. |
| TraceabilityAcross Sections V.A–VI.A | A matrix that runs requirement → threat → control → verification evidence → residual risk → ISO 14971 harm. The single artifact that most often decides whether a reviewer believes the rest. |
| Measures and metricsSection V.A.6 | The measures FDA expects you to track defined, baselined, and wired into a process that will still be producing them a year after clearance. |
| Cybersecurity labelingSection VI | Security information for operators and hospital or lab IT: network and connectivity assumptions, supported configurations, hardening guidance, SBOM access, backup and recovery, and end-of-support communication. |
| Postmarket plan§524B(b)(1) | Monitoring, coordinated vulnerability disclosure, and patch and update plans that describe a process you can really run — with the intake path, triage timelines, and decision records that make it auditable. |
Documentation breadth scales with device risk. FDA is explicit that a single-interface device needs less than a networked instrument with cloud connectivity and a commercial operating system — we scope to your device, not to a checklist.
How it plugs in
A cybersecurity thread through the development lifecycle.
Aligned to IEC 81001-5-1 and mapped onto your design controls, so every security activity produces a design control output rather than a side file nobody can trace.
Plan
Cybersecurity management plan, scope, roles, and the artifact list for this submission.
Requirements
Security requirements derived from the initial risk assessment and traced from day one.
Design
Threat model and all four architecture views; controls selected and justified.
Implementation
Secure coding, SBOM generation on every build, SAST and dependency analysis.
Verification
Cybersecurity test plan and report, DAST, independent penetration testing, retest of high findings.
Release
Unresolved anomalies assessment, traceability closeout, risk management report.
Postmarket
Monitoring, disclosure intake, patch decisions, SBOM refresh, and the records behind them.
Standards and frameworks we work against
Call us if any of this is true.
If none of it is, you probably do not need us yet — and we will tell you that on the call.
- This is your first submission with cybersecurity in scope, and the internal estimate feels optimistic.
- You have an Additional Information letter or an RTA hold citing cybersecurity, and the clock is running.
- A consultant delivered findings your team cannot implement without pulling engineers off the roadmap.
- Your quality system has no security risk management procedure, and QMSR made that everyone’s problem.
- You are bringing a legacy analyzer forward and nobody is certain what is actually in the software.
- Your threat model was written for a therapy device and your product is a diagnostic system.
- You need the update path signed and validated, and no one currently owns that work.
- Cybersecurity keeps slipping because it belongs to everybody and therefore to nobody.
What we do not do. We do not sell an SBOM or monitoring platform — we integrate the one that fits you, and we will say so when a tool beats a service. We do not do hospital or laboratory network security; that is a different buyer with different problems. And we do not penetration-test our own remediation work. Tester independence matters to reviewers, and it should matter to you.
How an engagement starts.
A first conversation
Thirty minutes with a senior medical device software expert, not a salesperson. We want your architecture, your interfaces, your submission type, and your date. You get a candid read on which artifacts are missing and which ones are going to be hard.
A scoped proposal
A named artifact list, the evidence each one produces, who owns what on both sides, and a schedule that maps to your submission date. No open-ended discovery phase, and no surprises about what “complete” means.
Work inside your quality system
Records land in your design history file under your document control, reviewed and approved through your workflow. When the engagement ends you own the artifacts, the tooling, and the process that produced them.
Questions we get on the first call.
Is our instrument a "cyber device" under Section 524B?
Section 524B applies to a cyber device: broadly, one that includes software validated, installed, or authorized by the sponsor, that has the ability to connect to the internet, and that contains technological characteristics which could be vulnerable to cybersecurity threats. Most modern analyzers, connected instruments, and SaMD products meet that description — including plenty of devices whose teams assumed they did not, because the connection is “only to the LIS” or “only for service.” Applicability is device-specific and worth confirming in writing before you scope a submission.
We already have an ISO 13485 quality system. Do we need separate cybersecurity procedures?
Yes. Security risk management is a distinct process from ISO 14971 safety risk management, because it evaluates threat-driven risk and exploitability rather than probability of failure. FDA expects the two to be separate but linked, with security risk feeding the safety risk file wherever patient harm is possible.
That linkage is where submissions most often come apart: two risk files that disagree with each other, or a security assessment that never translates exploitability into a probability of harm. It is also straightforward to fix if you do it before the file is frozen.
Do you perform the penetration test yourselves?
No, deliberately. We scope it, we hand the tester the threat model and architecture views so the engagement exercises the interfaces that actually matter, we triage the findings against your risk file, and we implement the fixes. We do not test our own remediation work.
A narrow, automated, web-only report from a generalist firm is its own deficiency. Getting the scope and the methodology right up front is most of the value.
Our device is already on the market. Is it too late?
No, and legacy instruments are a large share of this work. The path is a current-state threat model and risk assessment, an SBOM for what is genuinely deployed rather than what the build system thinks is deployed, a vulnerability position with a defensible rationale for what you will and will not patch, and monitoring and disclosure processes that meet the postmarket obligations.
Findings then get prioritized against your real release cadence and the labs that cannot take downtime. Sequencing matters more than volume here.
How is this different from hiring a cybersecurity firm?
A security firm finds problems and documents them, which is genuinely useful right up to the point where something has to change in the product. We are a software engineering company that has built FDA-regulated instrument software for more than 25 years, so we can also do the changing: sign the update path, fix the key management, harden the LIS interface, rework operator authentication and the audit trail.
Findings that never reach the codebase come back as the next submission’s deficiency.
Can you work inside our quality system and our templates?
Yes, and that is usually the right answer. If your QMS already has the procedures, we execute inside them and the records land in your design history file. If it does not, we can bring a cybersecurity quality system framework, adapt it to your numbering and approval workflow, and train your team to run it after we leave — which is the point.
Who does the work?
Senior engineers who have shipped regulated instrument software, working with a regulatory lead. You will meet the people doing the work on the first call, and they stay on the engagement. We would rather scope less and staff it properly than the reverse.
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