45 CFR 164.312 Explained: HIPAA Technical Safeguards in Full
45 CFR 164.312 is the section of the HIPAA Security Rule that defines technical safeguards for electronic protected health information. It contains five standards and several implementation specifications, each marked required or addressable. This clause-by-clause reference explains every provision, its citation, its status and what it means in software. Need implementation help? Talk to our team. For a plain-language overview first, read our guide to the HIPAA Security Rule technical safeguards. This page is not legal advice; confirm interpretations with qualified counsel. Citations follow the current regulation text.
How 45 CFR 164.312 Is Structured
The HIPAA 164.312 section contains five standards, labeled (a) through (e). Some standards include implementation specifications, which are marked either required or addressable. Required specifications must be implemented. Addressable specifications must be assessed: you implement them if reasonable and appropriate, implement an equivalent alternative, or document why neither applies. Understanding this structure is essential before reading each clause, because most compliance mistakes start with misunderstanding what addressable actually means. The key terms are explained below.
Standards and Implementation Specifications
Standards state the overall requirement, such as access control. Implementation specifications describe specific ways to meet that standard, such as unique user identification or automatic logoff controls. Each standard is covered below.
What Required Means
Required specifications, explained in our HIPAA compliance guide, must be implemented as described. There is no option to document an alternative, so every covered entity and business associate handling ePHI must implement them fully. No exceptions apply.
What Addressable Means
Addressable does not mean optional. You must assess each addressable specification, then implement it, implement an equivalent alternative measure, or document why neither is reasonable and appropriate. The decision must be justified.
Documentation Obligations
Decisions about addressable specifications must be documented and retained. Auditors expect to see the reasoning, the risk analysis behind it and any alternative controls implemented instead. Keep documentation for six years, as the Security Rule requires.
Proposed Changes to the Rule
HHS proposed Security Rule updates in January 2025 that would make most addressable specifications required. Check the current status of that rulemaking before finalizing your compliance approach. Timelines remain uncertain.
164.312(a): Access Control
The access control standard at 45 CFR 164.312(a)(1) requires technical policies and procedures that allow access to ePHI only for persons or software programs granted access rights. It is the foundation of every other technical safeguard. The standard includes four implementation specifications: two required and two addressable. In software, access control affects authentication design, authorization models, session handling, emergency workflows and encryption of stored data across every system component. Each specification is explained below.
164.312(a)(2)(i) Unique User Identification — Required
Assign a unique name or number to identify and track each user. In software, this means individual accounts for every user and service, with no shared logins that hide who performed actions.
164.312(a)(2)(ii) Emergency Access Procedure — Required
Establish procedures for obtaining necessary ePHI during emergencies. In software, this usually means break-glass access workflows that grant temporary elevated access, require justification and generate prominent audit records. Review every use afterward.
164.312(a)(2)(iii) Automatic Logoff — Addressable
Implement electronic procedures that terminate sessions after inactivity. HIPAA sets no timeout duration, so organizations choose durations by context and enforce them server-side, not only with client timers. Document your chosen durations.
164.312(a)(2)(iv) Encryption and Decryption — Addressable
Implement a mechanism to encrypt and decrypt ePHI. In practice, encrypt databases, files and backups at rest, manage keys securely and document any reasoned exceptions in your risk analysis. Rotate keys regularly.
Designing Role-Based Access
Role-based access control implements the standard by mapping job functions to permissions. Apply least privilege, review roles regularly and remove access promptly when staff change roles or leave. Document every role clearly.
164.312(b) and 164.312(c): Audit Controls and Integrity
The audit controls standard at 164.312(b) requires hardware, software or procedural mechanisms that record and examine activity in systems containing ePHI. It has no separate implementation specifications, so the standard itself applies directly. The integrity standard at 164.312(c)(1) requires policies protecting ePHI from improper alteration or destruction. Both standards shape logging design, data validation and change tracking, which are often underbuilt in healthcare applications and integration environments today. Our HIPAA software development checklist covers practical steps.
164.312(b) Audit Controls — Standard
Record and examine activity involving ePHI, including reads, not just writes. Capture user, record, action, timestamp and source, protect logs from tampering and review them on a defined schedule. This standard is required.
Examining Activity, Not Just Recording It
HIPAA expects logs to be reviewed. Define who reviews them, how often, which events trigger investigation and how findings are documented, because unreviewed logs provide limited compliance value. Keep review records.
164.312(c)(1) Integrity — Standard
Implement policies and procedures to protect ePHI from improper alteration or destruction. This covers database changes, file corruption, integration errors and unauthorized modification by users or processes. This standard is required.
164.312(c)(2) Mechanism to Authenticate ePHI — Addressable
Implement electronic mechanisms to confirm ePHI has not been altered or destroyed improperly. Common approaches include checksums, hashing, digital signatures, row versioning and immutable audit trails. Choose methods proportionate to your risk analysis findings.
Integrity in Integration Workflows
A transformation that silently drops a segment or result is an integrity failure, not just a bug. Validate interface outputs, reconcile message counts and alert on unexpected data changes. Document every incident.
164.312(d) and 164.312(e): Authentication and Transmission Security
The person or entity authentication standard at 164.312(d) requires procedures verifying that anyone seeking access to ePHI is who they claim to be. The transmission security standard at 164.312(e)(1) requires technical measures guarding against unauthorized access to ePHI transmitted over networks. Together, they cover how users and systems prove identity and how data stays protected in transit, which matters for apps, APIs and HL7 integration interfaces alike. See our HIPAA compliant app development guide for apps.
164.312(d) Person or Entity Authentication — Standard
Verify identity before granting access. Use strong passwords with multi-factor authentication for users, and certificates, signed tokens or mutual TLS for systems, applications and integration partners. This standard is required and has no implementation specifications.
Authentication for APIs and Services
APIs should use OAuth 2.0 with short-lived tokens, and backend services should authenticate with signed assertions or client certificates. Avoid static API keys shared across systems and environments. Rotate credentials regularly.
164.312(e)(2)(i) Integrity Controls — Addressable
Implement security measures ensuring transmitted ePHI is not improperly modified without detection. TLS provides integrity protection in transit, while message-level validation catches problems TLS cannot detect. Both layers work together.
164.312(e)(2)(ii) Encryption — Addressable
Implement a mechanism to encrypt ePHI in transit whenever appropriate. Use TLS 1.2 or higher for web, API and MLLP traffic, and encrypt file transfers using SFTP or equivalent protocols.
Commonly Missed Transmission Paths
Teams often secure web traffic but miss HL7 MLLP feeds, internal service calls, database connections, email notifications and webhook callbacks. Inventory every path carrying ePHI and secure each one. Review it annually.
Frequently Asked Questions
What does 45 CFR 164.312 cover?
45 CFR 164.312 defines the technical safeguards of the HIPAA Security Rule. It includes five standards: access control, audit controls, integrity, person or entity authentication and transmission security. Several standards include implementation specifications marked required or addressable, which covered entities and business associates must implement or assess and document.
What are the five technical safeguards under 164.312?
The five technical safeguards are access control at 164.312(a), audit controls at 164.312(b), integrity at 164.312(c), person or entity authentication at 164.312(d) and transmission security at 164.312(e). Together, they govern who can access ePHI, how activity is recorded, how data is protected and how it moves.
Is encryption required under 164.312?
Encryption at rest under 164.312(a)(2)(iv) and in transit under 164.312(e)(2)(ii) are addressable, not required. You must still assess them and implement encryption, an equivalent alternative, or documented reasoning. In practice, encryption is expected for nearly all modern systems, and it supports breach notification safe harbor protections.
What does addressable mean in HIPAA?
Addressable means an implementation specification must be assessed rather than automatically implemented. If reasonable and appropriate, you implement it. If not, you implement an equivalent alternative or document why neither applies. Addressable never means optional, and decisions must be documented and supported by your risk analysis.
What does 164.312(b) audit controls require?
164.312(b) requires hardware, software or procedural mechanisms that record and examine activity in information systems containing or using ePHI. That includes logging access, including reads, protecting logs from tampering and reviewing them regularly. Unreviewed logs do not fully satisfy the requirement to examine system activity.
Has the HIPAA Security Rule changed recently?
HHS published a proposed rule in January 2025 that would significantly update the Security Rule, including making most addressable specifications required and adding new technical requirements. Proposed rules can change or stall before finalization, so check the current status with HHS or qualified counsel before relying on either version.
Need Help Implementing 164.312 Safeguards?
Our integration engineers are ready to help. Free consultation, no obligation.