Cybersecurity in hospital equipment does not begin on the day a system is connected to the network. Nor does it end when commissioning is complete. In fact, it starts much earlier: when the hospital decides what it needs, which communications will be essential, who will be allowed to administer the solution, how long it will receive support and how it will be replaced when it reaches the end of its service life.
In a connected operating room, a digital incident goes far beyond data confidentiality. A shared account, an update with no rollback option, an undocumented dependency or uncontrolled remote access can take a function out of service, complicate maintenance or prolong an interruption. The impact of cyberattacks on the healthcare sector therefore means that hospitals must stop thinking solely about how to respond and start deciding how to prevent risks through design and procurement.
The truly useful question is not whether a product is “secure” in absolute terms. What matters is understanding how it will be integrated into the hospital environment, which tests will verify it and who will be responsible for maintaining its security conditions over time.
Cybersecurity is not added to hospital equipment once the project has been completed. It is defined in the procurement specifications, verified during acceptance and maintained throughout the equipment’s service life.
In brief: cybersecurity in hospital equipment comprises the technical, organisational and contractual requirements needed to protect the availability, integrity and confidentiality of connected systems and the data they exchange, from selection through to decommissioning.
This approach has become even more relevant with the ENISA guidelines for cybersecurity procurement in hospitals, published in July 2026. The guide organises procurement into three main stages —planning, selection and management— and proposes requirements, information to be provided by the supplier and evidence that should be retained throughout the contractual lifecycle.
Why cybersecurity begins in the procurement specifications
A statement such as “the system must be secure” may sound reassuring, but it is almost impossible to verify. Nor does it make it possible to assign responsibility clearly if something goes wrong. A well-formulated requirement, by contrast, describes a specific behaviour, establishes the evidence that must be provided and identifies who must validate it.
This is not merely a semantic distinction. If the update policy, activity logs or remote-support conditions are not included in the procurement specifications, the hospital may only discover their limitations once the system has already been installed. Correcting the architecture at that stage is usually more expensive, requires greater coordination and leaves less room to choose an alternative.
| Insufficient wording | Verifiable requirement | Expected evidence |
|---|---|---|
| “The equipment will be cybersecure.” | The supplier will document the components, versions, interfaces and network services included in the scope. | Technical inventory and communications diagram delivered before acceptance. |
| “The system can be updated.” | The contract will define the update policy, method, support, validation and rollback procedure. | Tested procedure and communicated support schedule. |
| “Remote maintenance will be permitted.” | Remote access will be disabled by default or subject to authorisation, traceability and expiry. | Evidence of access activation, logging and revocation. |
| “Backups will be available.” | Recoverable data and configurations, backup frequency, custody and restoration objectives will be identified. | Restoration verified during acceptance testing. |
The European Action Plan on the Cybersecurity of Hospitals and Healthcare Providers structures the European response around four pillars: prevention, detection, response and deterrence. Bringing these capabilities into the procurement process turns general principles into specific project decisions.
Six decisions for managing the entire lifecycle
Security is not an isolated phase that can simply be considered complete. It accompanies the equipment from the definition of needs through to the end of support and final decommissioning. Every connected critical-area project should consider at least these six decisions:
Purchasing a connected system without agreeing how it will be maintained and decommissioned means accepting technical debt before it is even put into service.
Seven cybersecurity requirements for hospital equipment
1. Technical inventory and dependency map
The hospital needs to know which components it is receiving, which versions they use, which systems they communicate with and which services they require to operate. This inventory is not merely an administrative list. It is the reference that will make it possible to assess the criticality of each element, prepare an update and anticipate which other functions could be affected by a change or incident.
In addition to the initial inventory, the parties should agree who will keep it up to date. Documentation that is accurate on the day of acceptance loses much of its value if it does not reflect subsequent modifications.
2. Identity, privileges and remote access
Shared accounts, default passwords and permanent permissions make it impossible to know with certainty who did what and when. The project must define how users and technicians will authenticate, which privileges each profile needs, who may authorise a remote intervention and how credentials will be revoked once the work has been completed.
Remote access deserves particular attention. It should not remain open for convenience or depend on a password known by several people. A reasonable approach is to enable it only when necessary, for a limited period and with a record of the activity performed.
3. Segmentation and controlled interoperability
A connected operating room needs to share information, but that does not mean all its components should communicate freely with one another. The network must allow the flows that support clinical activity and block those that are not required.
Interoperability and segmentation are not opposing concepts. The former enables information exchange; the latter defines its limits. The objective is for equipment to work together without unnecessarily expanding the attack surface. This issue complements the analysis of medical device interoperability in critical care units.
4. Updates, vulnerabilities and support duration
Before awarding a system, the hospital should know how and how often it is updated, which channel is used to report vulnerabilities, how long it is expected to be supported and which procedure will apply if a patch cannot be installed immediately.
In a critical area, updating without validation can create as much risk as postponing a necessary correction indefinitely. The parties should therefore agree on a prior backup, compatibility testing, an intervention window, the people responsible for authorisation and a rollback mechanism if the outcome is not as expected.
It must also be clear what will happen when support ends. Knowing that date in advance allows the hospital to budget for migration and avoids retaining vulnerable systems because no alternative has been prepared.
5. Availability, degraded mode and recovery
In a critical environment, availability is also a security property. The design must anticipate what will happen if the network, a workstation, an integration or a central service fails. The response cannot be improvised during the incident.
Degraded modes, configuration backups, planned spare parts and manual procedures help reduce clinical impact. Having a backup is not enough: it is equally important to verify that it can be restored within the agreed timeframe. This dimension expands on the article about operational continuity in operating rooms and ICUs.
6. Logging, monitoring and notification
When an incident occurs, technical teams need to reconstruct what happened without compromising privacy. This requires knowing which events the system logs, how its clock is synchronised, how long information is retained and how it can be integrated with the hospital’s monitoring tools.
The contract should also establish a clear notification channel. If the supplier identifies a vulnerability, the hospital needs to know who will receive the alert, which information it will contain, how its severity will be classified and how quickly an action will be proposed.
7. Supply chain, end of support and secure decommissioning
A solution may depend on third-party components, subcontractors, software libraries or external services. The hospital needs to identify which elements are critical, who maintains them and which alternatives exist if one of those suppliers ceases to provide support. The NIST guide to managing cybersecurity risk in the supply chain recommends incorporating these relationships into governance and communicating security requirements to the suppliers involved.
Obsolescence should not come as a surprise either. The contract can establish how far in advance the end of support must be announced and which migration options will be offered. When the equipment is decommissioned, accounts, credentials, configurations and data must be removed in a verifiable manner; remote access must be revoked and the inventory must record its withdrawal.
| Control area | Question the project must answer | Verifiable outcome |
|---|---|---|
| Assets | Do we know what is connected and what it depends on? | Inventory, versions, interfaces and network diagram. |
| Access | Who can gain access, with which privileges and for how long? | Named accounts, least privilege and activity logs. |
| Communications | Which flows are clinically necessary? | Segmentation and rules approved by IT. |
| Maintenance | How is a vulnerability corrected without compromising operations? | Validated update, rollback and agreed intervention window. |
| Continuity | How does the service continue when a component fails? | Degraded mode, backups and tested recovery. |
| Incidents | Who detects, communicates, decides and recovers? | Documented escalation path, timescales and responsibilities. |
How it applies in a connected operating room
The digital architecture of the connected operating room can bring together environmental controls, video, communications, alarms, information and technical services. This integration facilitates access to information and can reduce operational steps, but it also creates dependencies that must be documented from the project stage.
Within the Tedisel Medical ecosystem, HERMES control software centralises functions within the environment. The Q Panel technical panel can integrate displays, PCs, video, data, alarms and other components, while the Glass Panel control and display panel brings visual elements together and supports configurations compatible with PACS, nurse stations and HERMES. The specific scope always depends on the configuration agreed for each hospital.
An important limitation: no panel, software or supply unit can guarantee the cybersecurity of an operating room on its own. The outcome depends on the complete architecture, its configuration and the way in which the hospital, integrators and suppliers allocate and fulfil their responsibilities.
| Environment layer | Solution or responsible party | Role within security |
|---|---|---|
| Interface and infrastructure | Q Panel / Glass Panel | They centralise technical elements and interfaces that must be included in the inventory and maintenance plan. |
| Control and integration | HERMES | It concentrates control and integration functions; its flows, access and dependencies must be documented. |
| Network and corporate services | Hospital IT | Defines segmentation, identities, monitoring, backups and remote-access conditions. |
| Clinical operations | Users and clinical management | Determine criticality, degraded modes and safe continuity conditions. |
| Lifecycle | Hospital and supplier | Coordinate support, updates, changes, incidents and decommissioning. |
Acceptance testing: turning promises into evidence
Technical acceptance is the point at which the hospital verifies whether the contracted solution works in the real environment. This does not mean conducting invasive tests without coordination, but rather checking the agreed documentation, configurations and capabilities before putting the solution into service.
Every requirement should produce evidence. If a check cannot be completed or requires an exception, it must be documented together with its risk, the compensating measure and the person responsible for resolving it.
| Check | Acceptance criterion | Participants |
|---|---|---|
| Final inventory | Components, versions and connections match the installed scope. | Supplier, IT and biomedical engineering. |
| Secure configuration | No default credentials or unnecessary privileges remain. | IT and supplier. |
| Remote access | It can only be enabled with authorisation, logging and expiry. | IT, biomedical engineering and support. |
| Segmentation | Communications are limited to the approved flows. | IT and integrator. |
| Update and rollback | The procedure can be performed without losing configuration or clinical functionality. | Supplier, IT and key users. |
| Recovery | Backups can be restored within the agreed objective. | IT, biomedical engineering and supplier. |
| Escalation | Contacts, severity levels, timescales and decisions are documented. | Hospital and supplier. |
A useful acceptance test does not merely confirm that “everything works”. It demonstrates what works, under which conditions and who must act when it stops working.
Governance: a shared responsibility, but never a vague one
Procurement turns requirements into contractual obligations. IT defines the network, identities and monitoring. Biomedical engineering manages the installed equipment base. Engineering coordinates facilities and availability. Clinical professionals explain the consequences of an interruption. The supplier, meanwhile, documents, maintains and communicates.
Everyone participates, but that does not mean responsibility can be distributed until it disappears. Every decision needs an unequivocal owner and a known escalation path.
| Decision | Primary owner | Required participants |
|---|---|---|
| Approve a new connection or interface | Hospital IT | Integrator, biomedical engineering and clinical owner. |
| Authorise remote support | IT / security | Biomedical engineering and supplier. |
| Schedule an update | Biomedical engineering | IT, supplier and clinical leads. |
| Activate a degraded mode | Clinical management for the area | IT, engineering and biomedical engineering. |
| Isolate equipment following an incident | Incident response / IT | Clinical owner, biomedical engineering and supplier. |
| Validate the return to service | Clinical owner | IT, biomedical engineering and supplier. |
Infographic: specify, test and maintain security
The infographic summarises the lifecycle through three commitments that can be easily transferred to any hospital project. Specify turns risks into concrete requirements. Test transforms the promises made in the procurement specifications into evidence. Maintain prevents a configuration accepted at the outset from becoming obsolete or losing control over time.
These are not three independent actions. What is not specified can hardly be tested, and what is not maintained will cease to provide assurance even if it worked correctly on the day of acceptance.
Conclusion: purchasing technology means assuming responsibility for its lifecycle
Cybersecurity in hospital equipment does not depend on a single function and cannot be delegated entirely to the supplier. It begins when the hospital defines its needs, continues through architecture design and is sustained by maintenance, monitoring, testing and clear responsibilities.
In operating rooms and critical areas, the relevant question is not whether a system is “secure”, but how it contributes to secure and verifiable operations. The dependencies it introduces, how it is updated, which logs it generates, how it is recovered and what happens when support ends are as important as its functional capabilities.
For Tedisel Medical, this approach expands the content cluster dedicated to technical panels, digital architecture and operational continuity. The integration of HERMES, Q Panel, Glass Panel and the rest of the equipment must be planned as part of a coordinated and maintainable clinical environment that is ready to evolve.
Main technical sources: ENISA, 2026; European Commission; and NIST SP 1305.
Frequently asked questions about hospital cybersecurity
What is cybersecurity in hospital equipment?
It is the technical, organisational and contractual protection of devices, software, connections and data throughout their service life. Its objective is to preserve availability, integrity and confidentiality, reducing both digital risk and the potential clinical consequences of an interruption or manipulation.
What should procurement specifications include?
They should define, at a minimum, the inventory to be delivered by the supplier, required communications, identity and privilege management, remote-access conditions, the update policy, vulnerability handling, available logs, backups, recovery, support periods and the decommissioning procedure. Every requirement must be associated with evidence and a person responsible for validating it.
Why is it important to know the duration of support?
Because a system may continue to operate after it no longer receives security fixes or compatible updates. Knowing the support period in advance makes it possible to plan budgets, migration and compensating measures, preventing obsolescence from becoming a clinical or technical emergency.
How can interoperability and segmentation be combined?
By defining and authorising only the flows required for clinical activity. Interoperability allows systems to exchange the information they need; segmentation prevents that connectivity from extending to equipment, services or networks that should not be exposed.
Who is responsible for equipment cybersecurity?
Responsibility is shared, but every task must have a clear owner. The supplier documents and maintains its solution; IT controls the network, identities and monitoring; biomedical engineering manages the equipment base; engineering coordinates facilities and continuity; and clinical leads determine criticality and validate operating and recovery conditions.
What role do HERMES, Q Panel and Glass Panel play?
HERMES can centralise control and integration functions, while Q Panel and Glass Panel can bring together interfaces, visualisation and different technical components within the environment. Their specific role depends on each project. None of them guarantees operating-room cybersecurity on its own: they must be integrated into a documented, segmented and maintainable architecture governed jointly by the hospital and the suppliers involved.
Bring engineering, biomedical engineering, IT and integration teams into the process from the outset to avoid decisions that become costly to correct once the equipment has been installed. Talk to Tedisel Medical and we will work with you to develop a solution tailored to your project’s needs.