The technical safeguards are where compliance gets real

Administrative safeguards define your policies. Physical safeguards protect your building and hardware. Technical safeguards protect the data itself — inside the systems where it lives, moves, and gets accessed every day.

45 CFR § 164.312 contains five standards. Each standard has one or more implementation specifications classified as either required or addressable. Required means you must implement it. Addressable means you must assess whether it is reasonable and appropriate — and if you decide it is not, you must document why and implement an equivalent alternative. In practice, most addressable specifications have no viable alternative.

The 2025 HIPAA Security Rule NPRM, published January 6, 2025, proposes eliminating the addressable/required distinction entirely — making every specification mandatory. Whether or not that rule is finalized, the technical safeguards below represent the operational floor for any practice handling electronic protected health information (ePHI).

This reference covers every standard and specification in § 164.312, what it means in plain language, where independent practices most commonly fall short, and what compliant implementation looks like.

---

§ 164.312(a)(1) — Access control

Classification: Standard (required)

Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights.

Access control is the largest section in the technical safeguards and the one most frequently cited in OCR enforcement actions. It contains four implementation specifications.

§ 164.312(a)(2)(i) — Unique user identification (required)

Every person who accesses ePHI must have a unique identifier — a login that belongs to them alone.

What this means for your practice:

• No shared logins for the EHR, scheduling system, billing platform, or any system containing ePHI
• No generic accounts like "frontdesk@" or "billing1"
• Service accounts used by software (not humans) must be documented and restricted to their specific function
• When a staff member leaves, their credentials are revoked — not reassigned to the next hire

Where practices fail: Shared credentials are one of the most common findings in OCR investigations. When a breach occurs and you cannot prove who accessed what, every user of that shared account becomes a potential vector — and your audit trail is worthless.

For a deeper walkthrough of role mapping and implementation, see Step 6: Enforce Access Controls.

§ 164.312(a)(2)(ii) — Emergency access procedure (required)

You must have a documented procedure for obtaining necessary ePHI during an emergency — system outage, ransomware event, natural disaster — when normal access methods are unavailable.

What this means for your practice:

• A break-glass procedure documented, tested, and accessible to authorized personnel
• Emergency credentials stored securely (encrypted, physically separated from primary systems)
• Every emergency access event is logged and reviewed after the fact
• The procedure specifies who can invoke it, under what conditions, and what notification is required

Where practices fail: Most practices have no emergency access procedure at all. When a system goes down, staff either cannot access patient records or resort to workarounds that bypass every other safeguard — shared passwords texted between staff, sticky notes with admin credentials, or calling the IT vendor for a master login. Each of those workarounds is its own violation.

§ 164.312(a)(2)(iii) — Automatic logoff (addressable)

Electronic sessions must terminate after a predetermined period of inactivity.

What this means for your practice:

• EHR sessions: timeout after 5–10 minutes of inactivity
• Workstations: screen lock after 5 minutes
• Mobile devices: lock after 2 minutes or less, with biometric or PIN required to resume
• Remote access sessions (VPN, remote desktop): timeout after 10–15 minutes
• The timeout duration should be documented in your security policies

Where practices fail: The EHR may have a session timeout, but the workstation itself stays unlocked. A patient, cleaning crew member, or anyone with physical access can see whatever was on screen — scheduling data, clinical notes, insurance information. The specification requires the session to terminate, not just the application.

For device-level implementation details, see Step 5: Secure Devices and Endpoints.

§ 164.312(a)(2)(iv) — Encryption and decryption (addressable)

A mechanism to encrypt and decrypt ePHI.

What this means for your practice:

• ePHI at rest must be encrypted — full-disk encryption on workstations (BitLocker on Windows, FileVault on Mac), encrypted databases, encrypted backups
• ePHI on portable media (USB drives, external hard drives, laptops) must be encrypted
• Encryption must use a current, NIST-approved standard — AES-256 is the baseline

Where practices fail: The EHR vendor says "we encrypt everything," but the practice has no encryption on local workstations, no encryption on backup drives, and staff export patient lists to unencrypted USB drives for offsite work. The specification applies to the practice's entire environment — not just the EHR vendor's servers.

Why "addressable" is misleading: If you decide not to encrypt ePHI at rest, you must document why encryption is not reasonable and appropriate and implement an equivalent alternative measure. There is no equivalent alternative to encryption. OCR has consistently treated the absence of encryption as a deficiency, and the 2025 NPRM proposes making encryption a required specification.

Additionally, under the Breach Notification Rule, a lost or stolen device containing encrypted ePHI is not a reportable breach. A lost or stolen device containing unencrypted ePHI triggers mandatory notification to every affected patient, HHS, and potentially the media. Encryption is the single most effective safeguard against breach liability from device loss.

---

§ 164.312(b) — Audit controls

