HIPAA technical safeguards: current requirements and what the 2026 NPRM changes

The technical safeguards section of the HIPAA Security Rule — 45 CFR § 164.312 — sets the requirements for the technology and technology-related policies that protect electronic protected health information (ePHI) and control access to it. For a small practice, these requirements translate directly into decisions about EHR configuration, authentication methods, encryption settings, and how audit logs are managed.

The 2026 Notice of Proposed Rulemaking (NPRM), published January 6, 2025 (90 Fed. Reg. 898), proposes the most significant revision to the technical safeguards since the Security Rule was finalized in 2003. It is not yet in effect. Understanding both the current requirements and the proposed changes is essential for practices making technology investments now that will carry them through the next regulatory cycle.

The current technical safeguards: five standards

1. Access control — § 164.312(a)(1)

The access control standard requires covered entities to 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.

Unique user identification (Required): Assign a unique name and/or number for identifying and tracking user identity. Every workforce member accessing ePHI must have their own credentials. Shared logins are a violation of this requirement — and a common finding in OCR enforcement actions.

Emergency access procedure (Required): Establish and implement procedures for obtaining necessary ePHI during an emergency. Access must remain available to authorized personnel even when standard authentication systems fail.

Automatic logoff (Addressable): Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. Workstations that display ePHI and are left unattended without automatic logoff are a recurring physical security concern in small-practice investigations.

Encryption and decryption (Addressable): Implement a mechanism to encrypt and decrypt ePHI. See the dedicated email and communications articles for how this works in practice.

---

2. Audit controls — § 164.312(b)

Audit controls (Required): Implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

This is a required specification with no addressable component. Every covered entity must have audit logging enabled on systems containing ePHI — and must periodically review those logs.

OCR enforcement findings regularly cite practices that had audit logging available in their EHR system but had never enabled it, or that had logging enabled but no process for reviewing the output. The requirement is both to log and to review.

The current rule does not specify frequency of review. Reasonable practice is monthly review of access and activity logs, with documentation that the review occurred and any anomalies were investigated.

---

3. Integrity controls — § 164.312(c)(1)

Integrity (Required — standard): Implement policies and procedures to protect ePHI from improper alteration or destruction.

Authentication mechanisms to corroborate ePHI integrity (Addressable): Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

In practice, this means maintaining checksums, hash verification, or other mechanisms to detect unauthorized modification. Most modern EHR systems provide these mechanisms automatically; the covered entity’s obligation is to ensure they are enabled and that the policies governing data integrity are documented.

---

4. Person or entity authentication — § 164.312(d)

Person authentication (Required): Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.

This is a required specification. It does not, under the current rule, specify the authentication method. A username and password combination technically satisfies the current requirement — though the adequacy of that method under the covered entity’s own risk analysis is a separate question.

The 2026 NPRM proposes significant changes here (see below).

---

5. Transmission security — § 164.312(e)(1)

Transmission security (Required — standard): Implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network.

Integrity controls for transmission (Addressable): Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of.

Transmission encryption (Addressable): Implement a mechanism to encrypt ePHI whenever deemed appropriate.

---

What “addressable” actually means

Multiple specifications above are designated addressable. This is one of the most misunderstood designations in the Security Rule.

Addressable does not mean optional. A covered entity must:

1. Assess whether the specification is reasonable and appropriate for its environment
2. If yes: implement it
3. If an equivalent alternative is available: implement the alternative and document why
4. If neither is reasonable and appropriate: document the specific reasons

For most small practices, encryption of ePHI in transit and at rest is both reasonable and appropriate. The addressable designation has permitted some flexibility in implementation details — not in whether to encrypt.

---

What the 2026 NPRM proposes to change

The NPRM (90 Fed. Reg. 898, January 6, 2025) proposes to eliminate the required/addressable distinction for most technical safeguard specifications and replace it with uniformly required specifications. Key proposed changes:

Encryption becomes required

Both § 164.312(a)(2)(iv) (data at rest) and § 164.312(e)(2)(ii) (data in transit) would shift from addressable to required. The NPRM also specifies minimum technical standards:

• Data at rest: AES-256 encryption, per NIST recommendations
• Data in transit: TLS 1.2 minimum, TLS 1.3 preferred

Covered entities that have documented a decision not to encrypt — and there are some, particularly for internal systems — would need to implement encryption if the rule is finalized.

MFA becomes required for all ePHI access

Under § 164.312(d), the NPRM proposes requiring multi-factor authentication (MFA) for all systems that create, receive, maintain, or transmit ePHI. The proposal specifies:

• MFA required at initial authentication for all ePHI systems
• Phishing-resistant MFA methods preferred (FIDO2/WebAuthn hardware keys)
• SMS-based one-time passwords would satisfy the requirement but are not preferred given known interception vulnerabilities
• Account lockout required after a defined number of failed attempts
• Session timeout requirements with documented maximum duration

Under the current rule, MFA is addressable. Most practices with modern EHR systems have MFA available but not universally implemented.

Audit controls become more specific

The NPRM proposes:

• Audit logs must be tamper-resistant (immutable) — meaning a compromised system cannot delete or alter its own logs
• Minimum quarterly documented log reviews with documented sign-off
• Retention requirements for audit logs (proposed: six years minimum, aligning with HIPAA document retention generally)

New technical control requirements

The NPRM proposes several new required specifications with no current counterpart:

• Deployment of anti-malware protection on all systems handling ePHI
• Removal of extraneous software from systems containing ePHI
• Disabling network ports not required for ePHI operations, per the risk analysis
• Network segmentation for systems containing ePHI from general internet access where feasible
• Defined timeframe (72 hours) for restoring critical systems after a declared emergency or disaster

Technology asset inventory

The NPRM proposes requiring a current, accurate inventory of all technology assets that create, receive, maintain, or transmit ePHI. This inventory would be the foundation for the risk analysis and would be reviewed and updated at least annually, and whenever the environment changes materially.

---

Current status of the NPRM

The proposed rule was published January 6, 2025. The comment period closed March 7, 2025, with approximately 4,700 public comments received. HHS listed May 2026 as a target finalization date on its regulatory agenda. As of May 2026, no final rule has been published.

Legal and regulatory experts note that finalization is more likely in late 2026 or early 2027, given the volume and complexity of comments and the current administration’s general stance toward reducing regulatory burden. The current Security Rule remains fully in effect.

Covered entities should not defer current rule compliance pending the NPRM’s finalization. The proposed requirements — particularly MFA and encryption — represent best practices that OCR already expects to see in risk analysis documentation under the current rule.

Practical checklist against current requirements

• Access control: Every ePHI system has unique user credentials per staff member (no shared logins); automatic logoff is configured
• Audit controls: Audit logging is enabled on all ePHI systems; logs are reviewed on a documented schedule and findings are recorded
• Integrity: Data integrity controls are enabled; backup integrity is verified on a documented schedule
• Authentication: All ePHI systems require authentication before access; the method is documented in the risk analysis
• Transmission security: Email and other transmission channels carrying ePHI use TLS or equivalent; documentation is current

---

Sources: 45 CFR § 164.312 (technical safeguards); 45 CFR § 164.306 (general security requirements); HHS Summary of the HIPAA Security Rule, hhs.gov/hipaa/for-professionals/security/laws-regulations; 90 Fed. Reg. 898 (HIPAA Security Rule NPRM, January 6, 2025); NIST SP 800-111 (storage encryption); NIST SP 800-52 (TLS/SSL guidelines); HHS HIPAA Security Rule NPRM Fact Sheet, hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet. Last verified May 20, 2026.