HIPAA's technical safeguards in 45 CFR 164.312 ask engineers for five things: access control, audit controls, integrity protection, person or entity authentication and transmission security. Only unique user IDs and an emergency access procedure are strictly required specifications. The rest are addressable, which means assess, implement or document an alternative.
We read the eCFR text of 164.312 on 18 October 2026. The HHS pages returned HTTP 403. HIPAA also needs a risk analysis and administrative safeguards, which this checklist does not replace. This is not legal advice, and the rule may be changed, so check HHS for current status.
Access control (164.312(a))
The standard limits access to systems holding electronic protected health information, ePHI, to authorized people or software.
- Every person has a unique user ID, no shared accounts (required).
- A documented emergency access procedure for getting at ePHI during an emergency, tested (required).
- Automatic logoff on sessions and devices that reach ePHI (addressable).
- Encryption of ePHI at rest where reasonable, with key management (addressable).
- Role based access, least privilege, and a joiner, mover and leaver process.
- Service accounts and API keys scoped, owned and rotated.
Audit controls (164.312(b))
The standard asks for mechanisms that record and examine activity in systems with ePHI. No specification is listed under it.
- Logs show who accessed which record, when, from where and what they did.
- Logs are centralized and protected from tampering.
- Someone reviews them on a set schedule, and alerts exist for unusual access.
- Retention is decided and documented. HIPAA documentation rules in the Security Rule are commonly read as six years, so check the provision and your counsel before setting log retention.
Integrity (164.312(c))
The standard protects ePHI from improper alteration or destruction. A mechanism to authenticate ePHI is addressable.
- Database constraints, checksums or signed records where tampering matters.
- Change management with review for code that touches ePHI.
- Backups verified by restore tests.
- Write access to production data limited and logged.
Person or entity authentication (164.312(d))
- Multi-factor authentication for workforce access to ePHI systems and administration consoles.
- Strong, unique credentials, with a password manager or single sign-on.
- Service to service authentication using managed identities or short lived tokens.
The rule text lists no specifications here, but authentication strength is judged in your risk analysis.
Transmission security (164.312(e))
Integrity controls and encryption are both addressable.
- TLS on every external and internal path that carries ePHI.
- Certificates managed and monitored for expiry.
- Secure channels for administration, and no ePHI in email, chat or tickets unless approved.
- Message queues, exports and analytics pipelines covered, not just the web front end.
What are addressable measures?
Addressable does not mean optional. You assess whether a specification is reasonable and appropriate in your environment. If it is, implement it. If not, document why and use an equivalent alternative if reasonable. Document your reasoning in the risk analysis.
What sits around the code?
- An inventory of every system that creates, receives, maintains or transmits ePHI, including third party services.
- A risk analysis covering those systems, kept current.
- Business associate agreements with vendors who touch ePHI.
- Vulnerability and dependency scanning on ePHI applications, with remediation tracked.
- Incident response that includes breach assessment.
What to do
- Build the ePHI system inventory and data flow map.
- Walk each of the five standards using this list per system.
- Fix the required items first, then decide each addressable item and record why.
- Turn on and review logs.
- Add dependency and code scanning to the pipeline.
- Revisit after any architecture change.
Quick check
Which technical specifications are required, not addressable?
In the 164.312 text on eCFR, only unique user identification and the emergency access procedure, both under access control, are marked required.
Does HIPAA require multi-factor authentication?
The 164.312 text we read does not name it. Authentication is judged through your risk analysis, and regulators may change the rule, so check HHS for current requirements.
How Safeguard helps automate this
Engineering teams spend most time proving these controls stay on. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits, leaving time for other work. Technical evidence comes from your real code and dependencies through scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies in ePHI applications. It is off by default, every category starts on Manual, and you choose which categories run automatically. Safeguard does not make you HIPAA compliant. Book a call to see it.
Sources
- eCFR: 45 CFR 164.312, fetched 18 October 2026
- HHS: HIPAA Security Rule, HTTP 403 on fetch
Last reviewed: 18 October 2026.
