How hospitals spent the OpenSSL week waiting for ‘not affected’

The week

On October 25, 2022, the OpenSSL project announced that it would release a fix on November 1 for a vulnerability it rated critical. Most security emergencies arrive without warning; this one came with a countdown. The flaw affected only OpenSSL 3.0, a version released in September 2021.

The notice was brief by design. It named the version to be released, 3.0.7, gave a release window of 1300 to 1700 UTC on November 1, and said the highest severity issue fixed was critical. It gave no technical details. The project’s practice is to pre-announce serious fixes so that operators can line up people and change windows, while withholding anything an attacker could use before a patch exists. Under its security policy, critical is reserved for flaws where remote code execution is considered likely in common situations. The label alone told every security team to take the week seriously.

The rating carried extra weight because of history. In 2014 Heartbleed, an OpenSSL flaw that let attackers read server memory and potentially steal private keys, forced organizations worldwide to patch systems and replace certificates. Commentators reached for that comparison within hours of the notice.

OpenSSL is not a product most executives have heard of, but they use it constantly. It is a cryptographic library: a ready-made bundle of code that software developers include in their own products to handle encryption. When a browser shows a padlock, or a device sends data securely across a network, a library like OpenSSL is often doing the math. It is among the most widely used of these libraries, embedded in operating systems, applications, network devices and medical equipment.

So when its maintainers said “a serious flaw is coming, details in a week,” every organization running software had to work out whether any of its products contained the affected version.

Version 3.0 was young, but it had already reached important places. Several mainstream Linux distributions released in 2022, including Ubuntu 22.04 and Red Hat Enterprise Linux 9, shipped it as their system library. Node.js 18, a widely used platform for web applications, bundled it too. Anything built on those foundations in the previous year was a candidate.

The advance notice set off a week of inventory work across hospitals, banks and government agencies. Security teams searched their servers. Developers checked their code. And procurement and clinical engineering teams started emailing suppliers to ask whether their products contained OpenSSL 3.0.

National agencies tried to shorten the work. On October 31 the Dutch National Cyber Security Centre, NCSC-NL, told organizations to prepare for the update. It pointed them to a public list on GitHub, maintained with partners, of products and whether they used a vulnerable version. Vendors and volunteers updated it through the week. It was a crowd-sourced substitute for the structured supplier statements that most products did not yet provide.

On November 1 the project released version 3.0.7, fixing two buffer overflows in certificate verification, tracked as CVE-2022-3602 and CVE-2022-3786. A buffer overflow is a programming error in which software writes more data into a space than the space can hold, spilling into neighboring memory. In the worst case, an attacker can use the spill to run their own code. Certificate verification is the step where software checks the digital credentials another system presents.

The advisory filled in the detail. The first flaw had been reported privately on October 17 and allowed a four-byte overflow. The second, found by the project on October 18 while studying the first, allowed an overflow of any length. It could write only a single fixed character, so the expected impact was a crash rather than takeover. Both sat in the code that checks email address constraints in certificates. Both triggered only after the certificate chain’s signatures had been checked. That meant an attack needed either a certificate signed by a certificate authority the victim trusted, or an application that kept verifying after failing to find a trusted issuer.

The project also downgraded the severity to high, explaining that exploitation conditions and common platform protections made remote code execution, an attacker taking control of a system from afar, less likely than first feared. It said any OpenSSL 3.0 application that verified certificates from untrusted sources should be considered vulnerable, which included TLS clients and servers that asked clients for certificates. Unlike Heartbleed, servers did not need new certificates. The separately validated FIPS module was not affected, and no working exploit was known.

Systems running the still-common OpenSSL 1.1.1 were not affected. For many organizations, the week ended with relief. For hospitals, it also ended with an uncomfortable discovery about how hard it was to get a simple answer.

Log4Shell had shown that finding a vulnerable component is a search problem before it is a patching problem, and Spring4Shell had tested whether hospital teams could triage without panic. The OpenSSL week was a cleaner experiment. The project gave seven days’ notice and an exact scope: version 3.0 only. Hospitals could search their own servers and code quickly. The hard part was everything they did not build: commercial applications, appliances, cloud services and medical devices. For those, the answer most of them needed was a supplier saying, credibly, that the product was not affected.

