Quick legend: REQUIRED means the specification must be implemented. ADDRESSABLE means it must be implemented if reasonable for your organization; if not, document why and implement an equivalent alternative. Addressable is NOT optional.
What §164.312 covers
HIPAA's Security Rule has three parts: Administrative Safeguards (§164.308), Physical Safeguards (§164.310), and Technical Safeguards (§164.312). The technical safeguards are the part most engineering teams own directly — they specify how electronic Protected Health Information (ePHI) must be technically protected.
There are 5 standards, each with one or more specifications:
- Access Control (§164.312(a))
- Audit Controls (§164.312(b))
- Integrity (§164.312(c))
- Person or Entity Authentication (§164.312(d))
- Transmission Security (§164.312(e))
1. Access Control — §164.312(a)
Standard
Implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to those persons or software programs that have been granted access rights.
REQUIRED Unique user identification — §164.312(a)(2)(i)
What it means: Every user gets a unique identifier; no shared accounts. How to implement: SSO with one identity per person, no shared service accounts touching ePHI directly. Tag every database row touched by automation with the underlying human-initiated request ID. Run quarterly access reviews to remove orphans.
REQUIRED Emergency access procedure — §164.312(a)(2)(ii)
What it means: Documented break-glass procedure for accessing ePHI during an emergency (e.g. authentication system down during a patient-care incident). How to implement: Sealed-envelope or password-vault break-glass credentials for a small named group. Every use must be logged and reviewed within 24 hours. Document the process; train responders annually.
ADDRESSABLE Automatic logoff — §164.312(a)(2)(iii)
What it means: Sessions terminate automatically after a period of inactivity. How to implement: ePHI-touching sessions expire after ≤ 30 min idle (we recommend 15 min). Enforce both client-side (logout redirect) and server-side (token expiration). Document the rationale if you chose a longer window — but auditors expect ≤ 30 min as the default.
ADDRESSABLE Encryption and decryption — §164.312(a)(2)(iv)
What it means: ePHI at rest must be encrypted (or you must document an equivalent alternative — which in 2026 is essentially impossible to justify). How to implement: AES-256 for databases, object storage, backups, search indexes, message queues. Use a managed KMS (AWS KMS / GCP KMS / Azure Key Vault) with automatic key rotation. Document key rotation cadence, access controls on KMS, and the audit log for key usage. Application-layer encryption for the most sensitive fields (SSNs, financial account numbers).
2. Audit Controls — §164.312(b)
Standard · REQUIRED
Implement hardware, software, and/or procedural mechanisms to record and examine activity in information systems containing ePHI.
What it means: You must log every read, write, and deletion of ePHI, with enough fidelity that an investigator can reconstruct who accessed what. The Security Rule doesn't prescribe specific tools — it says you must have the capability to record and examine.
How to implement:
- Application-level audit logs capturing user ID, timestamp, action (read/write/delete), resource type, resource ID, and originating IP. Every ePHI endpoint emits an audit event.
- Database-level audit logs as a secondary source. Postgres
pg_audit, MySQL audit plugin, or RDS native audit logging. Useful when the application layer is bypassed. - Tamper-evident storage. Append-only object storage (S3 Object Lock, GCS Bucket Lock), or hash-chained logs where each entry's SHA-256 includes the previous entry's hash. LukaGRC's evidence chain ships this by default.
- Retention. Minimum 6 years. Move older logs to cold storage but ensure they remain accessible and tamper-evident.
- Active review. The rule says "record and examine" — daily / weekly automated anomaly review, monthly human spot-check, documented incident-triggered review.
Common mistake: turning on logs but never reviewing them. OCR enforcement actions repeatedly cite organizations that had logs but no review process.
3. Integrity — §164.312(c)
Standard
Implement policies and procedures to protect ePHI from improper alteration or destruction.
ADDRESSABLE Mechanism to authenticate ePHI — §164.312(c)(2)
What it means: A technical mechanism to detect when ePHI has been altered or destroyed in an unauthorized manner. How to implement:
- Database audit triggers that compare row state before and after every UPDATE / DELETE.
- File integrity monitoring (FIM) for any file-based ePHI storage. Tripwire, OSSEC, or built-in cloud equivalents (AWS Config rules, GCP Security Command Center).
- Application-level diffs emitted to audit logs whenever an ePHI field changes.
- Hash-chained audit log so an attacker who modifies an old log entry breaks the chain at every subsequent entry.
- Versioned object storage (S3 versioning, GCS versioning) with MFA-delete enabled.
4. Person or Entity Authentication — §164.312(d)
Standard · REQUIRED
Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.
What it means: Authentication must establish identity before access is granted. The rule doesn't mandate MFA, but in 2026 password-only authentication on ePHI systems is treated as inadequate by both OCR enforcement and ordinary risk analysis.
How to implement:
- MFA on every account that touches ePHI. No exceptions for admins. Phishing-resistant (FIDO2 / WebAuthn / hardware token) is the modern bar; TOTP is acceptable; SMS is now considered weak.
- Strong password policy. Minimum 12-14 characters; no quarterly rotation theater (NIST SP 800-63B explicitly recommends against it); blocked breached-password list (HaveIBeenPwned API or equivalent).
- Service-to-service authentication. mTLS or signed-token-based authentication for internal services that handle ePHI. Static API keys are inadequate unless rotated frequently and stored in a secrets manager.
- Account-takeover protections. Anomaly detection on login (impossible-travel, new-device challenges), account lockout after failed attempts, re-authentication for sensitive actions.
5. Transmission Security — §164.312(e)
Standard
Implement technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network.
ADDRESSABLE Integrity controls — §164.312(e)(2)(i)
What it means: Ensure transmitted ePHI hasn't been improperly modified in transit. How to implement: TLS 1.2+ inherently provides this via MAC. For higher-assurance pipelines, additionally sign the ePHI payload (e.g. JWS / detached signature) so the receiver can verify origin and integrity independently of transport.
ADDRESSABLE Encryption — §164.312(e)(2)(ii)
What it means: Encrypt ePHI in transit when appropriate. How to implement:
- TLS 1.2+ for all ePHI in transit. Disable TLS 1.0/1.1, weak ciphers, RC4, MD5-based MACs. Test with
testssl.shor Qualys SSL Labs (target A+). - HSTS with a long max-age and preload list inclusion.
- Certificate management. Automated renewal (Let's Encrypt + cert-manager / ACM), monitoring for upcoming expirations, certificate transparency log monitoring.
- No ePHI in URLs, query strings, or unencrypted email. Yes, still a common finding.
- End-to-end encryption for the most sensitive pipelines (patient-to-provider messaging, biometric data transmission).
Documentation auditors will ask for
OCR investigations typically request:
- Network diagram showing every system handling ePHI and the encryption boundaries between them.
- Encryption policy documenting algorithms, key lengths, KMS configuration, key rotation cadence.
- Access control policy with the role-based access matrix for ePHI systems and the access-review cadence.
- Audit logging policy describing what's logged, retention, tamper-evidence approach, and review cadence.
- Authentication policy including MFA enforcement, password requirements, account-takeover protections.
- Risk analysis per §164.308(a)(1)(ii)(A) — the periodic document where you assessed each addressable specification and chose your implementation approach.
- Sample audit logs demonstrating capture of user ID, timestamp, action, and ePHI resource ID.
- SAR / breach-determination records demonstrating active review of logs.
Common implementation gaps
- Service accounts not in MFA scope. Engineers add an "automation" account, exempt it from MFA, and that becomes the soft underbelly.
- Logs not tamper-evident. Stored on the same database that holds the ePHI, with full delete privileges.
- Backups not encrypted. Production DB is encrypted; the snapshots someone scripted to S3 aren't.
- TLS configuration drift. Initial setup passes Qualys A+; six months later someone enables a weak cipher for a partner integration. Need continuous testing.
- Auto-logoff only on the frontend. The session token at the backend is still valid for 24 hours — anyone who exfiltrated it can keep using it.
- No documented "why not" for addressable specifications. If you didn't implement auto-logoff at 15 min, you need a written risk analysis explaining the alternative measure and why it's equivalent.