Cybersecurity for Healthcare Providers in Saudi Arabia

Ask an IT team in a hospital to patch a piece of equipment and the answer is frequently that they are not permitted to. The device is regulated, the manufacturer controls its configuration, changing it may affect the device's approved state, and the vendor's next validated update is scheduled for some point next year.

That single constraint reshapes everything. Most security guidance assumes you can patch, install an agent, and reboot during a maintenance window. In a hospital, all three assumptions can fail at once, on a device attached to a patient, in a department that never closes.

Healthcare security is therefore less about applying standard controls harder and more about protecting things you are not allowed to touch. This guide covers how to do that, how to handle identity without slowing clinical work, what downtime planning actually requires, and the specifically Saudi obligations that shape all of it.

Why Is Healthcare Different?

Six characteristics separate healthcare from every other sector, and they compound.

• The risk is to care, not only to data. An outage in an office costs productivity. An outage in a hospital delays diagnosis and treatment, which is a different category of consequence and should drive a different investment case.
• Equipment cannot be patched on your schedule. Medical devices are regulated products whose configuration the manufacturer controls, so changes may require vendor validation and cannot simply be applied.
• There is no maintenance window. Critical care areas run continuously. The system you need to take offline is in use at three in the morning.
• Clinical urgency correctly overrides friction. A nurse who must reach a record during a deteriorating patient episode will share a login rather than lose thirty seconds. That is the right clinical decision, which means any control adding delay at the bedside will be bypassed and should be designed differently rather than enforced harder.
• Asset lifecycles are mismatched. An imaging system may serve a hospital for well over a decade. The computer controlling it has a supported software life measured in a few years.
• Ownership is split. Biomedical or clinical engineering owns medical devices. IT owns computers. Many devices are both, and neither department's inventory contains them.

That last point is the same structural gap described in converged security, where facilities-owned equipment sits outside IT's view. In healthcare the equipment is attached to patients, which raises the stakes considerably.

What Makes Medical Devices a Distinct Problem?

A medical device is a computer whose configuration you frequently do not control. Infusion pumps, patient monitors, ventilators, imaging systems, laboratory analysers and their attached workstations all run software, hold data and connect to the network, but they arrive as regulated products rather than as IT assets.

Three constraints follow. Security agents usually cannot be installed, because the manufacturer's supported configuration does not include them. Patches usually cannot be applied on the operator's timetable, because updates must come through the vendor's validated release process. And the device's supported software life is routinely shorter than its clinical service life, so a device can spend years in use after the last update it will ever receive.

The table below sets out how the available controls differ.

Criterion	Standard IT endpoint	Supported medical device	Legacy or unsupported medical device
Security agent can be installed	Yes	Usually not, unless vendor approved	No
Patching controlled by	The organisation	The manufacturer's validated release cycle	Nobody, updates have ended
Vendor approval needed to change	No	Yes	Not applicable, no changes available
Support life against service life	Broadly aligned	Support ends first	Support already ended
Remote vendor access	Controlled by IT	Frequently contractual and standing	Frequently standing and forgotten
Primary available control	Endpoint hardening and patching	Network segmentation plus vendor patch discipline	Network isolation and compensating controls
Realistic objective	Keep it current	Keep it current within the vendor's cycle	Contain it and plan replacement
Who usually owns it	IT	Biomedical engineering	Biomedical engineering

Two practices make this workable. Build one inventory covering every connected medical device, jointly owned by IT and biomedical engineering, because neither list is complete alone and the devices missing from both are the exposure. And put security into device procurement, requesting the manufacturer's disclosure statement for medical device security, known as the MDS2 form, which is a standardised document describing the device's security characteristics, along with the stated support period and the process for delivering patches. Asking at tender is free. Asking after installation changes nothing.

How Should a Hospital Network Be Segmented?

Segmentation is the primary control in healthcare precisely because so many endpoints cannot be hardened. The objective is that a compromised device can reach almost nothing.

Six segments cover most providers:

• Critical medical devices. Life-supporting and life-sustaining equipment, isolated tightly, permitted to communicate only with the specific clinical servers required.
• General medical devices and diagnostics. Laboratory analysers, monitoring equipment and similar, separated from critical devices so an issue in one does not reach the other.
• Imaging and archiving. High-bandwidth traffic between modalities and the image archive, kept on its own path so it neither disrupts nor is disrupted by other clinical traffic.
• Clinical workstations. Where staff access records, on a segment separated from the devices themselves.
• Corporate and administrative. Finance, human resources, general office work.
• Guest and patient wireless. Fully isolated, internet only, with no route to any internal segment. Patients and visitors on hospital wireless must be unable to reach anything clinical.

