Section 524B gave hospitals a baseline to buy against

The week

On December 29, 2022, President Biden signed the Consolidated Appropriations Act, 2023, the spending law that funded the federal government. Inside that very large bill, signed while most of Washington was winding down for the holidays, was a change to hospital security. Section 3305 of the act added a new section 524B to the Federal Food, Drug, and Cosmetic Act, the law under which the US Food and Drug Administration (FDA) oversees medical devices.

Section 524B is about cybersecurity: protecting computer systems from people who want to break in, steal data or disrupt them. It applies to what the law calls “cyber devices.” A device qualifies if it includes software, can connect to the internet and could be vulnerable to cybersecurity threats. That describes a large share of modern hospital equipment, from the pumps that deliver medication to the monitors beside a patient’s bed.

The law placed three obligations on manufacturers submitting such devices for premarket review, the FDA check a new device must pass before it can be sold.

First, manufacturers must provide a plan to monitor, identify and address postmarket vulnerabilities, meaning weaknesses discovered after the device is on the market. A vulnerability is a flaw in software that an attacker could exploit. The plan must include coordinated vulnerability disclosure: an orderly process for outsiders to report a weakness and for the manufacturer to investigate, fix and announce it.

Second, they must maintain processes that give reasonable assurance the device and related systems are secure, including updates and patches. A patch is a software fix.

Third, they must supply a software bill of materials, or SBOM, covering commercial, open-source and off-the-shelf components. An SBOM is an ingredients label for software. Modern devices are assembled from code written by many other companies and communities, and when a flaw turns up in one of those pieces, the SBOM is how anyone can tell quickly whether a particular device contains it.

The requirements took effect 90 days after enactment, at the end of March 2023.

The law did not apply to hospitals. It regulated the companies that make devices, not the organizations that buy and run them. Yet for health systems, it delivered something they had struggled to get on their own: a federal floor they could point to across the negotiating table.

Consider a hospital’s clinical engineering office a few years ago. A team is choosing a new fleet of patient monitors. Clinicians like one model; finance likes another’s price. Someone from the security team asks the vendor three reasonable questions. What software is inside the device? How do we report a problem if we find one? Will you send fixes when weaknesses are discovered? The answers come back vague. The hospital buys the monitors anyway, because there are only a few suppliers and patients need the equipment.

Hospitals had spent years asking device makers for exactly those things: a list of software components, a way to report vulnerabilities and a commitment to ship patches. They rarely had the bargaining power to insist, especially for specialized equipment with few alternatives. Section 524B did not apply to hospitals at all. It set a floor manufacturers had to meet for new submissions, and that changed the negotiation.

The effect showed up at three procurement moments: selecting a new device, contracting for its support, and managing the installed base the law did not touch.

Medical devices are now computers

A generation ago, an infusion pump was mostly a mechanical device with some electronics. Today many of the devices in a hospital are, in effect, specialized computers. An imaging system runs an operating system, the basic software layer, such as Windows or Linux, that every other program sits on. A patient monitor sends readings across the hospital network to a central nursing station. A laboratory analyzer passes results straight into the electronic health record. That connectivity is what makes modern care efficient. It is also what makes these devices worth an attacker’s attention.

Three ideas from the law need some explanation.

Vulnerabilities and patches

Every substantial piece of software has flaws. Some are harmless. Others would let an outsider take control of a system or use it as a stepping stone into the rest of the network. When such a flaw is found, it is called a vulnerability, and the fix is called a patch.

On an office laptop, patching is routine: the update downloads overnight and nobody notices. On a medical device it is harder. The device has been tested and validated to perform a clinical job safely, and changing its software could, in principle, change how it behaves. So hospitals have often been told not to install updates themselves and to wait for the manufacturer. If the manufacturer is slow, or has stopped supporting the product, the weakness simply stays open.

Coordinated vulnerability disclosure

Security researchers, hospital staff and sometimes rival manufacturers find weaknesses in devices. Coordinated vulnerability disclosure is the agreed etiquette for what happens next. There is a published way to report the problem. The manufacturer acknowledges it, investigates, prepares a fix or a workaround, and then tells customers and the public. Without such a process, warnings get lost, or become public before anyone has a remedy.

The software bill of materials

Very little software is written from scratch. A device maker will typically combine its own code with commercial products bought from other vendors, free open-source components maintained by public communities, and off-the-shelf pieces such as the operating system. An SBOM lists those ingredients.

Its value shows up on the day a serious flaw is announced in a widely used component. A hospital with SBOMs on file can search them and know quickly which devices might be affected. A hospital without them has to call each manufacturer and wait.

Section 524B made a postmarket vulnerability plan, secure update processes and an SBOM conditions of getting a new cyber device through FDA’s premarket review. That is the baseline.

A manufacturers’ law on the hospital’s risk register

Section 524B’s obligations fall on manufacturers, and FDA enforces them. Device security still belongs squarely on the hospital CEO’s and board’s own risk register, for four reasons.

