The HIPAA Security Rule is organized into three safeguard categories: administrative, physical, and technical. The Technical Safeguards section (45 CFR § 164.312) gets a disproportionate amount of attention in vendor marketing — usually to sell you something. Here's what it actually requires without the upsell.
The Structure: Required vs. Addressable
Before getting into the specific standards, understand what "required" and "addressable" mean in the Security Rule. These aren't categories of importance — they're instructions for implementation.
Required means you must implement it. No analysis needed, no alternatives.
Addressable means you must assess whether the specification is reasonable and appropriate for your environment given your risk analysis. If it is, implement it. If it isn't, you must document why and implement an equivalent alternative — or document why no alternative is appropriate.
Critically: addressable does not mean optional. This is the most common misreading of the Security Rule. The HHS guidance is explicit on this point. If you skip an addressable specification without documentation, you're out of compliance.
In practice, most addressable specifications — especially encryption — are nearly universal. The bar for documenting why encryption isn't reasonable and appropriate is very high. Don't count on that argument holding up in an enforcement action.
The Five Technical Safeguard Standards
1. Access Control — §164.312(a)(1)
Implement technical policies and procedures that allow only authorized persons or software programs to access ePHI.
Four implementation specifications:
Unique user identification (Required): Assign a unique name or number to each user so you can track individual activity. Shared accounts for clinical workstations are a common violation here. Every person who accesses ePHI needs their own credentials.
Emergency access procedure (Required): Establish a procedure for obtaining necessary ePHI during an emergency, including when normal authentication processes aren't available. This is often underdocumented — organizations have break-glass accounts but no formal procedure for when to use them or how to audit use afterward.
Automatic logoff (Addressable): Implement an electronic procedure that terminates a session after a defined period of inactivity. Most organizations implement this. If you don't, document why your risk analysis indicates it's not appropriate (it's a hard argument to make when workstations are in shared spaces).
Encryption and decryption (Addressable): Implement a mechanism to encrypt and decrypt ePHI. This covers ePHI at rest — on hard drives, backup media, portable devices, and cloud storage. Most organizations implement this for laptops and mobile devices at minimum. If you're not encrypting ePHI at rest on any endpoint or storage system, document your reasoning.
2. Audit Controls — §164.312(b)
Implement hardware, software, and/or procedural mechanisms to record and examine activity in information systems that contain or use ePHI.
No implementation specifications — this standard is entirely required. You need audit logs. You need to examine them. What "examine" means in practice: periodic log review (at minimum), with more frequent review if you have a SIEM or equivalent alerting capability.
Common gap: organizations have audit logging enabled but no process for reviewing the logs. The logs exist; no one looks at them. That doesn't satisfy this standard.
3. Integrity — §164.312(c)(1)
Protect ePHI from improper alteration or destruction.
One addressable implementation specification:
Authentication of ePHI (Addressable): Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Hash verification, digital signatures, and file integrity monitoring are common approaches. This is more about protecting data integrity than authentication in the access-control sense.
4. Person or Entity Authentication — §164.312(d)
Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.
This is entirely required, with no implementation specs listed. In practice, it means authentication mechanisms — and most auditors expect multi-factor authentication for remote access to systems containing ePHI. MFA isn't explicitly required in the rule text, but failing to implement it while claiming this standard is satisfied is increasingly hard to defend given the current threat environment. OCR's 2024 HIPAA update proposals would make MFA explicitly required.
5. Transmission Security — §164.312(e)(1)
Implement technical security measures to guard against unauthorized access to ePHI transmitted over electronic communications networks.
Two addressable implementation specifications:
Integrity controls (Addressable): Security measures to ensure ePHI isn't improperly modified during transit without detection. TLS (which provides both encryption and integrity) satisfies both transmission specifications.
Encryption (Addressable): Implement encryption when deemed appropriate. Sending ePHI over unencrypted email is one of the most common Security Rule violations. Secure messaging platforms, encrypted email, and patient portals are the common implementations. If you're faxing clinical information, be aware that analog fax over PSTN is generally considered acceptable, but internet fax services have different considerations.
What This Looks Like in Practice
For a medical practice or healthcare-adjacent business, Technical Safeguards compliance typically requires:
- Unique credentials for every user with access to ePHI (no shared logins)
- Automatic screen lock on workstations in clinical areas
- Full-disk encryption on all laptops and mobile devices that touch ePHI
- Audit logging enabled on EHR systems, practice management software, and any system containing ePHI
- A defined process for reviewing those logs at least quarterly
- MFA for remote access (VPN, remote desktop, webmail with ePHI)
- TLS for all web applications handling ePHI
- Secure messaging or encrypted email for clinical communications outside the organization
- An emergency access procedure in writing
None of this requires expensive enterprise tooling. Most EHR systems have audit logging built in. Windows BitLocker and macOS FileVault handle endpoint encryption. The gaps are usually process gaps — logging is on but nobody reviews it, encryption is available but not enforced on every endpoint.
The Bigger Picture
The Technical Safeguards section doesn't exist in isolation. Everything here connects back to your Security Rule risk analysis (§164.308(a)(1)) — the required administrative safeguard that almost every enforcement action cites as missing or inadequate.
Your technical safeguard decisions should be driven by your risk analysis. If your risk analysis identifies unencrypted portable devices as a high risk, encryption isn't just addressable — it's the obvious treatment for that risk. The risk analysis and the technical safeguards document a consistent story.
SOURCES
- 45 CFR §164.312 — Technical Safeguards: ecfr.gov
- HHS, "Guidance on Addressable Implementation Specifications": hhs.gov/hipaa/for-professionals/security/guidance/addressable-implementation-specifications/index.html
- HHS, "Security Rule Guidance Material": hhs.gov/hipaa/for-professionals/security/guidance/index.html
- OCR, "Audit Protocol — Technical Safeguards": hhs.gov/hipaa/for-professionals/compliance-enforcement/audit/protocol/index.html
- HHS HIPAA Security Rule Summary (45 CFR Part 164, Subpart C): hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
Have questions about what Technical Safeguards compliance actually looks like for your practice or organization? Schedule a consultation to walk through what you need.
