🏥 HIPAA for Linux Servers

HIPAA Security Rule for Linux servers: the technical safeguards in plain English
Law: HIPAA Security Rule, 45 CFR Part 164 (technical safeguards: section 164.312)      Enforced by: HHS Office for Civil Rights (OCR)      Applies to: covered entities (providers, health plans, clearinghouses) and their business associates that handle electronic protected health information (ePHI)

The Security Rule requires "reasonable and appropriate" safeguards for ePHI. It is a law, but it is flexible and risk-based: it says WHAT to protect and leaves HOW to you, based on a risk analysis of your own environment. There is no official "HIPAA certification": any vendor claiming one is selling something else. This sheet shows how the technical safeguards look on a Linux server. It is not legal advice: talk to your compliance officer or counsel.
Facts were checked on 2026-09-29: the safeguard text against 45 CFR 164.312 and the rulemaking status against several 2026 sources (see "Rule changes on the way").

Administrative   Risk analysis and management, workforce training, access management, incident response, contingency (backup and recovery) plans, business associate agreements. The largest part of the rule.
Physical         Facility access, workstation and device controls.
Technical        Access control, audit controls, integrity, authentication, transmission security. This is the part that lives on your Linux servers. It is the subject of this sheet.

"Required" versus "Addressable" (people misread this all the time)
Required    You must implement it.
Addressable It is NOT optional. You must assess whether it is reasonable and appropriate for you. If yes, implement it. If not, document why and use an equivalent alternative (or explain why nothing is needed). In practice, encryption is expected almost everywhere.

Standard and specification                                       Status        On Linux
(a) Access control
    Unique user identification                                   Required      One person, one account: no shared or generic logins. Service accounts have an owner. SSH keys tied to a person.
    Emergency access procedure                                   Required      A documented "break-glass" way to reach ePHI in an emergency (a sealed admin account or console access), tested and logged.
    Automatic logoff                                             Addressable   SSH ClientAliveInterval/ClientAliveCountMax, shell TMOUT, screen lock on consoles and workstations.
    Encryption and decryption                                    Addressable   Disk encryption (LUKS), encrypted database volumes, encrypted backups, encrypted file shares.
(b) Audit controls                                               Required      Record and examine activity in systems with ePHI: auditd, journald (persistent), application audit logs, sent to a central log server, and actually reviewed.
(c) Integrity
    Mechanism to authenticate ePHI                               Addressable   Ways to show ePHI was not altered or destroyed improperly: file integrity monitoring (AIDE), database checksums, signed packages, restricted write access, versioned backups.
(d) Person or entity authentication                              Required      Verify the user is who they claim: SSH keys with passphrases, MFA, strong passwords, lockout after failed attempts.
(e) Transmission security
    Integrity controls                                           Addressable   Protect ePHI in transit from undetected change: TLS, SSH, VPN (IPsec, WireGuard).
    Encryption                                                   Addressable   Encrypt ePHI whenever appropriate: TLS 1.2 or newer everywhere it crosses a network, including internal links carrying ePHI.
The wording of each standard comes from 45 CFR 164.312. The Linux column is common practice, not text from the law.

Related requirements that matter to an admin (administrative safeguards, 45 CFR 164.308)
   - Risk analysis (required): a documented, current analysis of where ePHI lives and what threatens it. Everything else is chosen from it.
   - Contingency plan: data backup plan, disaster recovery plan and emergency mode operation plan are required. Test your restores.
   - Information system activity review (required): someone actually looks at the logs and reports.
   - Access management: give access by role, review it, and remove it promptly when people leave.
   - Documentation must be kept for six years (45 CFR 164.316). HIPAA does not name a fixed retention period for system logs. Many organisations keep logs for six years to line up with the documentation rule; ask your compliance officer.
   - Business associate agreements (BAAs) with every vendor that touches ePHI, including hosting and backup providers.

   1. Patch: automatic security updates plus a reboot process (unattended-upgrades or dnf-automatic).
   2. Individual accounts, SSH keys, no root logins, no shared logins, MFA for administrators.
   3. Default-deny firewall; only the ports the application needs; ePHI systems on their own network segment.
   4. Encrypt at rest (LUKS and encrypted backups) and in transit (TLS 1.2+, SSH, VPN).
   5. Auditd rules for authentication, account changes, sudo use and access to ePHI files; central, protected log server.
   6. Time sync (chrony) so log times can be trusted.
   7. File integrity monitoring (AIDE) and a regular review of the results.
   8. Automatic session timeouts and screen locks.
   9. Backups that are encrypted, off the machine, tested, and covered by a documented recovery plan.
   10. Remove what you do not use: services, packages, test accounts.
   11. A written risk analysis that lists these choices and the reasons for any "addressable" items you did differently.
