Identity and Access Management for UAE Healthcare

Why hospital IAM is a different problem from office IAM

Most IAM guidance is written for knowledge workers who sit at one desk, use one laptop, and log in once a day. Clinical environments do not work that way. A nurse moves between four workstations on a single shift, a doctor needs to pull up a chart in under ten seconds during a code, and a radiologist reads images from a PACS terminal configured a decade ago and never re-imaged because it also runs the imaging vendor's proprietary software stack.

That reality produces three patterns generic IAM projects underestimate: shared logins on shared workstations, break-glass access that has to work even when the identity provider is unreachable, and a device population including infusion pumps, PACS viewers and lab analysers never designed to support individual user accounts. An IAM programme that treats a hospital like a bank branch with more paperwork gets the architecture wrong before it gets to policy.

Where it actually breaks

Shared and generic accounts

The single most common finding in a healthcare identity assessment is a shared login on a nursing station, ward terminal or triage kiosk. It usually exists because the clinical workflow genuinely cannot tolerate a ten-second login delay during handover, and nobody replaced the workaround once single sign-on arrived. The fix is not "ban shared accounts": it is fast local authentication (proximity badge tap, PIN-plus-badge, or session locking tied to a badge reader) paired with an identity provider that logs the badge tap as the actual user event. Removing the shared account without replacing the workflow just pushes staff to write PINs on sticky notes.

Break-glass access

Emergency access to a patient record has to work when the requesting clinician is not the record's assigned care team, and it has to work during an identity provider outage, not just during business-as-usual. A break-glass process that depends on a helpdesk ticket during a cardiac arrest is not a control, it is theatre. What works: a pre-provisioned emergency role that any credentialed clinician can invoke, that fires an immediate alert to a privacy officer, and that generates a mandatory post-hoc justification review within a fixed number of hours. The audit trail is the control here, not the gate.

Joiner-mover-leaver for a workforce that is not all employees

Permanent staff deprovisioning is usually fine, because it runs through HR. What breaks is everyone HR does not directly manage: locum consultants on short contracts, agency nurses on rotating assignments, medical students on placement, and outsourced billing or transcription staff who need EHR access from outside the hospital network. Each of those populations typically has its own sponsor, its own start and end date, and its own system of record that the identity team does not control. An access review that only reconciles against the HR feed will always miss this group, and it is precisely this group that produces stale, unmonitored accounts.

Devices and service accounts

PACS workstations, infusion pump consoles, lab interfaces and biomedical equipment gateways commonly authenticate with one service account shared across every device of that type, because the vendor's original design assumed a closed network with no meaningful identity layer. These accounts rarely appear in a directory-based access review because they are not tied to a person. Vulnerability and asset inventories catch the device; identity governance frequently does not catch the account behind it.

Federation with NABIDH and Malaffi

Dubai's NABIDH and Abu Dhabi's Malaffi health information exchanges connect hospital and clinic systems so a patient's record follows them across providers. That federation changes the identity problem: a clinician's access decision is no longer contained inside one hospital's directory, because the exchange itself has to authenticate the requesting facility and, in some workflows, the requesting clinician. Any identity architecture built without accounting for this connects the wrong system first and retrofits federation later, which is the more expensive order to do it in. Decide early whether your identity provider will assert clinician-level attributes to the exchange or whether the exchange only sees a facility-level trust relationship, because that decision drives how granular your role model has to be internally.

Role design: RBAC is necessary but not sufficient

Role-based access control gets a hospital most of the way: nurse, physician, pharmacist, billing clerk and lab technician are reasonably stable roles. Where pure RBAC falls short is context: a physician's legitimate access to a chart usually depends on whether they are on the care team for that patient, in which department, and during which shift. Attribute- and relationship-based access controls, layered on the role model, are what separate "this physician can see cardiology patients" from "this physician can see this patient because they are covering tonight." Most EHR platforms support this through care-team and encounter-based access models; the failure mode is deploying the role layer and never configuring the relationship layer on top, which leaves every physician of a given role able to browse every patient.

What assessors actually ask for

A DoH or DHA-aligned data protection review, or an internal audit against UAE PDPL expectations, generally focuses on evidence rather than architecture diagrams:

• A current access review for clinical and administrative roles, with sign-off from a named data owner, not just IT.
• Break-glass logs showing that emergency access events were reviewed within the committed window, with a justification recorded for each one.
• Proof that leaver deprovisioning for non-employee populations (locums, agency staff, vendors) runs on a defined SLA, not on an ad hoc basis.
• Evidence that shared and service accounts are inventoried, that each has a named owner, and that their use is logged even though the login itself is not tied to one person.
• Multi-factor authentication on remote and administrative access at minimum, with a documented exception process for clinical workstations where MFA genuinely cannot be applied without breaking a workflow.

Architecture decisions that actually matter

The platform choice matters less than three decisions made early and expensive to reverse. First, whether privileged administrative access to clinical systems runs through a dedicated privileged access management layer with session recording, or through the same directory accounts as everyone else; breaches involving domain admin or EHR database credentials are consistently the most damaging because they bypass every patient-level control at once. Second, whether the identity provider can express care-team and encounter-level context to downstream applications, or only role membership; that capability determines whether attribute-based refinement is possible later. Third, how emergency access is logged and reviewed, because this is the control auditors return to first, and the one most hospitals design last.

Microsoft Entra ID and comparable identity platforms handle the federation and conditional access layer well; the harder integration work is almost always on the EHR and PACS side, where vendor-specific access models have to be mapped onto whatever role and attribute structure the hospital settles on. A privileged access management layer for the administrative accounts that manage those clinical systems closes the gap that role-based end-user access never covers.

A working checklist

Before calling a healthcare IAM programme complete, confirm each item below has an owner and a review cadence, not just a policy document:

1. Every shared and service account is inventoried, has a named accountable owner, and its use is logged even where the login itself is generic.
2. Break-glass access triggers an immediate alert and a mandatory justification review within a fixed, documented window.
3. Non-employee populations (locums, agency staff, students, outsourced vendors) are covered by the same leaver process as permanent staff, with a defined maximum time-to-deprovision.
4. Administrative access to the EHR, PACS and directory runs through a controlled, session-recorded path rather than standing domain credentials, which is where a zero trust approach to internal access actually pays off in a clinical environment.
5. Role definitions map to real clinical workflows, and the highest-risk roles (physician, pharmacist, system administrator) have attribute- or relationship-based refinement on top of the base role.