Most suppliers were not affected, because 1.1.1 was far more common in shipped products. That made the negative answer the bottleneck. A health system with hundreds of suppliers needed hundreds of statements, most of them reassuring, before it could focus on the few that mattered. Three things decided how fast that happened: knowing whom to ask, getting answers in a form that could be processed, and having a rule for suppliers who stayed silent.

The sections below first explain why a single library reaches so far into a hospital, then take those three things in turn. They close with how a prepared organization runs such a week, what it means for a board, and how to test readiness before the next one.

Why one small library touches so much of a hospital

Modern software is assembled more than it is written. A developer building, say, an infusion pump’s network module or a patient portal does not write encryption from scratch. They pull in a library like OpenSSL, alongside dozens or hundreds of other ready-made components. Those components often pull in components of their own. The result is a product that looks like a single thing from the outside but is, inside, a stack of parts from many sources.

That has a practical consequence. When a flaw is found in one widely used part, it may be present in thousands of finished products, and the people who own those products usually cannot see inside them. A hospital can look inside the servers and software it runs itself. It cannot easily open up a commercial imaging system, a cloud scheduling service or a bedside monitor and check which version of OpenSSL is in there.

Hospitals are especially exposed to this problem for three reasons. They run an unusually large number of products from an unusually large number of suppliers: clinical systems, billing systems, laboratory instruments, pharmacy cabinets, building controls. Many of those products are medical devices that cannot simply be scanned or patched, because poking at them with security tools can disrupt their operation and because changes may need the manufacturer’s involvement. And the consequences of disruption cannot be counted in money alone. A device taken offline as a precaution may be a device a nurse needs.

A vulnerability is a weakness that an attacker could use. Each publicly known one gets a CVE number, a catalog identifier that lets everyone refer to the same flaw unambiguously. A patch is the fix. In a perfect world, a hospital would know which products contain the vulnerable component, apply the patch where it can, and protect the rest some other way. In the real world, the first step, knowing, is where most of the time goes.

How the library gets into a product

The way a product includes OpenSSL decides who can fix it. Some software uses the copy that comes with the operating system. On a server running a 2022 Linux release, updating the operating system’s package fixes every application that relies on it. The hospital’s own server team can do that.

Other software carries its own copy. A developer may compile the library directly into the program, a practice called static linking, or ship it alongside the program in its own folder. Container images, the packaged environments many modern applications run in, bring their own operating system files, including their own OpenSSL. Patching the host server does nothing for a container image built months earlier. In each of these cases only the supplier, or whoever builds the image, can produce a fixed version.

Scanners see these cases unevenly. A scan that asks the operating system which packages are installed will find the system copy and miss a statically linked one. A scan that looks inside files for version strings will find more, with more false alarms. For a sealed appliance or a medical device, neither kind of scan is usually allowed. That is why the supplier’s statement mattered so much more for bought products than for built ones.

Why the version number decided so much

The flaw lived only in a branch of the library that was about a year old. Products follow long cycles: a supplier picks a library version, builds and tests a release, and ships it. Medical device makers add verification and, for many products, regulatory submissions. A bedside device certified in 2019 or 2020 would almost certainly carry an older branch.

That produced an odd result. The slow-moving, older parts of a hospital’s fleet were the likeliest to be safe this time, and the newest servers, containers and web platforms were the likeliest to be affected. Teams that assumed the oldest equipment was the riskiest had to reverse that instinct for a week. The version question was also exactly the question hospital records were worst at answering: inventories usually record the product and model, rarely the components inside.

What the flaw needed in order to work

The advisory described a narrow path. Software had to verify a certificate from a source it did not control, and the malicious certificate had to clear the signature checks first. In everyday terms, two kinds of system were exposed. One was software acting as a client, connecting outward to servers an attacker might run. The other was servers that asked connecting clients to present certificates of their own, a setup called mutual TLS.

Hospitals use both patterns. Clinical and business systems call out to payer portals, cloud services and update servers. Some device gateways, integration engines and partner connections authenticate each side with certificates. A product sitting behind the firewall and accepting only ordinary web traffic, without asking for client certificates, was much harder to reach. Mapping that path would later shape the silence rule described below.

Knowing whom to ask

