Five places a cybersecurity section fails review, followed through one cardiac monitor's 510(k), and what answers each
A wearable cardiac monitor: a patch that records the heart, a phone app that reads it over Bluetooth Low Energy, and a cloud service the clinic signs into. The 510(k) is due next quarter. The regulatory lead has a cybersecurity plan from the consultancy, a threat model, a block diagram, a software bill of materials in a spreadsheet, and a scan report from the last sprint. Every one of them describes the device as designed. The reviewer's questions are about the device as built.
Since October 2023, FDA may refuse to accept a premarket submission for a cyber device on its cybersecurity content alone.[2] The requirement comes from section 524B of the Federal Food, Drug, and Cosmetic Act,[1] and the guidance that says what the submission should contain was reissued on February 3, 2026.[3] This article is not regulatory advice, and the consultancy that wrote the plan should keep owning it. It is the view from the bench where the technical evidence underneath the plan gets made.
The full list of artifacts a reviewer expects is in our 524B evidence checklist. This article follows the five that decide the outcome, starting with why the section can now end the review before it begins.
The monitor is a cyber device three times over. The statute defines one as a device that includes software, can connect to the internet, and has characteristics that could be vulnerable to cybersecurity threats.[1] FDA's illustrative list of what counts as connecting includes cloud services, radio such as Bluetooth Low Energy, and hardware connectors such as USB and serial ports.[3]
For a cyber device, section 524B(b) asks the sponsor for three things: a plan to monitor, identify, and address postmarket vulnerabilities, including coordinated disclosure; processes that give reasonable assurance the device is cybersecure, with patches on a regular cycle and out of cycle for critical vulnerabilities; and a software bill of materials covering commercial, open-source, and off-the-shelf components.[1]
The teeth arrived on a date. FDA's refuse-to-accept policy states that "beginning October 1, 2023, FDA expects that such sponsors will have had sufficient time to prepare premarket submissions that contain information required by section 524B of the FD&C Act, and FDA may RTA premarket submissions that do not."[2] A refusal is not a deficiency letter. The submission is not under review at all until the content is there.
The guidance describing that content was reissued on February 3, 2026, to align with the Quality Management System Regulation. The technical expectations did not change, but the file now has to trace to a controlled quality process rather than sit beside it.[3] On testing, the guidance is direct: cybersecurity controls "require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context."[3]
Requirement → Artifact FDA expects → Deficiency that sinks it → Evidence that answers it
That is the reading order for the five sections that follow. Start with the report most teams already have and believe is enough.
The scan report from the last sprint is what the monitor's file calls its penetration test. It lists open ports and known vulnerabilities by version number, and it was produced by the engineers who wrote the firmware, in an afternoon.
Artifact. The guidance asks that penetration testing "focus on discovering and exploiting security vulnerabilities in the product," and that the report include five elements: "independence and technical expertise of testers; scope of testing; duration of testing; testing methods employed; and test results, findings, and observations."[3] It asks for the original third-party report where one exists, and, for all testing, the manufacturer's "assessment of any findings including rationales for not implementing or deferring any findings to future releases."[3]
Deficiency. A scan discovers. It does not exploit, so it says nothing about what an attacker can do with what it found. A report without the five elements cannot be weighed, and findings with no disposition leave the reviewer to guess whether they were fixed, deferred, or missed.
Evidence. A report written to the five elements, by testers who can state their independence from the developers, with a path for each finding that shows what was reached and how, and the manufacturer's disposition of every finding in the risk file. The guidance gives the reason exploitation matters: "if a penetration tester, for example, was able to exploit a vulnerability, the ability of a threat actor to exploit that vulnerability is likely to increase over the device lifecycle."[3]
A good penetration test finds what an attacker finds. The next deficiency is about proving what the design was supposed to stop.
The monitor's threat model is good. It names Bluetooth Low Energy pairing as the control against a rogue phone and a signed update image as the control against tampered firmware. The test folder holds no test in which an unpaired phone tries to connect, and none in which the device is offered an image with a bad signature.
Artifact. Two of the testing types the guidance names are about exactly this. For security requirements, manufacturers "should provide evidence that each design input requirement was implemented successfully," along with "evidence of their boundary analysis and rationale for their boundary assumptions."[3] For threat mitigation, they "should provide details and evidence of testing that demonstrates effective risk control measures according to the threat models provided in the global system, multi-patient harm, updatability and patchability, and security use case views."[3]
Deficiency. A control that appears in the threat model and nowhere in the test record is a claim. The reviewer has the design input and the assertion that it was met, and nothing in between.
Evidence. One test per control, each attempting the thing the control exists to stop and recording what the device did: the unpaired phone refused, the unsigned image rejected. The guidance's vulnerability-testing list adds what a thorough file also carries: "abuse or misuse cases, malformed and unexpected inputs," fuzz testing, and vulnerability chaining, with the tools and results documented.[3]
Both of those test what the team knew to look for. The third is about what nobody on the team knew was there.
The block diagram has three boxes: patch, phone, cloud. The board has a serial header the contract manufacturer uses to load firmware. The firmware has a maintenance service, left from development, that answers on a fixed credential. Neither is in the diagram, so neither is in the threat model, so neither was tested.
Artifact. The guidance asks for at least four security architecture views: a global system view, a multi-patient harm view, an updateability and patchability view, and security use case views. They should "identify security-relevant medical device system elements and their interfaces" and "define security context, domains, boundaries, critical user roles, and external interfaces of the medical device system."[3] Among the testing it expects are "attack surface analysis," "software composition analysis of binary executable files," and "static and dynamic code analysis, including testing for credentials that are 'hardcoded,' default, easily guessed, and easily compromised."[3]
Deficiency. The views describe the interfaces the design team drew. A serial port is, in FDA's own list, a way of connecting to the internet.[3] An interface the views omit is one the threat model never considered and the tests never touched, and a fixed credential in the image is a finding the guidance names outright.
Evidence. An interface list built from the device rather than the drawing: the firmware image taken apart and every service, port, and credential it exposes enumerated; the board examined for the connectors it carries; and the architecture views corrected to match, so the threat model and the tests cover what ships.
What is in the firmware also decides whether the software bill of materials is true.
The monitor's SBOM is a spreadsheet with forty rows: the operating system, the Bluetooth stack, a TLS library, the app framework, each with a version typed in by hand. It is what the team knows it chose. It is not what the build produced.
Artifact. Section 524B(b)(3) makes the SBOM a statutory requirement.[1] The guidance asks for one consistent with the NTIA minimum elements, in an industry-accepted format, with two things more per component: its "level of support" and its "end-of-support date."[3] It then asks the manufacturer to identify all known vulnerabilities in the device and its components, including those in CISA's Known Exploited Vulnerabilities Catalog, to "describe how the vulnerabilities were discovered to demonstrate whether the assessment methods were sufficiently robust," and to assess the safety and security risk of each.[3]
Deficiency. A spreadsheet has no transitive dependencies, because nobody typed them, no support status, no end-of-support dates, and no vulnerability assessment, so the reviewer cannot tell whether the open vulnerabilities were judged or never looked up. And because it was written from the design and not from the build, it can disagree with the binary that ships, which is why composition analysis of binary executables is on the guidance's list of tests.
Evidence. An SBOM generated from the build in an industry format, with support status and end-of-support recorded per component, a vulnerability assessment for each component that says how it was found, and an SBOM that agrees with the shipped image.
Each of these is a document about the device as designed, checked against the device as built. The last deficiency is the one that turns that gap into a liability.
The cybersecurity summary at the front of the monitor's section says that all communications are encrypted and authenticated. The reviewer looks for the artifact that shows it. There is a line in the threat model, and nothing else.
Artifact. The guidance asks the security risk management report to "provide traceability between the threat model, cybersecurity risk assessment, SBOM, and testing documentation."[3] Every claim in the summary should name an artifact the reviewer can open.
Deficiency. A summary that outruns its file. The threat model says a control exists, the view does not show where, the tests never exercise it, and the summary asserts it anyway. It is the gap the four deficiencies above accumulate into, and the one a reviewer sees first.
It is also no longer only a review problem. On July 31, 2025, the Department of Justice announced that Illumina Inc. agreed to pay $9.8 million to resolve False Claims Act allegations that it sold government agencies genomic sequencing systems with cybersecurity vulnerabilities and "falsely represented that the software on the genomic sequencing systems adhered to cybersecurity standards, including standards of the International Organization for Standardization and National Institute of Standards and Technology."[4] No breach was alleged, and as the Department states, "the claims resolved by the settlement are allegations only and there has been no determination of liability."[4] The point for a device maker is narrower than the case: a written statement about device security is a representation, and one the file cannot support has consequences outside the review.
So here is what the monitor's file looks like when all five are answered.
The penetration test report states who tested, how independent they were, the scope, the duration, the methods, and the findings, with the original third-party report attached and a disposition for each. Each control in the threat model has a test that attacked it and a record of what the device did. The interface list came from the firmware and the board, and the views match it. The SBOM came from the build, with support status, end-of-support dates, and a vulnerability assessment per component. The summary names an artifact for every sentence. The postmarket plan, the disclosure process, and the labeling are in place, and the checklist covers those.
None of this is exotic. It is the difference between a file about the device as designed and a file about the device as built, and the second kind is the one a reviewer can accept.
How independent are you from the people who built it? The guidance asks the report to say so. The answer should be a sentence you can put in the file, not a reassurance.
Do you take the firmware apart, or only test it from the outside? The interfaces and credentials that sink submissions live in the image and on the board, where black-box testing does not look.
Does each control in the threat model get its own test? Ask to see one: the attack attempted, the device's response, and which architecture view it traces to.
Does each finding arrive with the path that reached it and a disposition we can file? A finding without a path cannot be reproduced, and a finding without a disposition is a question the reviewer will ask.
Which of these can you show me? A sample report is evidence. A methodology slide is not.
A cybersecurity plan describes what a device was meant to be. The evidence beneath it shows what the device is. Since October 2023 the second is what gets a submission through the door, and it is the part we are glad to show.
The consultancy that wrote your plan should keep owning it. What sits beneath the plan, the firmware taken apart, the device and its app observed in operation, every interface exercised, and an independent penetration test written to the five elements above, is the work we do, direct or as a white-label subcontract under your consultancy's name. One product line first; judge us on the artifacts. The full list of what a reviewer expects is in our 524B evidence checklist.
Or write to josh@vivasecuris.com.