• Patient safety. A compromised device is a clinical risk as well as a technology risk. If monitors, pumps or imaging systems must be taken offline, care is delayed or patients are diverted elsewhere.
• Operational continuity. Devices sit on the same networks as scheduling, records and billing systems. A weak device can become the door through which an attacker reaches everything else. Ransomware, malicious software that locks an organization’s files and systems until a payment is made, typically spreads this way, hopping from one foothold to the next.
• Money. Devices are long-lived capital purchases. A device that cannot be patched carries ongoing costs for workarounds and, eventually, early replacement, on top of the risk itself.
• Accountability. When something goes wrong, patients, regulators, insurers and journalists ask what the hospital knew and what it did. “The vendor would not tell us” is a weaker answer when federal law requires the vendor to have the information.

The practical value of 524B to a health system, then, is a reference point. Before it, a hospital asking for an SBOM was asking for a favor. After it, the hospital was asking the manufacturer to share something it had already prepared for its regulator. That shift is subtle, but it is where most of the benefit lives.

Selecting a new device

Before the law, a request for a software bill of materials in a request for proposals often met a refusal, a marketing sheet or a promise to provide one later. Once FDA required an SBOM in premarket submissions for cyber devices, the question shifted from whether a manufacturer had one to whether it would share it.

FDA submissions are not automatically available to buyers, so health systems still had to ask, and some manufacturers asked for nondisclosure terms first. That request is understandable: an ingredients list can help an attacker as well as a defender. A nondisclosure agreement should be treated as a step in the process, not a reason to stop asking.

The paperwork matters less than the process behind it. Strong selection questions ask whether the manufacturer publishes a coordinated vulnerability disclosure policy. They ask how it assesses and tells customers about new vulnerabilities in third-party components, which operating system the device runs, and when support for it ends. They also ask whether the hospital can apply operating system patches itself, or only the manufacturer can.

A manufacturer that built these processes for FDA can answer quickly. Slow or vague answers are a useful signal, and they should lower the score rather than prompt a follow-up meeting.

Scoring matters too. If security answers carry little weight in the evaluation, they will not change outcomes. Health systems that gave security a defined share of the technical score, agreed in advance by clinical engineering, security and supply chain, turned the baseline into an actual criterion.

One pump replacement, two vendors

Suppose a health system is replacing infusion pumps across its hospitals. Before any vendor presents, its evaluation committee agrees that security will be one defined part of the technical score, alongside clinical usability, integration with the health record and service.

Two finalists emerge. Vendor A returns a component list under a short nondisclosure agreement, points to its published disclosure policy, names the operating system and the date support for it ends, and explains which updates the hospital may install itself. Vendor B says an SBOM is “available after purchase” and offers a call with its product team.

Without a scoring rule agreed up front, the committee might treat Vendor B’s answer as a loose end and let price decide. With one, the difference shows in the numbers, and the nurses, engineers and finance staff in the room all signed up to that rule before they knew which vendor it would favor. Fixing the weights early stops the decision from being reopened by whichever answer is most convenient on the day.

Contracting for support

The law requires manufacturers to maintain processes for updates and patches. It sets no service terms between a manufacturer and a particular hospital. That gap belongs in the contract.

Useful clauses are specific. They set a time frame for the manufacturer to assess a newly published vulnerability and tell the customer whether the device is affected. They commit to patches or documented compensating controls for critical issues. They state which party may apply operating system and antivirus updates without voiding the device’s validation. They require a minimum notice period before end of support, and a right to receive updated SBOMs when software changes.

Two of those terms need a gloss. A compensating control is a protective measure that reduces the danger of a weakness when the weakness itself cannot yet be fixed, such as walling the device off from other systems. Validation is the manufacturer’s tested, approved configuration of the device. Manufacturers often say that if a hospital installs its own updates, validation is void and the manufacturer will no longer stand behind the device. That leaves hospitals choosing between staying patched and staying supported. Settling in advance who may install which updates removes that dilemma before it arises.

Sequence matters as much as wording. Device contracts are often negotiated by supply chain and clinical departments, with security consulted late or not at all. Once price is agreed, the buyer’s bargaining power is gone. Bringing security into the requirements stage, with standard contract language that references the manufacturer’s own FDA-facing commitments, made the terms harder to refuse. A manufacturer can hardly argue that it cannot commit to processes it has already described to its regulator.

There is a cost. Security requirements raise manufacturers’ costs, and some of that reaches device prices. What changed is that the baseline became a cost of market entry shared by all manufacturers, rather than an extra that one hospital had to fund alone.

Bid evaluation should then use total cost of ownership, meaning everything the device will cost over its working life rather than the sticker price alone. A cheaper device with a short support horizon and no patch commitments carries later costs: segmentation work, monitoring, early replacement and possible downtime. Those costs land in different budgets, often years later, which is exactly why they are easy to ignore at purchase.

The installed base the law did not touch

