SA-22 System Acquisition

Unsupported System Components

High Risk Complex High Cost

SA-22 requires replacing system components when support for the components is no longer available from the developer, vendor, or manufacturer — or providing alternative sources for continued support. Unsupported operating systems under imaging modalities, abandoned interface engines, and EOL antivirus on clinic PCs are classic ePHI risk concentrators.

Control Objective

Identify components that lack vendor support and replace them, or formally provide compensating support and isolation so unsupported technology does not silently undermine ePHI safeguards.

Implementation Guidance

  1. Inventory components with support end dates: OS, EHR modules, medical devices, middleware, libraries.
  2. Flag unsupported or soon-to-be-unsupported items in the risk register (RA-3).
  3. Prefer replacement or upgrade paths with clinical engineering and vendors.
  4. When replacement is delayed, document alternative support (extended contracts, in-house sustainment) plus compensating controls (segmentation, virtual patching, heightened monitoring).
  5. Prohibit new ePHI workloads on unsupported platforms without exception approval.
  6. Include biomedical and IoT clinical devices — not only servers.
  7. Track vendor EOL notices as an input to capital planning.
  8. Reassess exceptions at least quarterly until remediated.

Real-World Use Cases

How this control shows up in healthcare and HIPAA-covered environments.

Windows imaging workstation EOL

Radiology PCs running an unsupported OS still open studies with ePHI. SA-22 drives segmented VLAN, application allow-listing, and a funded replacement schedule.

Abandoned HL7 engine

Vendor bankrupt; engine still routes lab results. Alternative support agreement with a specialist firm is documented while migration to a supported broker proceeds.

Clinic buys used ultrasound on eBay

Device ships with obsolete embedded OS and no patch path. SA-22 acquisition gate blocks network connection until risk review and isolating controls are approved.

Best Practices

  • Living EOL dashboard tied to CM-8 inventory.
  • Capital planning aligned to support calendars.
  • Compensating controls when clinical care blocks immediate replace.
  • No new deployments on unsupported stacks.
  • Include devices and libraries, not only servers.
  • Time-box exceptions with owners.

Common Gaps & Violations

  • Unknown unsupported systems discovered only after ransomware.
  • “Clinical can’t upgrade” with no compensating controls.
  • Unsupported VPN appliances still exposing EHR.
  • Shadow apps on abandoned PaaS tiers.
  • EOL software still in PCI/ePHI shared zones.

Required Documentation

  • Unsupported component policy (SA-22)
  • Inventory of unsupported / approaching-EOL components
  • Replacement or alternative-support plans
  • Exception and compensating-control records
  • Network isolation evidence for deferred replacements

How to Test & Validate

  1. Compare CM-8 inventory to vendor support status samples.
  2. Verify unsupported items appear in risk treatment plans.
  3. Confirm compensating controls for deferred replacements.
  4. Check acquisition gates reject unsupported defaults.
  5. Review exception expiration and reassessment dates.

Audit Considerations

Unsupported systems are a favorite assessor finding because patch and vendor response obligations cannot be met. Documented isolation and replacement plans are expected when clinical constraints delay upgrades.

HIPAA Mapping

How this NIST control supports HIPAA Security Rule expectations.

  • 164.308(a)(1) Risk Analysis / Risk Management — unsupported components are identifiable risks requiring treatment.
  • 164.308(a)(5)(ii)(B) Protection from Malicious Software — outdated platforms weaken malware defenses.
  • 164.312(a) Access Control / 164.312(e) Transmission Security — encryption and access features may be unavailable on EOL platforms.
  • 164.306 General rules — reasonable and appropriate safeguards include sustaining supportable technology.

Compliance Tips

  • Feed vendor EOL bulletins into the same queue as vulnerability management.
  • Give clinical engineering shared ownership of device SA-22 items.
  • Report unsupported ePHI systems as a standing leadership metric.

Frequently Asked Questions

Can we keep an unsupported modality if it is air-gapped?

Possibly with documented alternative support and compensating controls — air-gap claims must be verified, and removable media risks addressed.

Does SA-22 require immediate replacement?

It requires replace or alternative support. Delayed replacement needs formal alternative support and risk treatment, not indefinite neglect.

Are SaaS apps ever “unsupported”?

Yes when the provider ends a product/version you still rely on — migrate or obtain continued support terms before security updates stop.

References & Resources

  • NIST SP 800-53 Rev. 5 — SA-22
  • Related controls: CM-8, RA-3, SI-2, SI-7, SR-3

Need Help Implementing SA-22?

Our auditors map NIST SP 800-53 controls to your HIPAA Security Rule program — policies, technical evidence, and audit readiness.