Building systems belong on their own segment as well, following the same reasoning as operational technology security, and the general design principles are set out in network segmentation and VLAN design.

Vendor remote access needs particular discipline. Imaging and laboratory vendors frequently hold standing remote access for support, arranged years earlier and never reviewed. Replace shared or permanent access with named individual accounts, multi-factor authentication, access granted only for the duration of a specific task, and full session logging. This belongs in the third-party risk process alongside the contract.

How Do You Handle Identity Without Slowing Clinical Care?

Shared logins at nursing stations are almost universal, and treating that as a discipline problem misdiagnoses it. Clinicians share credentials because signing in takes time they do not have, and in the moment they are right to prioritise the patient. The control has to change, not the behaviour.

Four approaches reduce friction rather than adding it:

Fast user switching by badge. A proximity badge tap authenticates the user at a shared workstation in about a second. Where the badge is combined with a PIN it satisfies most two-factor requirements while remaining faster than typing a password.

Session roaming. A clinician's session follows them between workstations, so moving from one bay to another does not mean signing in again. This removes the largest single cause of staff leaving sessions open.

Break-glass emergency access. Break-glass access is a documented, deliberately available override allowing a clinician to reach records they would not normally be permitted to see, which is logged, time-limited and reviewed afterwards. Its purpose is to give staff a legitimate route in an emergency so they never need an illegitimate one. A system with no break-glass path guarantees shared credentials.

Auditing record access rather than blocking it. Clinical need is unpredictable, so overly restrictive rules obstruct care. Broad access with rigorous auditing, including proactive review of access to records of high-profile individuals and of staff members, is generally the workable balance.

Where biometrics are used at the point of care, the considerations in biometric authentication apply, including where templates are stored, which matters more in healthcare given the sensitivity of everything else in the environment.

What Happens When Ransomware Hits?

For a hospital, ransomware is not primarily a data incident. It is a continuity of care incident, and the response has to be built around that.

The technical recovery is the smaller half of the problem. The larger half is whether the organisation can continue treating patients while systems are unavailable, which depends on clinical downtime procedures being written and, critically, practised.

Downtime planning should answer specific questions before an incident, not during one:

• How are patient records accessed when the electronic record is unavailable, and how far back does the printed or cached summary reach?
• How does the laboratory report results, and how does the ward receive them?
• How are images reviewed if the archive is down, and can modalities operate standalone?
• How is medication administration recorded and reconciled afterwards?
• Who decides to divert incoming patients, on what information, and how is that communicated?
• How does clinical documentation created on paper get reconciled into the record once systems return?

Two points make the difference between a plan and a document. The procedures must be practised, ideally as part of a tabletop exercise that includes clinical leadership rather than only IT, because the decisions that matter most are clinical ones informed by technical status. And the plan itself must be available offline, since a plan stored on the file server is unavailable in exactly the scenario it exists for.

Backups need the same scrutiny. Test restores of clinical systems specifically, measure how long a full restore actually takes, and confirm that the recovery time is compatible with continuing to run a hospital. The wider approach is covered in ransomware recovery and disaster recovery planning.

What Do Saudi Healthcare Providers Need to Address?

Five factors apply specifically in the Kingdom.

National health information exchange changes the connectivity picture. Saudi providers integrate with the national platform for health information exchange services, known as NPHIES, which carries clinical and claims information between providers, payers and health authorities. That integration means the clinical estate now holds credentials for a national platform and maintains a connection to it. Two things follow, and they mirror the situation retailers face with tax platform integration. The interface credentials are secrets requiring the protections described in secrets management, including controlled storage, rotation and revocation when a vendor's involvement ends. And the firewall rule permitting that connection should be written narrowly to the specific endpoints required, rather than as a broad allow that also opens other paths.

Medical devices are regulated by the Saudi Food and Drug Authority. Device approval, importation and post-market obligations fall under the SFDA, which is why configuration changes are constrained. Engage the regulatory or biomedical function before assuming a security change is permitted, and use the manufacturer's stated position rather than inferring it.

Accreditation includes information management. Healthcare facilities in the Kingdom are accredited through the Saudi Central Board for Accreditation of Healthcare Institutions, and information management and patient record confidentiality feature within accreditation expectations. Aligning security work with the accreditation cycle usually secures attention and budget more effectively than presenting it separately.

Health data carries heightened sensitivity. Health information is among the most sensitive categories of personal data under the Personal Data Protection Law (PDPL) administered by the Saudi Data and Artificial Intelligence Authority, which affects retention, access control, disclosure and any transfer outside the Kingdom. Cloud clinical systems and remote diagnostic services should be assessed on where data is stored and who can reach it, not only on functionality. Healthcare providers also fall within the scope of the National Cybersecurity Authority's Essential Cybersecurity Controls (ECC), and systems classified as critical carry the Authority's additional critical systems controls.