See the Linux Hardening Basics sheet for the commands.

If a breach involves only ePHI that was properly encrypted (in the way HHS guidance describes), it is generally not treated as a breach of "unsecured" PHI, so notification duties may not apply. Encryption is therefore worth doing even where the rule calls it "addressable". Keys must be protected separately: encrypted data with the key stored next to it protects nothing. Ask your counsel how this applies to you.

Red Hat family: scap-security-guide ships a hipaa profile. It checks system settings that map to the technical safeguards, and cannot check policies, training or BAAs.
   oscap info --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
   sudo oscap xccdf eval --profile hipaa --results hipaa-results.xml --report hipaa-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Ubuntu: use a CIS profile (usg audit cis_level1_server) as your documented baseline. See the OpenSCAP, USG and Lynis sheet for commands and warnings.
Useful guidance: NIST SP 800-66 Revision 2 (published February 14, 2024, prepared with OCR), "Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide". It walks through each Security Rule standard with suggested activities and maps them to NIST controls.
Evidence to keep: the risk analysis and its updates, scan reports, account lists and access reviews, log samples showing the required events, backup and restore test records, encryption settings (lsblk -f, TLS scan results), training records and BAAs.

In January 2025 HHS published a Notice of Proposed Rulemaking (NPRM) to update the Security Rule. The proposals include: removing the required/addressable distinction so all specifications are required, mandatory encryption of ePHI at rest and in transit, multi-factor authentication, an asset inventory and network map, regular vulnerability scanning and penetration testing, annual risk analysis and stronger documentation, with limited exceptions.
Status as reported in mid-2026: the comment period closed on March 7, 2025; OCR has not issued a final rule; the federal regulatory agenda targets final action around July 2027 and those dates are not binding and can move. NOTHING in the NPRM is law today, and OCR continues to enforce the current Security Rule.
It is still smart to build toward it: encryption, MFA, inventories and regular testing are good practice now. Check HHS/OCR for the current status before you rely on any date.

"Addressable means optional, right?": no. It means you must assess it and either implement it or document a reasoned alternative.
"We encrypted the disk, so we are done": disk encryption protects a stolen or discarded disk, not a running system that an attacker or a careless admin can read. Add access control, audit logs and encryption in transit.
"Everybody shares the 'admin' account": that breaks unique user identification (required). Give every person their own account and use sudo.
"We keep logs but nobody looks at them": the rule expects information system activity review. Set up alerts and a schedule, and record that it happened.
"Our cloud provider is HIPAA compliant, so we are": no. Providers offer HIPAA-eligible services under a BAA, but you are still responsible for your own configuration, access and logging (the shared responsibility model).
"We have a firewall so segmentation is done": ePHI systems still need their own rules and their own admin path.
"Restores never tested": a backup plan you have not restored from is not much of a contingency plan.

Start with a risk analysis: it tells you where the ePHI is, and often shows you can shrink the number of systems that hold it.
Log access to ePHI, not just logins. Auditors and investigators want to know who read what.
Use MFA for administrators now. It is inexpensive, and it is where the proposed rule is heading.
Keep the policies short and real. A ten-page policy you follow beats a hundred pages you do not.
Encryption without key management is theatre. Decide who holds keys and how they rotate.
"We take your privacy seriously" belongs on the website, and in the audit logs.

45 CFR 164.312, technical safeguards:            https://www.law.cornell.edu/cfr/text/45/164.312
HHS, HIPAA Security Rule:                          https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
NIST SP 800-66 Rev. 2 (published Feb 14, 2024):    https://csrc.nist.gov/News/2024/nist-publishes-sp-80066-revision-2-implementing-th
Proposed rule (NPRM, Jan 6, 2025):                 search federalregister.gov for "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information"
Rule status explainer (updated June 2026):         https://medcurity.com/hipaa-security-rule-2026-update/
Red Hat, compliance scanning (RHEL 9):             https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/scanning-the-system-for-configuration-compliance-and-vulnerabilities_security-hardening