Classification: Standard (required)

Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

Audit controls require you to log access to ePHI and review those logs.

What this means for your practice:

• Every system containing ePHI must generate audit logs — who accessed what, when, and what action they performed (view, create, modify, delete, print, export)
• Logs must be retained for a minimum of six years (the HIPAA retention requirement for security documentation)
• Logs must be reviewed on a regular schedule — not just stored

Review cadence:

• Weekly: Failed login attempts, after-hours access, access from unusual locations or devices
• Monthly: User access patterns, privilege escalation events, bulk data exports, new user creation
• Quarterly: Full audit review aligned with risk assessment updates

Where practices fail: Most EHR systems generate audit logs. Most practices never look at them. A log that is never reviewed cannot detect unauthorized access, cannot identify insider threats, and cannot demonstrate compliance during an OCR investigation. "We have logging turned on" is not the same as "we have audit controls."

OCR enforcement actions — including settlements with Banner Health, Oklahoma State University, and Lifetime Healthcare — have specifically cited failures to implement audit controls and review system activity logs.

---

§ 164.312(c)(1) — Integrity

Classification: Standard (required)

Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

Integrity means ensuring that ePHI has not been changed or destroyed in an unauthorized manner. This applies to data at rest and data in motion.

§ 164.312(c)(2) — Mechanism to authenticate electronic protected health information (addressable)

Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

What this means for your practice:

• Database integrity checks — checksums or hash verification to detect unauthorized modification
• Version control or change tracking on clinical records
• File integrity monitoring on systems containing ePHI (detects unauthorized changes to system files, configurations, or data stores)
• Backup verification — confirming that restored data matches the original

Where practices fail: Integrity controls are the least understood technical safeguard. Most practices assume their EHR handles this — and the EHR vendor may implement some degree of integrity checking within their application. But the specification applies to your entire ePHI environment: local files, exports, backups, scanned documents, spreadsheets, and any other electronic format containing patient information.

Practical implementation for small practices:

• Ensure your EHR vendor documents their integrity controls (ask for specifics, not marketing language)
• Enable file integrity monitoring if your endpoint protection supports it (most modern business-grade solutions do)
• Verify backup integrity quarterly — restore a sample and confirm data matches
• Restrict who can modify, delete, or export records using role-based access controls

---

§ 164.312(d) — Person or entity authentication

Classification: Standard (required)

Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

Authentication verifies identity before granting access. This is distinct from access control (which determines what a verified user can do) — authentication establishes that the user is who they claim to be.

What this means for your practice:

• Username and password as a minimum — but passwords alone are increasingly insufficient
• Multi-factor authentication (MFA) for all systems containing ePHI — something you know (password) plus something you have (phone, hardware token) or something you are (biometric)
• The 2025 NPRM proposes making MFA a required specification for all ePHI access
• Authentication mechanisms for system-to-system communication (API keys, certificates, token-based auth) must be documented and secured

MFA implementation priorities:

1. EHR system — highest priority
2. Email (if used for any patient communication or contains ePHI)
3. Cloud storage (Google Workspace, Microsoft 365, Dropbox — any service with a BAA containing ePHI)
4. Remote access (VPN, remote desktop)
5. Practice management and billing systems
6. Administrative portals for any vendor handling ePHI

Where practices fail: Password-only authentication on systems containing ePHI is the single most exploitable gap in independent practices. The Change Healthcare breach — which exposed more than 190 million patient records and caused more than $2.8 billion in losses — began with stolen credentials used against a Citrix remote access portal that did not require multi-factor authentication. MFA would have stopped the attack at the door.

Password standards (until MFA is universal):

• Minimum 12 characters
• No password reuse across systems
• Use a password manager — do not rely on staff memory
• No default or factory passwords on any device or system
• Change all passwords and revoke access immediately upon employee termination

---

§ 164.312(e)(1) — Transmission security

Classification: Standard (required)

Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

Transmission security protects ePHI in transit — moving between systems, between your practice and a vendor, between a provider and a patient, or between any two endpoints on a network.

§ 164.312(e)(2)(i) — Integrity controls (addressable)

Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of.

What this means for your practice:

• Use protocols that include integrity verification — TLS includes this by default
• Verify that file transfers (ePHI exports, lab result imports, clearinghouse transmissions) use checksums or digital signatures
• Do not use protocols that lack integrity protection (unencrypted FTP, HTTP without TLS)

§ 164.312(e)(2)(ii) — Encryption (addressable)

Implement a mechanism to encrypt ePHI whenever deemed appropriate.

What this means for your practice:

• All ePHI transmitted over any network must be encrypted — TLS 1.2 at minimum, TLS 1.3 preferred
• Email containing ePHI must use encryption in transit. Standard email (SMTP without TLS) transmits in plaintext and is not compliant
• The "addressable" designation has the same practical reality as encryption at rest: there is no reasonable alternative. The 2025 NPRM proposes making transmission encryption required
• Wireless networks within your practice must use WPA3 (or WPA2 at minimum) — open or WEP-encrypted networks are not compliant

