5.4 Cloud, Devices, and Identity Infrastructure

5.4 Cloud, Devices, and Identity Infrastructure

Quick Answer: Cloud, IoMT, and identity change where ePHI lives, not who is responsible for it. CPHIMS expects BAA-aware IaaS/PaaS/SaaS choices, unmanaged-device assumptions for medical equipment, and SSO, MFA, and privileged-access design.

Why this cluster is one section

/practice/cphimsPractice questions with detailed explanations

IaaS, PaaS, SaaS — and the BAA

Exam trap: cloud does not transfer HIPAA duty. The covered entity remains responsible for the Security Rule. The vendor is a business associate when it creates, receives, maintains, or transmits ePHI. A BAA is necessary and not sufficient. You still perform risk analysis, access reviews, encryption decisions, and incident coordination. HITECH made business associates directly liable for the Security Rule, but your board still owns the patient relationship.

Points CPHIMS loves:

• No ePHI in a consumer cloud (personal file share, unsanctioned generative-AI chat) — that is a missing BAA and an impermissible disclosure.
• Shared-responsibility matrix in the contract and architecture review, not only a slide.
• Data residency, encryption keys, and exit (how do you extract CCD, FHIR, or bulk data if you leave).
• Admin consoles are privileged systems; they need MFA and just-in-time access.
• Subcontractors — the BAA must flow down.

An IaaS BAA does not encrypt your database for you. If you lift unencrypted VMs into a public region and leave the same flat directory trusts you had on-premises, you have moved the problem closer to the internet. SaaS is not “the vendor is now the covered entity.” IaaS is not “only SaaS needs a BAA.” An NDA is not a BAA.

Medical devices and IoMT

Internet of Medical Things (IoMT) includes infusion pumps, monitors, imaging modalities, smart beds, RTLS tags, and connected implants’ gateways. They are often unmanaged endpoints: old operating systems, no agent, default passwords, vendor-only patch windows, and 10–15 year service lives.

Design rules:

1. Assume they cannot be hardened like a laptop. Isolate on biomedical VLANs; no general internet; no clinical workstation browsing from the same subnet.
2. Inventory is a safety control. You cannot patch or isolate a device you have not found.
3. Vendor remote access is a privileged path: brokered jump, time-bounded, logged, covered by a BAA if ePHI is reachable.
4. Clinical availability beats casual patching. Coordinate with biomed and the unit; a Wednesday noon pump reboot in the ICU is a harm event.
5. Default credentials are an incident, not a footnote.

Exam trap: medical devices are often unmanaged endpoints. Treating them as “clinical equipment, not IT” is how ransomware walks from a modality PC into the EHR. Treating them as ordinary PCs and forcing an OS upgrade that voids clearance is the opposite failure. The CPHIMS answer is segment, inventory, broker vendor access, and risk-assess—not “install EDR on the MRI,” and not “put the pumps on guest Wi-Fi so the drug library can update.” Many pumps are already on wireless for drug libraries and alarm middleware; “they are air-gapped” is frequently false.

Identity, SSO, and MFA

Identity infrastructure is the directory, lifecycle, federation, and authenticator stack.

• Single sign-on (SSO) lets a workforce identity open EHR, PACS, email, and HR through one authenticated session (SAML or OpenID Connect). It reduces password sprawl and centralizes revocation. It does not reduce the need for MFA or least privilege; a stolen SSO session is a master key.
• MFA adds a second factor (phish-resistant tokens preferred for admins). Remote access and cloud admin without MFA is an outdated design.
• Provisioning from the HR system (joiner / mover / leaver) is how you avoid the traveling-nurse account that never dies.
• Federation to affiliates and students needs scoped access and a clock.

Patient-facing identity (portals, apps) is a different trust domain: identity proofing, not the same directory as nurses. Do not put patient self-registration into the workforce forest. SMART on FHIR scopes from section 5.2 are how patient apps receive less than the entire chart even after the patient authenticates.

Privileged access

Privileged Access Management (PAM) covers domain admins, EHR database owners, cloud root, interface-engine admins, and biomed vendor IDs.

Minimum pattern:

• Separate privileged identities from daily-driver accounts.
• Just-in-time elevation with approval and expiry.
• Session recording or command audit on jump hosts.
• Vaulted passwords; no shared “admin/admin” on network gear or modalities.
• Break-glass accounts offline, dual-control, and tested.

Privileged access is where integrity and availability fail fastest: one unrestricted cloud key can delete the archive or open it to the world. Standing vendor support accounts that stay enabled all year are privileged access with no owner. Time-box them. Log them. Revoke them when the ticket closes.

Scenarios and traps

• Trap: “SaaS means the vendor is the covered entity.” No. You are still the covered entity; they are usually the business associate.
• Trap: “IaaS BAA covers our unencrypted database.” Shared responsibility leaves encryption and IAM to you.
• Trap: “SSO replaces MFA.” SSO concentrates risk; MFA is more important, not less.
• Trap: “Pumps are air-gapped so we can ignore them.” Many are on Wi-Fi for drug libraries and alarm middleware.
• Trap: “Vendor support accounts can stay enabled all year.” Time-box and log them.

A health system that lifts VMs to IaaS without a BAA, without disk encryption, and with the same flat directory trusts it had on-premises has not completed a cloud program. Cloud is a delivery model, not a control. Identity and device isolation are the controls that travel with the data.