HIPAA Security Rule: Technical Safeguards Explained

1Access Controls (§ 164.312(a)(1))

Access controls restrict who can access ePHI to only those persons or software programs that have been granted access rights. This is one of the most foundational — and most commonly cited — HIPAA technical requirements.

Unique User Identification (Required)

Every user who accesses ePHI must have a unique identifier — typically a username or user ID. This is a required implementation specification. Shared accounts, generic logins, or group credentials are not acceptable under HIPAA. Unique IDs enable accountability: every action taken in the system can be traced to an individual user.

Emergency Access Procedure (Required)

Organizations must establish procedures for obtaining ePHI during emergencies. This is a required specification — you must have a documented process that allows authorized personnel to access critical ePHI even when normal authentication mechanisms are unavailable (e.g., a system outage or disaster recovery event).

Automatic Logoff (Addressable)

Systems that handle ePHI should implement automatic session termination after a defined period of inactivity. While addressable, automatic logoff is considered standard practice and virtually all HIPAA auditors expect it. Typical timeouts range from 5 to 30 minutes depending on the risk environment. Clinical settings often use longer timeouts; administrative systems with access to sensitive PHI should use shorter ones.

Encryption and Decryption (Addressable)

HIPAA does not mandate a specific encryption algorithm, but it requires that organizations implement a mechanism to encrypt and decrypt ePHI as an addressable specification under access controls. In practice, encryption of ePHI at rest is universally expected. NIST recommends AES-256 for data at rest. Organizations that do not encrypt ePHI at rest must document a compelling reason — which is rarely accepted during audits or breach investigations.

2Audit Controls (§ 164.312(b))

Audit controls are a required specification with no addressable sub-components. Organizations must implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

Hardware Audit Controls

Physical access logs, badge readers, and device inventory systems track which hardware interacts with ePHI environments. For servers and workstations, BIOS logs and hardware security modules (HSMs) provide an additional audit layer.

Software Audit Controls

Application-level audit logs must capture, at minimum: who accessed ePHI, what they did (view, create, modify, delete), when the activity occurred, and from where (IP address, device). These logs must be tamper-evident — meaning users should not be able to modify or delete their own audit trail. Storing audit logs in an append-only data store or shipping them to a centralized SIEM (Security Information and Event Management) system is best practice.

Procedural Audit Controls

Beyond technical logging, organizations need documented procedures for regularly reviewing audit logs. Who reviews them? How often? What triggers an investigation? HIPAA requires that audit logs be not just collected, but reviewed. Automated anomaly detection tools can flag suspicious access patterns and reduce the manual burden of log review.

3Integrity Controls (§ 164.312(c)(1))

Integrity controls ensure that ePHI is not improperly altered or destroyed. Organizations must protect ePHI from unauthorized modification or tampering — both in storage and in transit.

Authentication of ePHI (Addressable)

Organizations should implement mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Common technical approaches include:

• Cryptographic hashing: Computing SHA-256 or SHA-3 hashes of records and storing them separately. Any unauthorized modification changes the hash.
• Digital signatures: Signing ePHI documents to provide both integrity verification and non-repudiation.
• Database triggers and versioning: Immutable record histories that preserve every version of an ePHI record with timestamps and user attribution.
• Checksum validation: Validating file integrity on upload and download to detect corruption or tampering.

For EHR systems specifically, FHIR R4 audit resources (AuditEvent) provide a standardized mechanism for tracking ePHI access and changes with integrity guarantees built into the standard.

4Transmission Security (§ 164.312(e)(1))

When ePHI is transmitted over electronic communications networks, technical security measures must guard against unauthorized access. This applies to APIs, web applications, mobile apps, HL7 interfaces, FHIR endpoints, and any other channel that carries ePHI.

Integrity Controls in Transit (Addressable)

Organizations should implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection. TLS (Transport Layer Security) provides integrity protection in addition to encryption for data in transit.

Encryption in Transit (Addressable)

All ePHI transmitted over networks must be encrypted. While technically “addressable,” transmission encryption is non-negotiable in practice:

• All web interfaces must use HTTPS with TLS 1.2 or higher (TLS 1.3 preferred). HTTP must be disabled or redirected.
• APIs serving ePHI must enforce TLS and validate certificates. Certificate pinning is recommended for mobile applications.
• HL7 v2 interfaces (MLLP) carrying ePHI must be wrapped with TLS or transmitted over encrypted VPNs.
• FHIR REST APIs must implement OAuth 2.0 with SMART on FHIR for authentication, combined with TLS for transport security.
• Email containing ePHI must be encrypted end-to-end. Plain-text email is not acceptable for ePHI transmission.

Summary: Required vs. Addressable

Note: “Addressable” does not mean optional. Organizations must implement addressable specifications if reasonable and appropriate, or document why an equivalent alternative is used.

Putting It All Together

HIPAA technical safeguards are not just a compliance checkbox — they are fundamental security engineering principles that protect patient privacy and prevent costly data breaches. The average cost of a healthcare data breach in 2024 exceeded $10 million, and HIPAA violations can result in civil penalties ranging from $100 to $50,000 per violation (up to $1.9 million per category per year).

For software developers building healthcare applications, these requirements translate into concrete engineering decisions: choosing the right encryption libraries, designing immutable audit log systems, implementing session management, and securing API endpoints with mutual TLS or OAuth 2.0.

Working with a HIPAA-experienced development partner ensures that these safeguards are built into your system architecture from the start — not bolted on after the fact. Taction Software has implemented HIPAA technical safeguards in 100+ healthcare applications over 18+ years.