Seasonal surge is a genuine risk factor. Facilities serving Makkah and Madinah operate under extraordinary demand during Hajj and Umrah periods, with temporary staff, expanded capacity and mobile facilities added at scale. A cyber incident during that window has consequences of an entirely different order, and the corresponding preparations belong in the plan: change freezes ahead of peak periods, rehearsed downtime procedures before rather than during the season, and rapid onboarding and offboarding processes for temporary clinical staff so access does not persist afterwards.

Blue Edge, a technology distributor based in Dammam, Saudi Arabia, distributes NinjaOne endpoint and patch management for administrative and clinical workstation estates and KnowBe4 security awareness training, alongside the structured cabling and networking that segmented clinical networks depend on.

What Are the Most Common Healthcare Security Mistakes?

Six mistakes account for most healthcare estates that remain exposed.

No joint medical device inventory. Biomedical engineering holds one list, IT holds another, and the devices absent from both are the ones nobody is protecting.

Medical devices on a flat clinical network. A device that cannot be patched, able to reach the whole estate, is the worst possible combination and the most common one.

Trying to secure the device instead of the network around it. Effort spent seeking permission to install agents on regulated equipment is usually effort that segmentation would have spent better.

Adding authentication friction at the bedside. Any control that costs a clinician time during care will be bypassed. Reduce friction with badge tap and session roaming, and provide a break-glass path so the bypass is never necessary.

Downtime procedures that exist but are never practised. A document nobody has used cannot be relied on during the incident it was written for, particularly if it is stored on an unavailable system.

Standing vendor remote access. Imaging and laboratory support access granted years ago, shared, never reviewed, and frequently still active after the contract changed.

Protect What You Cannot Patch

The defining constraint in healthcare security is that a significant part of the estate is outside your control by design. Regulated devices are supposed to be configuration-controlled, and that is a patient safety feature rather than an oversight. Working against it wastes effort.

So work around it. Build one inventory jointly with biomedical engineering, because you cannot contain what you have not listed. Segment the clinical network so each device reaches only what it must. Treat unsupported devices as contained, with a documented replacement date rather than an indefinite exception. And put the MDS2 disclosure and a stated support period into every device tender, so the next generation of equipment arrives in a supportable state.

Then deal with the two human realities honestly. Clinicians will bypass friction at the bedside and are right to, so reduce the friction and provide a break-glass path instead of enforcing harder. And practise the downtime procedures with clinical leadership in the room, because when it happens the critical decisions are clinical, informed by technical status, and nobody makes those well for the first time under pressure.

Frequently Asked Questions

• Why can't medical devices simply be patched like other computers?

  Because they are regulated products whose configuration the manufacturer controls. Updates must come through the vendor's validated release process, and applying changes outside that process may affect the device's approved state and the vendor's support position. Many devices also cannot accept a security agent, because the manufacturer's supported configuration does not include one. The practical response is to control the network around the device rather than the device itself.

• Who should own medical device security, IT or biomedical engineering?

  Both, through one joint inventory and one named accountable owner. Biomedical engineering holds the vendor relationships, the regulatory context and knowledge of clinical criticality. IT understands network exposure, segmentation and monitoring. Assigning it wholly to either produces a predictable failure: biomedical alone means no network controls, IT alone means changes made without clinical or regulatory context.

• Why do clinical staff share logins, and how do you stop it?

  Because signing in costs time during patient care, and in the moment the patient correctly takes priority. The answer is to remove the friction rather than enforce the rule harder. Badge tap fast user switching authenticates in about a second, session roaming lets a clinician move between workstations without signing in again, and a documented break-glass override gives staff a legitimate emergency route so an illegitimate one is never needed.

• What are clinical downtime procedures?

  They are the documented arrangements for continuing patient care while electronic systems are unavailable, covering how records are accessed, how laboratory results reach wards, how images are reviewed, how medication administration is recorded, who decides on patient diversion, and how paper documentation is reconciled afterwards. They must be practised with clinical leadership involved and stored offline, because a plan held on an unavailable system cannot be used.

• What does NPHIES integration mean for a provider's security?

  It means the clinical estate holds credentials for a national health information exchange and maintains a connection to it. Those interface credentials are secrets requiring controlled storage, rotation and revocation when a vendor's involvement ends, in the same way as any database password. The firewall rule permitting the connection should be written narrowly to the specific endpoints required rather than as a broad allow that opens additional paths.

---

Published 9 September 2026 • Last updated 3 October 2026 • This article is reviewed when standards, regulations or product guidance change.