HIPAA Technical Safeguards Explained for IT Teams

HIPAA technical safeguards are the technology controls the HIPAA Security Rule requires to protect electronic protected health information (ePHI). They are set out in 45 CFR 164.312 as five standards: access control, audit controls, integrity, person or entity authentication, and transmission security.

Each standard has more specific requirements under it, called implementation specifications. There are seven. Two are required: unique user identification and an emergency access procedure. The other five are "addressable": you assess each one, then either do it or write down why you used something else instead.

This guide is for the IT admins and MSPs who have to turn the rule into settings. For each standard it covers what the text says, what to configure on servers, laptops and phones, and what an auditor will ask to see.

Download the HIPAA checklist (PDF + Excel)

TL;DR

What are the HIPAA technical safeguards?

The Security Rule splits its safeguards into three groups: administrative (164.308), physical (164.310) and technical (164.312). Technical safeguards are the controls built into the technology itself: who can sign in, what gets logged, and how data is protected when stored and when sent.

The rule covers providers, health plans and clearinghouses (covered entities) and the vendors that handle patient data for them (business associates). If an MSP manages devices that hold ePHI, it is covered too.

Your EHR vendor does part of this for you. In a cloud EHR, the vendor runs much of the logging, integrity and backup inside the application. That vendor is a business associate. Get its business associate agreement, ask which safeguards it covers, and keep its answer with your risk analysis. Everything outside the EHR, starting with the devices people use to reach it, is still yours.

R means required and A means addressable. The rule is technology-neutral on purpose: it names outcomes, not products. That is why two clinics can meet the same standard with different tools.

1. Access control (164.312(a))

The standard: allow access to ePHI "only to those persons or software programs that have been granted access rights". It has four specifications.

Unique user identification (required)

Every person who touches ePHI gets their own account, so every action can be traced to one person. Shared logins at nurse stations, labs and front desks are the most common way clinics break this. Staff share a login because signing in and out of a shared workstation is slow.

Fix the speed problem and the sharing usually stops. Fast user switching, tap-badge sign-in and a short screen lock on shared machines all help. If a system can't support named accounts, note it in your risk analysis with the compensating controls you use.

Enforcement example. In September 2026, Ambry Genetics agreed to pay $700,000 after a phishing attack affecting 225,370 people. One of the potential violations identified by HHS's Office for Civil Rights (OCR), which enforces HIPAA, was not assigning unique user IDs in systems that held ePHI.

Emergency access procedure (required)

A written, tested way to reach ePHI when normal access fails: an outage, a locked-out admin, a disaster. In practice this is usually an emergency admin account, often called a break-glass account, whose password stays sealed until it is needed. Keep it sealed, alert on every use, and review each use afterwards. Test it once a year, because a break-glass password nobody can find is not a procedure.

Automatic logoff (addressable)

End or lock a session after "a predetermined time of inactivity". HIPAA does not set the number of minutes, so you choose it based on risk. Use a short timeout on shared workstations in clinical areas and a longer one in private offices. Write both numbers and the reason in your policy.

Expect pushback from clinicians who lose work to screen locks. A lock that resumes the session with a quick sign-in is usually accepted. A full logoff that closes the EHR usually isn't.

Encryption and decryption (addressable)

Encrypt ePHI at rest: laptops, desktops, phones, tablets, removable drives and servers. On endpoints this means BitLocker on Windows, FileVault on macOS, and a passcode on iOS and Android so built-in encryption is active. Store the recovery keys centrally, away from the devices. See our guide to full-disk encryption for the setup.

Enforcement example. HHS has settled several cases over stolen unencrypted laptops. In 2020, Lifespan Health System paid $1,040,000 after the theft of an unencrypted laptop holding ePHI on 20,431 people. OCR found Lifespan had decided encryption was reasonable and appropriate, and then didn't encrypt its laptops.

2. Audit controls (164.312(b))

The standard: put in place "hardware, software, and/or procedural mechanisms that record and examine activity" in systems that contain or use ePHI. It has no specifications, so it must be met as written.