A question cannot be sent without a recipient. Many health systems found that their supplier records named a sales contact or a support portal, not a security team. Medical device inventories often listed manufacturer and model but not the software version or the security contact. Some products had reached the hospital through resellers or as part of larger systems, so the actual producer was not recorded at all.

Suppose that on the morning of October 26 a health system’s security lead asks for a list of every supplier whose product might contain OpenSSL. The procurement database returns invoices and account managers. The clinical engineering database returns device models and service dates. Nobody can say, for the patient monitoring system bought through a distributor years ago, who at the manufacturer handles security questions. By the time the right people are found, half the week is gone.

Where the records live, and why they disagree

Each record was built for a different job. Procurement tracks contracts and spending, so it knows the legal entity that sends invoices. The IT asset database, or configuration management database, tracks servers and applications, so it knows hostnames and owners. Clinical engineering tracks devices in a maintenance system built around inspections, repairs and recalls. Departments that bought cloud tools on a credit card may appear in none of them.

No single one of these systems was designed to answer which products contain a given component and who can say so. Joining them takes judgment: matching a vendor name on an invoice to a manufacturer on a device record, or a hosted service to the company that actually runs it. That joining work is what consumed the days.

The fix is a supplier security contact map, maintained like any other critical register. For each product it records the producer, the version in use, where the producer publishes security advisories and who to contact when no advisory appears. Clinical engineering should own the device portion, since it already tracks service contracts and recalls. The map also needs a notification subscription for each supplier’s advisory feed, so statements arrive without being chased.

Building the map without a large project

Few hospitals can stop to build a complete register. A workable start uses lists they already hold. Business associate agreements, which HIPAA requires with vendors that handle protected health information on a covered entity’s behalf, give a near-complete list of software and service suppliers that touch patient data. Accounts that let vendors connect in for remote support show which suppliers maintain systems inside the network. Firewall and proxy logs show which outside services clinical systems call. Many device makers already provide the Manufacturer Disclosure Statement for Medical Device Security, the MDS2 form, which hospitals collect during purchasing and which records security features and contact points.

Sequence matters more than completeness. The first pass should cover products that are clinically critical, exposed to outside networks or both. A health system that can name the security contact for its top systems by criticality and exposure has covered most of the risk, even if the long tail of departmental tools remains thin.

Cloud and software-as-a-service suppliers belong on the map too. Hospitals cannot scan a vendor’s hosted environment, so a statement is the only evidence available. Many large providers publish status pages for major vulnerabilities; smaller ones often need a direct question.

How the map differs by type of provider

An academic medical center with its own developers and research computing has a large internal estate to search, plus a long list of suppliers. Its first days go to scanning, and its map must reach into research groups that buy their own instruments and software. A community hospital that outsources IT operations depends on its managed service provider. Its contract should say who coordinates supplier inquiries during an event, or each party will assume the other is doing it.

An ambulatory network running a hosted electronic health record and a handful of cloud tools has little to scan and almost everything to ask. Its map is shorter, but nearly every answer is a statement. Federal hospitals, such as those in the Veterans Health Administration, also sit under federal software supply chain policy. In September 2022 the Office of Management and Budget had told agencies, in memorandum M-22-18, to collect attestations of secure development from software producers and allowed them to request SBOMs. That memo applies to federal agencies, not to private health systems.

Products that pass through several hands need one more field. When a device maker uses an embedded operating system or a communications module from another company, its answer depends on that company’s answer. The map should record that a statement is second-hand, so the hospital knows the chain behind it.

Group purchasing organizations and information sharing bodies can help. A question asked once on behalf of many hospitals is cheaper for the supplier to answer and faster for everyone.

Getting answers in usable form

Suppliers that did respond did so in every possible format: web pages updated several times, PDF letters, support portal notices, emails to account managers. Each had to be read by a person and matched by hand to the hospital’s inventory. A statement that a product line was not affected rarely said which versions it covered.

Machine-readable formats existed for this purpose. “Machine-readable” means structured so that a computer can process it without a person reading it first.

• The Common Security Advisory Framework, or CSAF, approved as a standard in November 2022, structures advisories so tools can parse them.
• A software bill of materials, or SBOM, says what components a product contains. It is the ingredients label on the package.
• Vulnerability Exploitability eXchange statements, or VEX, which federal agencies had been promoting that year, let a supplier say for a specific product and version whether it is affected, not affected, fixed or under investigation.

