The numbers behind HIPAA enforcement in 2024 are hard to ignore: HHS's Office for Civil Rights logged 663 large breaches (500+ records) for incidents occurring that year, exposing an estimated 242.9 million records, according to the hipaajournal.com 2024 healthcare data breach report — a figure dominated by the single Change Healthcare breach, which affected roughly 192 million individuals. OCR also closed 785 investigations and collected $7.81 million across 12 settlements and penalties. Meanwhile the rulebook itself is about to get stricter: on December 27, 2024, HHS OCR published a Notice of Proposed Rulemaking in the Federal Register (January 6, 2025) that would eliminate HIPAA's long-standing "required vs. addressable" distinction, making nearly every technical safeguard mandatory, including encryption of ePHI at rest and in transit, mandatory multi-factor authentication, vulnerability scanning at least every six months, and annual penetration testing. For engineering teams building healthtech software, this is the moment to stop treating HIPAA as a legal checkbox and start mapping it directly to the controls already sitting in a mature application security program. This post walks through the Security Rule's technical safeguards at 45 CFR §164.312 and translates each into something an app-sec team can actually implement and verify.
What does 45 CFR §164.312 actually require?
The Security Rule's technical safeguards, codified at 45 CFR §164.312, require covered entities and business associates to implement five categories of controls over electronic protected health information (ePHI): access control, audit controls, integrity controls, person or entity authentication, and transmission security. Unlike a framework such as SOC 2 that leaves control design largely to the organization, §164.312 names specific implementation specifications — unique user identification, emergency access procedures, automatic logoff, and encryption/decryption among them. Historically, some of these specifications were labeled "addressable" rather than "required," meaning an organization could implement an equivalent alternative or document why a control wasn't reasonable and appropriate. The 2024 NPRM proposes removing that distinction almost entirely, which means the addressable-vs-required debate that has shaped a decade of HIPAA compliance programs is heading toward obsolescence. Application security teams building or maintaining systems that touch ePHI should treat every specification in §164.312 as a hard requirement now, not a someday item.
How does access control under §164.312(a) map to real application controls?
Access control under §164.312(a) requires unique user identification, an emergency access procedure, automatic logoff, and encryption or decryption mechanisms for ePHI — and each maps cleanly to controls most app-sec teams already own. Unique user identification means no shared service accounts or generic logins touching ePHI-bearing systems; every principal, human or machine, needs a traceable identity. Automatic logoff translates directly into session timeout policy on any application surface that renders patient data — a common gap is a web dashboard with no idle-session expiry. Role-based access control (RBAC), scoped so that a billing engineer's account cannot query the same ePHI fields as a clinician's, satisfies the spirit of "access control" even though RBAC itself isn't named in the statute. The emergency access procedure specification is the one teams miss most often: it requires a documented, auditable break-glass mechanism for accessing ePHI during a system outage, which needs its own audit trail distinct from normal access logging.
What do audit controls and integrity mean for logging and data pipelines?
Audit controls under §164.312(b) require hardware, software, or procedural mechanisms that record and examine activity in systems containing ePHI, and integrity controls under §164.312(c) require mechanisms to confirm that ePHI has not been improperly altered or destroyed. In practice, audit controls mean centralized, immutable, tamper-evident logging of every read and write against ePHI-bearing tables or object stores — not just application error logs, but a dedicated access trail that records who queried what patient record and when, retained long enough to support an OCR investigation. Integrity controls typically show up as checksums, digital signatures, or write-once storage on records that must remain unaltered, plus database-level constraints and change-data-capture pipelines that make silent data corruption detectable. A common failure mode app-sec reviewers should watch for: application logs that capture the fact of an ePHI access but not enough context (record ID, requesting user, timestamp) to reconstruct what happened during a breach investigation.
Why are authentication and transmission security becoming non-negotiable?
Person or entity authentication under §164.312(d) and transmission security under §164.312(e) are the two specifications most directly affected by the pending rule change, because the 2024 NPRM proposes making multi-factor authentication and encryption mandatory rather than addressable. Today, many organizations still treat MFA as a risk-based control applied only to administrative accounts; the proposed rule would extend it across systems accessing ePHI, with only narrow, documented exceptions. Transmission security has followed a similar trajectory — TLS in transit is already near-universal in healthtech, but encryption of ePHI at rest is where gaps persist, particularly in analytics warehouses, backup snapshots, and third-party data-sharing pipelines that predate a company's current security program. The NPRM's proposed exceptions for skipping encryption are described as tightly scoped and require specific written justification, which means "we didn't get to it" will no longer be a defensible compliance posture once the final rule takes effect.
What should app-sec teams do while the rule is still pending?
App-sec teams should treat the pending NPRM as a compliance runway rather than a reason to wait: the comment period closed March 7, 2025, OCR's regulatory agenda had targeted a final rule for spring 2026, and that window has now passed with no final rule published and no confirmed new timeline. Once a final rule does publish, it's expected to carry a compliance window of roughly 240 days (a 60-day effective date plus a 180-day compliance period) — meaning organizations that build the control inventory now will already be compliant when the clock starts, while those that wait will be racing it during an active enforcement environment. Build a control inventory now that maps each of the five §164.312 categories to a named owner, a technical implementation, and an audit artifact (a log export, a config screenshot, a penetration test report) that proves it. Vulnerability scanning at least every six months and annual penetration testing are both named in the proposed rule, so if those cadences aren't already on a calendar with a documented output, that's the fastest gap to close. For teams that also serve as business associates under a covered entity's HIPAA program, Safeguard's compliance mapping covers HIPAA/HITECH within its Americas framework catalog specifically for business associate evidence — collecting and organizing the evidence artifacts a covered entity's audit will ask a vendor to produce, rather than replacing an organization's own Security Rule implementation work.
How should this checklist fit into an existing SDLC?
This checklist works best when it's embedded into the same pipeline that already gates code review and dependency scanning, rather than run as a separate quarterly compliance exercise. Access control and authentication requirements belong in infrastructure-as-code review, where a new database role or API scope should trigger a check against least-privilege and MFA requirements before merge. Audit and integrity controls belong in the data layer's design review, evaluated whenever a new table or pipeline touches ePHI. Transmission security is a build-time check: CI can verify that new service-to-service calls use TLS and that no new at-rest datastore is provisioned without encryption enabled by default. Treating §164.312 as five checklist items reviewed once a year is how organizations end up in OCR's breach report; treating it as five gates evaluated on every relevant pull request is how teams keep pace with a rule that, after the current NPRM finalizes, will no longer offer an "addressable" escape hatch for skipping any of them.