Note the two verbs: record and examine. Turning logging on is half the job. The other half is reviewing the logs, which a separate HIPAA rule (164.308(a)(1)(ii)(D)) requires you to do regularly.

• What to log: sign-ins and failed sign-ins, record access in the EHR, admin changes, permission changes, exports and deletions.
• Where: the EHR, email, file storage, identity provider, firewall and VPN, and your device management console.
• How often to review: the rule sets no frequency. Pick one you will keep, such as weekly alerts plus a monthly review, and record who reviewed what and when.
• Keep: the review records and your logging policy for six years (164.316(b)(2)). Protect the logs from editing.

Small teams often stall on how much of the EHR log to review. Start with alerts for the high-risk events: access to staff or VIP records, bulk exports, and sign-ins at odd hours. Then sample the rest.

Enforcement example. Montefiore Medical Center paid $4.75 million in February 2024. An employee had stolen and sold data on 12,517 patients, and it went unnoticed for about two years. OCR's potential violations included not having audit controls that record and examine activity.

3. Integrity (164.312(c))

The standard: protect ePHI "from improper alteration or destruction". The addressable specification asks for a mechanism to confirm that ePHI hasn't been changed or destroyed without authorization.

Ransomware is the most common real-world test of this safeguard. In practice it means:

• Least-privilege write access, so only the right people and systems can change records.
• Versioning and change history in the EHR and file storage, so a change can be seen and rolled back.
• Checksums, hashes or digital signatures where data moves between systems or is archived.
• Backups that can't be edited or deleted from the production network, and test restores that prove them.
• Anti-malware and patched systems, since malware is a common way records get altered or destroyed.

4. Person or entity authentication (164.312(d))

The standard: verify that a person or entity seeking access to ePHI "is the one claimed". It has no specifications. "Entity" covers systems too, such as an app calling an API or a device joining your network.

Does HIPAA require MFA? The current rule does not mention it. But a password alone is hard to defend after a phishing breach, and MFA is one of the essential goals in HHS's voluntary cybersecurity performance goals for healthcare. The January 2025 proposed rule would make it mandatory. Put it first on email, remote access, the EHR and admin consoles. Our guide to multi-factor authentication covers the options.

Where phones aren't allowed on the clinical floor, app-based MFA fails. Hardware security keys or badge-based sign-in work there. On devices, enforce passcode length, complexity and lockout after failed attempts, so a lost phone can't simply be guessed open.

Enforcement example. Providence Medical Institute was fined $240,000 in October 2024 after three ransomware attacks, including for access control failures. OCR's notice records that staff at an acquired practice were sharing generic logins with administrator rights.

5. Transmission security (164.312(e))

The standard: guard against unauthorized access to ePHI "being transmitted over an electronic communications network". It has two addressable specifications: integrity controls, which detect changes in transit, and encryption.

• Web and apps: TLS 1.2 or later everywhere ePHI moves. Turn off old SSL and TLS versions.
• Remote access: a VPN or a similar secure remote-access service, never a remote desktop port open to the internet.
• Wi-Fi: WPA2 or WPA3 Enterprise with certificates on staff networks, and a separate guest network.
• Email: TLS between mail servers, plus a secure message option for ePHI sent outside the organization. Test any "encrypt all outgoing mail" rule before you switch it on. Rules that encrypt every outgoing message often break ticket replies and automated mail.

Required vs addressable: what "addressable" means

Five of the seven specifications are addressable. The word is often misread as "optional". Under 164.306(d)(3), you must assess whether the specification is reasonable and appropriate for you. If it is, you implement it. If it isn't, you document why and implement an equivalent alternative if one is reasonable.

In practice, few organizations can defend not encrypting laptops or not locking idle screens. The tools are built into every major operating system, and auditors know it. Treat "addressable" as "required unless you can write a convincing reason". Keep that reason with your risk analysis.

Is encryption required under HIPAA?

Not strictly. Encryption at rest and in transit are both addressable. But encryption decides what happens when a device goes missing, and that makes it close to mandatory in practice.