Email encryption options: | Use case | Recommended approach | |---|---| | Internal staff communication | TLS-enforced email (reject plaintext fallback) | | Provider-to-provider | S/MIME or TLS with verified certificate | | Patient communication | Encrypted portal or secure messaging platform | | Billing and insurance | TLS-enforced connection with clearinghouse |

For a comprehensive guide to email encryption implementation, BAA requirements for major providers, and cost analysis, see The Imperative of Email Encryption in Modern Healthcare.

Where practices fail: Staff send patient information via standard email — lab results, referral notes, insurance details, appointment confirmations — without encryption. Each email is a separate potential violation. Email interception is a common attack vector for healthcare practices, and standard email provides no protection against it.

---

The 2025 NPRM and what changes

The Notice of Proposed Rulemaking published January 6, 2025 proposes significant changes to the technical safeguards:

• Elimination of addressable/required distinction — every specification becomes mandatory
• Mandatory encryption — at rest and in transit, no exceptions
• Mandatory MFA — for all ePHI access
• 72-hour restore requirement — systems must be recoverable within 72 hours of a security incident
• Annual compliance audits — technology asset inventories and network mapping required annually
• Vulnerability scanning every 6 months — with penetration testing at least annually

These proposed changes have not been finalized as of this writing. But they signal where OCR enforcement priorities are heading — and every proposed requirement reflects a gap that OCR has repeatedly identified in current enforcement actions.

Practices that implement the technical safeguards described in this reference are already positioned to meet the proposed requirements without significant additional investment.

---

How Patient Protect addresses § 164.312

Patient Protect was built to satisfy the technical safeguards by design — not as an afterthought bolted onto a documentation platform.

Access controls (164.312(a)): Nine-role access management maps to real practice structures — provider, clinical staff, front desk, billing, office manager, IT, external BA, compliance officer, and practice owner. Every role enforces minimum necessary access. No shared credentials. Automatic session timeout.

Audit controls (164.312(b)): Every access event — view, create, modify, delete, export — is logged with user identity, timestamp, and action. Logs are retained, reviewable, and surfaced through security alerts that flag anomalous patterns.

Integrity (164.312(c)): AES-256 encryption at rest with authenticated encryption. File integrity monitoring built into the platform architecture. Backup verification integrated into the compliance workflow.

Authentication (164.312(d)): Multi-factor authentication enforced across the platform. Zero Trust architecture means every request is authenticated and authorized — no implicit trust based on network location or device.

Transmission security (164.312(e)): TLS 1.3 for all data in transit. No plaintext fallback. Secure messaging replaces email for patient communication. Encrypted channels for all data exchange.

The platform also includes continuous compliance monitoring, security alerts, and live diagnostics — so you know when a technical safeguard degrades before it becomes a finding in an audit or a vector in a breach.

---

Quick-reference table

| Standard | Spec | R/A | What it requires | Common failure | |---|---|---|---|---| | 164.312(a)(1) | — | R | Access control policies and procedures | No formal access management beyond EHR defaults | | 164.312(a)(2)(i) | Unique user ID | R | Individual login for every user | Shared credentials across staff | | 164.312(a)(2)(ii) | Emergency access | R | Documented break-glass procedure | No procedure exists; staff improvise during outages | | 164.312(a)(2)(iii) | Automatic logoff | A | Session timeout on inactivity | EHR times out but workstation stays unlocked | | 164.312(a)(2)(iv) | Encryption/decryption | A | Encrypt ePHI at rest | Local workstations and backups unencrypted | | 164.312(b) | — | R | Log and review system activity | Logs exist but are never reviewed | | 164.312(c)(1) | — | R | Protect ePHI from improper alteration | No integrity controls outside EHR | | 164.312(c)(2) | Authenticate ePHI | A | Verify ePHI not altered or destroyed | No backup verification; no file integrity monitoring | | 164.312(d) | — | R | Verify user/entity identity | Password-only access; no MFA | | 164.312(e)(1) | — | R | Protect ePHI in transit | Unencrypted email used for patient communication | | 164.312(e)(2)(i) | Integrity controls | A | Detect improper modification in transit | Using protocols without integrity verification | | 164.312(e)(2)(ii) | Encryption | A | Encrypt ePHI in transit | Standard email without TLS enforcement |

R = Required · A = Addressable (proposed to become Required under 2025 NPRM)

---

Start with your gaps

If you do not know which of these safeguards your practice has implemented — and which are missing — the free risk assessment identifies your gaps in under five minutes. No login required. No sales call. Just a clear picture of where you stand against § 164.312.