HIPAA Technical Safeguards: An Engineering Guide to 45 CFR 164.312

Short answer: HIPAA technical safeguards are the five standards in 45 CFR 164.312: access control, audit controls, integrity, person or entity authentication and transmission security. Two implementation specifications are required (unique user identification and emergency access procedure). The other five are addressable, which means assess, then implement or document an equivalent alternative.

Related guides:

• HIPAA Security Rule
• HIPAA encryption requirements
• PHI in logs

Key takeaways

• Five standards, seven implementation specifications. Audit controls and person or entity authentication are standards with no separate specifications, so the standard itself must be met.
• Addressable is not optional. Under 164.306(d) you either implement the specification, or document why it is not reasonable and appropriate and implement an equivalent alternative where that is reasonable and appropriate.
• The rule is technology neutral. It names outcomes, not products. Your SSO, MFA, logging, TLS, key management and backup choices are how you meet it.
• Evidence beats architecture diagrams. Assessors look for configuration exports, logs, access lists and dated decision records kept for six years.
• The January 2025 NPRM is still a proposal as of October 2026. It would make nearly all specifications required, but the current rule remains in effect.

What are the HIPAA technical safeguards?

The HIPAA technical safeguards are the technology-focused protections for electronic protected health information (ePHI), set out as five standards in 45 CFR 164.312.

The regulation labels each implementation specification "Required" (R) or "Addressable" (A). Here is the full set, exactly as 164.312 marks it:

Standard	Citation	Implementation specification	R/A
Access control	164.312(a)	Unique user identification	R
		Emergency access procedure	R
		Automatic logoff	A
		Encryption and decryption	A
Audit controls	164.312(b)	None (the standard applies directly)	n/a
Integrity	164.312(c)	Mechanism to authenticate ePHI	A
Person or entity authentication	164.312(d)	None (the standard applies directly)	n/a
Transmission security	164.312(e)	Integrity controls	A
		Encryption	A

Each standard describes an outcome. Access control limits ePHI to people or software programs that have been granted access rights. Audit controls record and examine activity in systems that contain or use ePHI. Integrity protects ePHI from improper alteration or destruction. Person or entity authentication verifies that whoever seeks access is the one claimed. Transmission security guards against unauthorized access to ePHI sent over an electronic communications network.

HHS's technical safeguards paper stresses that the rule identifies no specific technology. The administrative safeguards in 164.308, such as the risk analysis and workforce access authorization, sit alongside these controls and are outside the scope of this guide.

Required vs addressable: what does 164.306(d) mean?

A required specification must be implemented, while an addressable one must be assessed and then either implemented or replaced by a documented, reasoned alternative.

45 CFR 164.306(d) sets out the decision for addressable specifications:

1. Assess whether the specification is a reasonable and appropriate safeguard in your environment, considering its likely contribution to protecting ePHI.
2. Implement it if it is reasonable and appropriate.
3. If it is not, document why, and implement an equivalent alternative measure if that alternative is reasonable and appropriate.

The assessment draws on the flexibility factors in 164.306(b): your size, complexity and capabilities, your technical infrastructure, the costs of security measures, and the probability and criticality of potential risks to ePHI. Under 164.306(e), you must review and modify these measures as needed over time.

For a cloud SaaS company, "not reasonable" is a hard argument to make for most addressable technical specifications. Managed services typically make encryption at rest, TLS and session timeouts low-cost settings. HHS's technical safeguards paper notes that where risk analysis shows the risk to transmissions is significant, a covered entity must encrypt them. In our experience, teams get into trouble less often by choosing an alternative and more often by never writing the decision down.

Whatever you decide, 45 CFR 164.316(b) requires a written record of required assessments, kept for six years from creation or from the date last in effect, whichever is later. Feed each decision from your HIPAA risk assessment.

How does a cloud SaaS stack implement each standard?

Most HealthTech SaaS teams meet the technical safeguards through five layers: the identity provider, the application, the data layer with key management, the network edge and the logging pipeline.

The table below shows a typical mapping. These are common patterns, not the only valid designs.

Specification or standard	Typical SaaS implementation
Unique user identification (R)	Every workforce member signs in through the identity provider (IdP) with a named account. No shared admin logins, and service accounts are named per workload. Customer users get unique IDs in your app.
Emergency access procedure (R)	A documented break-glass path: sealed emergency credentials or a time-boxed elevated role, with alerts on use and a post-use review. Include how ePHI is obtained if the IdP is down.
Automatic logoff (A)	Idle timeouts on application sessions and admin consoles, short-lived tokens with refresh limits, and device screen lock enforced through endpoint management.
Encryption and decryption (A)	Encryption at rest for databases, object storage, volumes and backups using a managed key management service (KMS), with key access restricted by role.
Audit controls	Application audit events (who viewed or changed which record), cloud control-plane logs, database and IdP sign-in logs, shipped to a central store with restricted write access and a review process.
Mechanism to authenticate ePHI (A)	Database constraints and transactional writes, checksums or hashes on stored files, object versioning, immutable or write-once backups and restore testing.
Person or entity authentication	SSO with MFA for workforce, MFA options for customer users, and workload identity or mutual TLS for service-to-service calls.
Integrity controls (A)	TLS, which detects tampering in transit, plus signed webhooks or message authentication for integrations.
Encryption (transmission) (A)	TLS on all external endpoints and internal hops that carry ePHI, with older protocol versions disabled.