The two together turn a week of email into a query. A hospital holding SBOMs for its products could have asked its own system “which of our products contain OpenSSL 3.0?” and had an answer within minutes. A hospital receiving VEX statements could then have filtered that list down to the products where the flaw actually mattered.

What an SBOM can and cannot tell you

The National Telecommunications and Information Administration published federal minimum elements for an SBOM in July 2021. They ask for the supplier, component name, version, a unique identifier, dependency relationships, the author of the SBOM and a timestamp. Two common formats, SPDX and CycloneDX, carry those fields. With them, the OpenSSL question becomes a search for one component name and one version range.

The limits are just as concrete. An SBOM describes one release, so it goes stale when the product is updated. Its depth varies: some list only the top layer of components, missing a library pulled in two levels down. Names differ between tools, so the same library can appear under several identifiers, and matching them takes care. A statically linked library may be missed if the supplier generated the SBOM from package metadata alone. A hospital should treat an SBOM as strong evidence that a component is present and weaker evidence that it is absent.

Why VEX matters more for the negative answer

An SBOM alone tends to create alarms. If a product contains OpenSSL 3.0, a scanner reading the SBOM will flag it, whether or not the vulnerable code can be reached. VEX exists to close that gap. A supplier can state that the product is not affected and give a reason. The vulnerable code may be absent from the build, unreachable, or beyond an attacker’s control.

That reasoned negative is what hospitals were chasing by email in the OpenSSL week. A VEX statement is also versioned and dated, so it can be checked again when the product changes. Suppliers have argued, with some justice, that SBOMs released without VEX statements flood customers with findings that do not matter and flood suppliers with questions. The two documents work best as a pair.

Running intake without the standards

Even without standard formats, hospitals could control their own intake. Logging every supplier statement in one place, against the product and version it covers, with a status of affected, not affected, fixed or no answer, turns scattered emails into a dashboard. The security team can then report a single number to leadership each day: products still without a statement. That number is the honest measure of exposure during an event like this.

A useful tracker has few fields: product, version in use, supplier, date of statement, status, the reason given, a link to the evidence, next action and owner. Two measures come out of it directly. One is time to first statement for each supplier. The other is the share of statements that name specific versions, which separates evidence from reassurance.

Hospitals had little ability to require these in October 2022. They could start asking for them in new purchases and at renewal, and give preference to suppliers who provided them. The payoff is greatest for medical devices, where scanning is often unsafe and the supplier’s statement is the only practical source.

There is a trade-off. Structured data has to be stored, matched and kept current, and a folder of SBOM files nobody can query is no better than a folder of PDF letters. A small hospital may get more from a disciplined tracker and advisory subscriptions than from buying a platform to ingest SBOMs. A large system with hundreds of suppliers and in-house tooling has the opposite problem: manual intake will not scale, and the structured route pays back quickly.

Deciding what silence means

Some suppliers never answered. Others answered late. The health system needed a default for products without a statement, and few had one written down.

A sensible default treats a silent product as potentially affected if it plausibly uses the component and is exposed to the risk path. For this flaw, that path was a product verifying certificates from untrusted sources, such as a system accepting connections from the internet. Silent products on that path received compensating controls: tighter network restrictions, monitoring and, for devices, a check with clinical engineering on whether isolation would affect care. Silent products off the path were tracked and chased but not disrupted.

Compensating controls do not fix the flaw, but they make it much harder to reach. Restricting which systems can talk to a device, for example, means an attacker on the internet cannot send it the malicious certificate in the first place.

Writing the default in tiers

A written rule works best as a short set of tiers decided before any event. The first tier holds silent products that face the internet or partner networks, or that make outbound connections to services the hospital does not control. Those get compensating controls by an agreed deadline. The second tier holds silent products on internal clinical or business networks. Those get added monitoring and a firm chase date. The third tier holds isolated or offline products, which are logged and revisited.

“Under investigation” should count as silence with a date attached. A supplier that says it is investigating has acknowledged the question but has not answered it. If the status has not changed by the agreed date, the product moves to the default for its tier.

Who decides, and how it is recorded