The requirements apply to new premarket submissions. Imaging systems, infusion pumps, laboratory analyzers and patient monitors already in service were unaffected. Many run older operating systems and will stay in use for years because they are expensive and clinically trusted. A scanner the radiology department relies on is not replaced because a new law appeared.

For these devices, the hospital’s bargaining power is indirect. Manufacturers building new processes for new products can often extend some of them, such as vulnerability notices and component lists, to current product lines on request. Service contract renewal is the moment to ask, because it is the only time the hospital is paying for something new.

Where a manufacturer will not support an older device, the decision becomes a capital and clinical one. Compensating controls come first: placing devices on dedicated network segments, restricting which systems they can talk to, and monitoring their traffic for anomalies.

Network segmentation means dividing the hospital network into separate zones with controlled doors between them, so that trouble in one zone cannot easily spread to the next. Restricting which systems a device can talk to means, for example, that the monitor may send readings to the nursing station and nothing else. Monitoring traffic means watching for the device behaving out of character, such as suddenly contacting computers it has never spoken to.

A replacement timeline should be agreed by clinical leadership, finance and security together, and recorded in the capital plan with the device’s risk rating attached. Without that record, legacy devices tend to stay in service until they fail or are attacked.

Clinical engineering teams need a practical inventory to do any of this: device model, software version, network location, support status and whether an SBOM is on file. Many hospitals had the first three in a maintenance system and none of the security attributes. Adding them is unglamorous work that makes every later decision faster.

Habits that connect the people involved

A hospital that gets this right does not need a large new program. It needs a handful of habits that connect people who often work apart.

Signs of a mature approach

• Security, clinical engineering and supply chain agree evaluation criteria together, before vendors are invited, and the security share of the score is written down.
• The organization has standard contract language for vulnerability assessment times, patch commitments, update rights, end-of-support notice and updated SBOMs, so each deal does not start from a blank page.
• The device inventory includes security attributes alongside maintenance data, and someone owns keeping it current.
• Older devices that cannot be patched have a named set of compensating controls and a replacement date in the capital plan.
• When a new security warning is published, someone checks the SBOMs on file against it and reports what was found.

Where hospitals slip

• Collecting SBOMs and never reading them. A component list sitting in a shared drive offers comfort, not protection.
• Bringing security in after the price is settled. At that point every security request looks like a late change, and the vendor has little reason to agree.
• Treating vague answers as pending. A follow-up meeting rewards the vendor that was least prepared.
• Assuming the law fixed the old fleet. Equipment bought before the requirements took effect is outside them, and it is often the equipment in greatest need of attention.
• Buying on sticker price. A device with a short support life can be the most expensive option once workarounds and early replacement are counted.

Holding the device program to account

A board member or executive does not need to understand software components to hold the organization to account. These questions are a good start.

1. In our last major device purchase, how much of the score depended on security, and who agreed that weighting?
2. Do we routinely ask for an SBOM and the manufacturer’s vulnerability disclosure policy, and what do we do when a vendor will not provide them?
3. When is security brought into a device purchase: at the requirements stage, or after price is agreed?
4. Which of our connected devices are no longer supported, where do they sit on the network, and what is protecting them?
5. When a serious new security warning is published, who checks our SBOMs against it, and how long does that take?

The questions call for no new legislation or large budget, only for the organization to use a baseline that already exists, at the moments when it still has something to bargain with.

With hindsight

The law set the direction; FDA filled in the detail. FDA issued final guidance on cybersecurity in premarket submissions on September 27, 2023. Its transitional policy of not refusing cyber device submissions that lacked the section 524B information expired on October 1, 2023. From that date a manufacturer could no longer expect FDA to accept an application for review while the cybersecurity material was missing. In June 2025, FDA updated the guidance with a section devoted to 524B.

SBOMs became a standard part of new cyber device submissions. That is a real change in how devices are built and documented, and it happened across the industry at once rather than one contract at a time.

Whether hospitals benefited depended on whether they asked for them. The law gave buyers a reason and a reference point; it did not deliver anything to their door. Systems with strong clinical engineering and security functions could write the new expectations into contracts. Hospitals without that staff had a harder time using the baseline at all. The pattern is an uncomfortable one: a rule designed to raise the floor for everyone helped most those already standing highest.

The installed base remained the durable problem, because the law never reached it. Devices bought before the requirements took effect carry whatever security they shipped with, and because medical equipment stays in service for many years, that gap does not close quickly. It closes through segmentation, monitoring, service contract renewals and capital plans that schedule replacement deliberately rather than waiting for failure.

The baseline itself held: device cybersecurity is now treated as a product quality matter regulated at the manufacturer. A device that cannot be kept secure therefore falls short of a federal expectation, a fair point for a hospital to make in any negotiation.

The gap that remains is use. An SBOM on file helps only if someone matches it against new vulnerability advisories, the public warnings issued when a flaw is discovered. The most valuable step for many organizations is not asking for more documents but assigning a person and a process to read the ones they already have.