For person or entity authentication, HHS lists three types of proof: something known (password or PIN), something possessed (smart card, token or key) and something unique to the individual such as a biometric. MFA combines two of these.

Two pitfalls are worth naming. First, shared accounts undermine unique identification. HHS's summer 2021 cybersecurity newsletter warns that shared IDs remove accountability from individual users. Second, audit logging can itself leak ePHI if request bodies are logged, a problem our PHI in logs guide (in Related guides above) covers in depth. Our HIPAA encryption requirements guide goes deeper on encryption choices.

Encryption also has a breach-notification payoff. HHS's guidance on rendering PHI unusable points to NIST SP 800-111 for data at rest and NIST SP 800-52 (TLS) for data in motion, and says decryption keys should be stored separately from the data they protect. That is a strong reason to keep keys in a KMS rather than beside the data.

What evidence will an assessor ask for?

An assessor will ask you to show that each safeguard is designed, implemented and operating, which in practice means exports, screenshots, logs and dated decision records.

Typical requests per standard:

• Access control: IdP user export showing unique named accounts, a list of service accounts and owners, the break-glass procedure and a record of its last test or use, session timeout settings, and KMS key policies and encryption settings for each data store.
• Audit controls: A list of log sources, retention settings, a sample of audit events showing user, action, record and timestamp, and evidence that someone reviews them, such as alert tickets or periodic review notes.
• Integrity: Backup configuration, versioning or immutability settings, and restore test results.
• Person or entity authentication: MFA enforcement settings in the IdP, a report of users without MFA (ideally empty), and how service identities are authenticated.
• Transmission security: TLS configuration for public endpoints, load balancer or gateway listener settings, and how internal traffic carrying ePHI is protected.
• Addressable decisions: For every addressable specification, the 164.306(d) assessment and outcome, dated and owned.

HHS notes that the rule does not dictate which data audit controls must gather. You decide based on your risk analysis, so be ready to explain the choice. For log design itself, see our audit logs guide.

HIPAA technical safeguards checklist for engineering teams

Use this HIPAA technical safeguards checklist as a starting point and adapt it to your own risk analysis.

• Every human and workload with ePHI access has a unique identifier, with no shared logins
• A written break-glass procedure exists, is tested and alerts on use
• Idle session timeouts are set for the app, admin consoles and workforce devices, or an alternative is documented
• ePHI at rest is encrypted with keys in a managed KMS, including backups and replicas
• Audit events cover access to and changes of ePHI, are centralized and are reviewed
• Logs exclude ePHI payloads where they are not needed
• Integrity mechanisms (checksums, versioning, immutable backups) are in place and restores are tested
• SSO with MFA is enforced for all workforce access to systems with ePHI
• TLS protects every network path carrying ePHI, with old protocol versions disabled
• Each addressable specification has a dated 164.306(d) decision record, retained for six years

Will the proposed Security Rule update change the technical safeguards?

Possibly, but as of October 2026 the changes are still a proposal, and the current 164.312 remains the rule you are assessed against.

HHS published its Security Rule notice of proposed rulemaking in the Federal Register on January 6, 2025. According to the HHS NPRM fact sheet, it would, among other things:

• Make all implementation specifications required, with specific, limited exceptions.
• Require encryption of ePHI at rest and in transit, with limited exceptions.
• Require multi-factor authentication, with limited exceptions.

HHS states that the current Security Rule remains in effect while rulemaking continues. We found no final rule published as of October 2026, so treat any compliance dates you see quoted as speculative. Practically, a SaaS stack that already encrypts everywhere, enforces MFA and documents its addressable decisions is well placed whichever way the final rule lands.

How SecureSlate helps

SecureSlate helps HealthTech teams turn 164.312 into tracked controls with evidence. Built-in HIPAA support, with multi-framework control mapping to SOC 2, ISO 27001 and HITRUST, links each technical safeguard to related controls, and custom controls let you record your 164.306(d) addressable decisions. Agentless read-only cloud integrations help surface configuration such as encryption and logging settings, the device agent helps check workforce devices, and access reviews support unique identification and least access. Code security and secrets detection help catch exposed credentials, audit management keeps evidence organized for assessors, and risk management ties decisions back to your risk analysis.

FAQ

How many HIPAA technical safeguards are there?

There are five standards in 164.312: access control, audit controls, integrity, person or entity authentication and transmission security. Together they contain seven implementation specifications, two required and five addressable.

Is encryption required under the HIPAA technical safeguards?

Under the current rule, encryption at rest and in transit are addressable specifications. You must assess them and either implement them or document why not and adopt an equivalent alternative where reasonable and appropriate. The January 2025 NPRM proposes making encryption required, but it is not final as of October 2026.

Is MFA required by 164.312?

The current rule requires you to verify identity under the person or entity authentication standard but does not name MFA. MFA is the common way SaaS teams meet it, and the NPRM proposes requiring it.

Do business associates have to meet the technical safeguards?

Yes. Section 164.312 applies to covered entities and business associates, so a HealthTech vendor handling ePHI for customers must meet it.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.