Decisions about silent devices cross departments. The security lead can propose a network restriction, but only clinical leaders can say whether a ward can work without a device or with a slower workaround. The decision rights should be set in advance: the CISO or security lead for servers and applications, and a joint decision with clinical engineering and a nursing or medical informatics leader for devices.

The record matters too. The HIPAA Security Rule requires covered entities and business associates to analyze risks to electronic protected health information and manage them. A dated log showing which products were silent, which tier each fell into and which controls were applied is the evidence of that process for this event. It also lets the hospital show later that it acted on what it knew at the time.

The case against a strict default

A strict rule has costs. Network restrictions can break integrations nobody had documented, and a device cut off from its central station may lose alarms or data flow that clinicians rely on. Over-reaction also erodes trust: if every pre-announced flaw leads to disruption, clinical staff will resist the next request. That argues for drawing the risk path narrowly and testing controls on one unit before applying them widely. It does not argue for having no rule. Without one, silent products are either ignored or disrupted at random, and both outcomes are worse.

Silence should also have consequences in the supplier relationship. Response time to security inquiries is a measurable service level. Recording it for each supplier during events like this, and raising it at renewal, turns an annoyance into contract terms. The OpenSSL week was low stakes in the end. Treating it as a drill and recording which suppliers answered, how fast and in what form gave health systems evidence for the next, less forgiving event.

The contract language does not need to be elaborate. A clause can require the supplier to name a security contact and publish advisories in a stated place. It can also require an initial statement on a publicly known vulnerability within a set number of business days. The Health Sector Coordinating Council has published model contract language for medical device cybersecurity that hospitals and manufacturers can start from, and counsel should review any terms before they go into a master agreement.

How a week like this runs inside a prepared organization

Advance notice is a gift only if an organization knows how to use the days. At a health system that had done its homework, the seven days might unfold like this, set out as a simple playbook rather than a technical runbook.

1. Day one: frame the question. The security lead circulates a one-paragraph note to IT, clinical engineering, procurement and the executive on call. It says what is known (a critical flaw, version 3.0 only, fix due on a set date), what is not known (the details), and what each team should do this week. Precision at this stage stops the rumor mill and prevents teams from chasing the wrong version.
2. Day two: search what you own. The infrastructure team scans the servers and applications the hospital runs itself and lists anything containing OpenSSL 3.0. The software team checks its own code. These are the quick wins, and they shrink the unknowns.
3. Days two and three: ask what you bought. Using the supplier contact map, procurement and clinical engineering send one standard question to every relevant supplier, asking for product, version and status. Using the same wording for everyone makes the answers comparable.
4. Days three to six: log and sort. Every reply goes into a single tracker. Each product gets a status. Leadership receives the daily count of products still without a statement. The security team marks which silent products sit on the risk path.
5. Day six: agree the silence plan. For silent products on the risk path, the team agrees compensating controls in advance, with clinicians consulted on any device that might be isolated. Nobody wants to make those calls for the first time on release day.
6. Day seven and after: patch, protect and chase. When the fix and details arrive, the team patches what it controls, applies the agreed controls where needed, and keeps chasing silent suppliers. A short write-up afterward records what worked, what did not, and how each supplier performed.

Roles, rhythm and timing

The playbook needs named owners. One person runs the event and keeps the tracker. The infrastructure lead owns internal scanning and patching. Clinical engineering owns device inquiries and any isolation plan. Procurement owns supplier contact and escalation through account managers. A communications lead keeps clinical managers informed so that rumors about devices do not spread faster than facts.

A short daily stand-up keeps the work moving: the count of products without a statement, newly confirmed affected products, decisions needed and blockers. Fifteen minutes is usually enough. The project’s release window of 1300 to 1700 UTC fell in the morning on the US East Coast, so American teams could read the advisory and act during working hours. A hospital elsewhere might face the same release at night, and the plan should say who is on call to read it.

Change control also needs a decision ahead of time. Most hospitals restrict changes to clinical systems, with approval boards and freeze periods. An emergency change path, agreed during the notice week, lets the team patch servers on release day without bypassing review entirely. The same path should state which systems may not be touched without clinical sign-off.