HHS guidance on unsecured PHI says that ePHI encrypted to NIST standards is not "unsecured", as long as the key wasn't also compromised. In practice, BitLocker, FileVault and a phone passcode meet this for devices, and TLS or a modern VPN meets it in transit. The NIST references are SP 800-111 for stored data and SP 800-52, 800-77 or 800-113 for data in transit. A lost laptop with properly managed full-disk encryption is generally not a reportable breach. The same laptop unencrypted usually is, with letters to every patient on it, a report to HHS and, if more than 500 residents of a state are affected, the media.

Two details matter. The recovery key must not travel with the device: store it in your management console or directory, not on a sticky note in the laptop bag. And you need proof the device was encrypted when it was lost, which means encryption status reports, not a policy that says encryption is on.

Technical safeguards on laptops, phones and personal devices

Most of the technical safeguards end up as settings on endpoints. A laptop that leaves the building with ePHI on it tests access control, authentication and encryption at once. The rule names no products, but the settings are the same everywhere:

Personal devices (BYOD) are allowed if your policy says what they need and you can show they have it. Many practices keep ePHI off personal phones entirely. Others require a passcode, a work profile or managed apps, and an agreement that lets IT remove work data. Write the choice down in your BYOD policy. Our post on PHI on mobile devices covers the details.

Lost and stolen devices need a written procedure: lock it, locate it if you can, wipe it if it won't come back, then check encryption status and decide whether it is a breach. An encryption status report from your device management tool makes that last step quick.

How to show an auditor your technical safeguards work

When OCR investigates, it asks for documents, not a demo. Policies say what you planned. Reports and logs show the controls actually ran. Keep your policies and the records of required activities (risk analysis, log reviews, addressable decisions) for six years from when they were created or last in effect (164.316(b)(2)). Many teams keep supporting reports for the same period.

Generate device reports on a schedule, not on request. A screenshot proves one moment. Twelve dated monthly reports prove a control was in place all year.

All of these items, with an owner, a frequency and the evidence column, are in our HIPAA compliance checklist. Look for the items in the Access, Devices, Network and Audit sections.

Get the HIPAA checklist with all 76 controls

What the proposed 2025 Security Rule would change

Most of these are already good practice, and some are already in OCR's corrective action plans. If you are setting up controls now, use the proposed rule as a guide. Encryption, MFA, account lockout and separate admin accounts are the cheap wins, and you won't have to redo them if the rule is finalized.

Technical vs administrative vs physical safeguards

The three groups overlap, and the same device policy often touches all of them:

The HIPAA guide for small businesses walks through all three for smaller practices. The minimum necessary standard explains how much access each role should get.

How trio.so helps with the device side

Does a device management tool make you HIPAA compliant? No. Policies, risk analysis, training and your EHR's own controls stay with you. What trio.so does is enforce many of the device settings above, and show encryption status for each device:

• Encryption: enforce BitLocker on Windows and FileVault on Mac, and see encryption status for each enrolled Windows and Mac device.
• Automatic logoff: set an inactivity lock on Windows, macOS, iOS and Android.
• Authentication on devices: set passcode length, complexity and lockout rules.
• Transmission security: push Wi-Fi, VPN and certificate profiles.
• Lost devices: lock a lost Mac, iPhone or Android device, locate company-owned phones, and wipe company-owned devices remotely.
• Audit controls: an event log of which admin changed what and when, with export, plus device logs.
• Console access: SAML single sign-on, MFA for console sign-in, and roles for your admins.

Learn more about compliance automation and device management for healthcare.

Start free trial Book a demo

14-day free trial. No credit card required.

Sources. Last reviewed October 2026. This article is general guidance, not legal advice.

• 45 CFR 164.312, Technical safeguards (eCFR)
• 45 CFR 164.306, Security standards: general rules (eCFR)
• 45 CFR 164.304, Definitions (eCFR)
• HHS, Guidance to render unsecured PHI unusable, unreadable or indecipherable
• NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule (2024)
• Federal Register, HIPAA Security Rule NPRM, 90 FR 898 (January 6, 2025)
• Unified Agenda entry, RIN 0945-AA22
• HHS, Healthcare and Public Health Cybersecurity Performance Goals
• HHS OCR, Resolution agreements and civil money penalties