Nothing in that list is technically advanced. It is coordination, record keeping and a few decisions made early. That is exactly why it is within reach of any organization willing to practice it, and why its absence is so costly.

A free rehearsal for the board

Hospitals spent the week chasing their suppliers by email for answers about a flaw that eventually proved manageable. For a board or executive team, that week was a free rehearsal that showed how the organization would cope if the next flaw were genuinely severe.

The costs of not knowing are real. Staff hours spent chasing suppliers by email are hours not spent on other security work. Precautionary isolation of devices can delay procedures or force workarounds on clinical staff. Regulators and insurers increasingly ask how quickly an organization can identify affected systems, and “we were waiting for suppliers” is not a reassuring answer. And if an attacker does use a flaw before a hospital has found it, the consequences can include diverted ambulances, canceled appointments and exposed patient records.

Staff feel this too. Security and clinical engineering teams in many hospitals are small. A week spent forwarding emails and decoding PDF letters is a week of overtime and frustration, and repeated weeks like that are part of why experienced people leave. A process that turns supplier answers into a tracked list protects those teams as much as it protects patients.

There is also a commercial point. Hospitals buy a great deal of technology, and they have more influence at the point of purchase than at any other time. A requirement to provide SBOMs, VEX statements or a named security contact costs little to write into a contract and is very hard to obtain afterward.

What a board should ask to see

Boards do not need component lists. They need a few measures that show whether the organization can answer a supplier question quickly. Useful ones include the time it took to produce a first list of possibly affected products, and the peak and final count of products without a supplier statement. Others are the number of suppliers with no known security contact and the share of critical suppliers whose contracts include a response commitment. Tracked across several events, those numbers show whether readiness is improving.

There is a regulatory angle as well. A 2021 amendment to the HITECH Act directs HHS to weigh recognized security practices when it decides penalties and audit outcomes. The test is whether a covered entity or business associate had them in place for the previous 12 months. A documented, rehearsed process for supplier vulnerability inquiries is the kind of practice that evidence can show. Counsel can advise on how that provision applies to a particular organization.

The argument that the week was overblown

One reasonable reaction was that the pre-announcement caused more work than the flaw deserved. The rating fell from critical to high on release day, exploitation needed unusual conditions, and much of the fleet ran an unaffected version. Some teams concluded that pre-announcements create panic and that they should wait for details next time.

That conclusion confuses the flaw with the readiness test. The severity did not decide how long the inventory work took. The missing contact records, unstructured answers and absent silence rules did, and they would have taken just as long for a flaw that stayed critical. Waiting for details would have saved a week of effort only by moving the same work into the days after release, when attackers also have the details.

The hospital that was ready on November 1

A well-prepared health system on November 1 looked something like this. Its security team had already searched its own servers and code. It had a list of every supplier, with a security contact for most of them. Statements were logged in one place, and leadership received a daily count of products still without an answer. Clinical engineering had identified which silent devices sat on internet-facing networks and agreed, with clinicians, which could be isolated without affecting care. When the fix arrived, the team knew where to apply it and which suppliers to chase.

It also knew what it would not do. It did not take devices offline on the strength of a rumor, and did not patch clinical servers outside the agreed emergency change path. It did not close the event until every product had either a statement or a recorded decision. The follow-up took weeks for the long tail of small suppliers, and the tracker stayed open until it was done.

The failures were just as recognizable:

• Searching only what you built. Internal scans are fast and satisfying, but most of a hospital’s exposure sits in products it bought.
• Patching the host and forgetting the containers. Applications that carry their own copy of the library stay vulnerable after the operating system is updated.
• Treating every email as an answer. A statement that does not name versions is a reassurance, not evidence.
• Having no rule for silence. Without a default, silent products either get ignored or get disrupted at random.
• Isolating devices without clinical input. A security fix that stops a ward from working creates a different kind of harm.
• Forgetting afterward. The most valuable output of the week was a record of which suppliers responded well. Few organizations kept it.

Testing readiness before the next flaw

A health system can test its readiness now, before the next flaw arrives, with a handful of questions:

• If a widely used component were found to have a serious flaw tomorrow, could we list every product that might contain it by the end of the day?
• Do we have a named security contact and an advisory feed for each of our critical suppliers, including medical device makers and cloud providers?
• What is our written rule for products whose suppliers stay silent?
• Do our new contracts ask for SBOMs, VEX statements and a response time for security inquiries?
• During the last event, which suppliers answered quickly and clearly, and have we used that at renewal?

A tabletop that takes an afternoon

The questions can be turned into a short exercise. The security lead names a widely used component and a version range, chosen for the exercise, and gives the team the same seven days the OpenSSL project gave. Over an afternoon, each owner shows what they would do: the scan they would run, the suppliers they would contact, the tracker they would fill and the tiers they would apply. Nobody needs to email a real supplier. The gaps show up as soon as someone tries to name a contact or a version.

The exercise works best when clinical engineering, procurement and a clinical leader take part alongside IT. Most of the delays in the OpenSSL week happened at the boundaries between those groups, and a tabletop is the cheapest place to find those boundaries. Repeating it each year, with a different component, shows whether the contact map and the contracts are keeping pace with what the hospital buys.

With hindsight

Two months later Congress gave the FDA new authority. The Consolidated Appropriations Act, 2023, signed on December 29, 2022, added section 524B to the Federal Food, Drug, and Cosmetic Act. It required manufacturers of cyber devices to include cybersecurity information, including a software bill of materials, in premarket submissions. A manufacturer seeking approval to sell a connected medical device now had to show its ingredients label up front. Manufacturers must also maintain processes for addressing vulnerabilities after market. The FDA began applying those requirements to new submissions in 2023.

The details followed in stages. The new section took effect on March 29, 2023. The FDA said it would generally not refuse submissions for missing cybersecurity information until October 1, 2023, giving manufacturers a transition period. Its final premarket cybersecurity guidance arrived in September 2023, and an updated version in June 2025 added specific recommendations on section 524B. The guidance asks manufacturers to describe, for components in the SBOM, the level of support each receives and its end-of-support date.

That last request became pointed for OpenSSL itself. Version 1.1.1, the branch whose prevalence made the November 2022 flaw a non-issue for most devices, reached end of life on September 11, 2023. After that date it received no public security fixes, though the project offered paid extended support. The version that had protected hospitals in 2022 became, a year later, an unsupported component inside many devices still in service. The question for suppliers shifted from “are you affected?” to whether the library inside a product was still maintained, and by whom.

CISA published minimum requirements for VEX documents in April 2023, and supplier use of machine-readable advisories grew, though unevenly. CSAF 2.0, approved as an OASIS standard on November 18, 2022, gave those statements a common container. The backdoor discovered in the XZ Utils library in March 2024 tested the same capability again. Once more, organizations had to work out quickly which of their products contained a particular component. Once more, those with good inventories and responsive suppliers moved fastest. The OpenSSH flaw known as regreSSHion, disclosed in July 2024, repeated the drill for another ubiquitous component.

Policy for hospitals moved too, mostly toward the inventory side. HHS published voluntary Cybersecurity Performance Goals for the health sector in January 2024, which include asset inventory, mitigating known vulnerabilities and cybersecurity requirements for vendors and suppliers. In January 2025 HHS proposed amendments to the HIPAA Security Rule that would, among other things, require a written inventory of technology assets and a network map. Whatever the final form of that proposal, the direction is clear: regulators expect a hospital to know what it runs.

By 2026, SBOMs and VEX statements are more common for new medical devices and major software products. Older devices and smaller suppliers still often require manual inquiries, so supplier contact maps and silence rules remain the controls hospitals can apply to their whole fleet.

That last point matters for anyone planning budgets or reviewing risk. Medical devices stay in service for many years, so the newer requirements improve the picture slowly, one purchase at a time. For the foreseeable future, a hospital’s ability to answer “are we affected?” will depend partly on structured data from newer suppliers. It will also depend on old-fashioned discipline: knowing whom to ask, logging every answer, and deciding in advance what silence means.

What held up from the week is the diagnosis: the negative answer was the bottleneck, and it still is for the older half of most fleets. What changed is that the structured route now exists for new purchases, backed by law for medical devices. What did not change is that hospitals must still ask for it, store it and use it.

The OpenSSL week carried a simple message: low-stakes events are the cheapest time to find out how ready an organization really is. Measuring supplier responses during the easy drills builds the evidence, and the contract terms, that make the hard events manageable.