HIPAA Security Rule Technical Safeguards: What §164.312 Requires in Practice

The HIPAA Security Rule technical safeguards are five standards in one short section of the regulation, 45 CFR 164.312. They decide who can reach electronic protected health information (ePHI), whether that access is logged, whether the data can be altered undetected, whether the person reaching it is who they claim to be, and whether it is protected in transit. This guide walks through each standard, explains which parts are required and which are addressable, and shows what a security assessment produces as evidence for each one. It is the technical-controls companion to our page on HIPAA penetration testing requirements, which covers the risk analysis and the proposed testing mandate.

Where the HIPAA Security Rule technical safeguards sit

The Security Rule (45 CFR Part 164, Subpart C) groups its standards into administrative, physical and technical safeguards. The rule defines technical safeguards as “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it” (45 CFR 164.304). Covered entities and business associates both have to comply (45 CFR 164.302), and the duty reaches all the ePHI they create, receive, maintain or transmit (164.306(a)).

Two things make 164.312 easy to misread. First, it is deliberately technology neutral: it names outcomes, not products. Second, each standard carries implementation specifications that are either required or addressable, and addressable does not mean optional.

Required vs addressable: what addressable actually means

For a required specification, you implement it. For an addressable one, 45 CFR 164.306(d) tells you to assess whether it is “a reasonable and appropriate safeguard in its environment,” then do one of two things: implement it, or, if it is not reasonable and appropriate, “document why it would not be reasonable and appropriate to implement” it and “implement an equivalent alternative measure if reasonable and appropriate.”

The practical result is that “addressable” means “implement it, or write down a defensible reason and put something equivalent in its place.” Skipping an addressable specification with no analysis and no alternative is a finding, not a choice. The Security Rule also gives you flexibility of approach, judged against your size and complexity, your technical capabilities, the cost of the measure, and “the probability and criticality of potential risks to electronic protected health information” (164.306(b)). A small practice and a national payer can meet the same standard differently, but both have to show their reasoning.

The five technical safeguards, one at a time

(a) Access control (Required standard)

The standard: allow access to ePHI “only to those persons or software programs that have been granted access rights” (164.312(a)). Its four implementation specifications:

• Unique user identification (Required): assign a unique name or number to track each user. Shared logins break this and break every audit trail built on top of it.
• Emergency access procedure (Required): a way to reach ePHI during an emergency, such as a break-glass account.
• Automatic logoff (Addressable): end a session after a period of inactivity.
• Encryption and decryption (Addressable): a mechanism to encrypt and decrypt ePHI. In practice this is the at-rest encryption control, since transmission gets its own standard below.

What a test checks: whether accounts are individual and least-privileged, whether a low-privilege user can reach records or admin functions they should not (the healthcare version of broken access control), whether session timeouts exist, and whether encryption is on where the data sits.

(b) Audit controls (Required standard)

Implement “hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information” (164.312(b)). There are no separate specifications, but the bar is real: an EHR that cannot show who viewed which record, when, fails this standard. Audit controls also underpin the administrative information system activity review at 164.308(a)(1)(ii)(D), which is required. A test confirms that access to ePHI is logged, that the logs are protected from the users they record, and that someone actually reviews them.

(c) Integrity (Required standard)

Protect ePHI “from improper alteration or destruction.” The addressable specification is a “mechanism to authenticate electronic protected health information,” meaning a way to verify data has not been changed in an unauthorized manner. The Security Rule defines integrity as “the property that data or information have not been altered or destroyed in an unauthorized manner” (164.304). Testing looks at whether an attacker or a mistaken process can modify records without detection, and whether checksums, versioning or database controls would catch it.

(d) Person or entity authentication (Required standard)

“Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed” (164.312(d)). No separate specifications, and the rule names no specific method, so passwords, PINs, tokens, smart cards and biometrics all qualify in principle. In practice this is where multi-factor authentication, password strength, session handling, and single sign-on are examined, and where a phishing simulation tests whether the authentication survives a realistic credential-theft attempt. Mailboxes often hold ePHI in attachments and threads, so where mail runs on Microsoft 365 a Microsoft 365 security assessment belongs in the same scope.

(e) Transmission security (Required standard)

Guard against unauthorized access to ePHI “being transmitted over an electronic communications network.” Two addressable specifications:

• Integrity controls (Addressable): ensure transmitted ePHI is not improperly modified without detection.
• Encryption (Addressable): encrypt ePHI in transit when appropriate.

Testing covers TLS configuration on portals and APIs (including FHIR endpoints), whether any ePHI moves in clear text, and whether internal traffic between clinical and business systems is protected.

The safeguards at a glance

Standard	Implementation specification	Required or addressable
Access control 164.312(a)	Unique user identification	Required
	Emergency access procedure	Required
	Automatic logoff	Addressable
	Encryption and decryption	Addressable
Audit controls 164.312(b)	(standard, no specifications)	Required
Integrity 164.312(c)	Mechanism to authenticate ePHI	Addressable
Person or entity authentication 164.312(d)	(standard, no specifications)	Required
Transmission security 164.312(e)	Integrity controls	Addressable
	Encryption	Addressable

Encryption appears twice, at rest under access control and in transit under transmission security, and both are addressable today. That is the single most consequential “addressable” in the rule, and the proposed update would change it.

How the proposed rule would rewrite 164.312

On January 6, 2025, HHS published a Notice of Proposed Rulemaking to strengthen the Security Rule (Federal Register, 2024-30983). It would rebuild 164.312 into a longer list of standards and drop the distinction between required and addressable specifications, leaving only specific, documented exceptions. That distinction is what makes the current section easy to under-implement. The proposed technical safeguards include:

• Access control with new controls for separating administrative identities, disabling access after failed log-in attempts, and network segmentation.
• Encryption and decryption as its own standard: “Encrypt all electronic protected health information at rest and in transit,” subject to narrow documented exceptions. This is the change that would make encryption effectively mandatory.
• Configuration management, including anti-malware, removing extraneous software, and disabling unused network ports against a secure baseline.
• Audit trail and system log controls with real-time monitoring and alerting.
• Integrity and transmission security kept as standards, each reviewed and tested at least every 12 months.
• Authentication with a multi-factor authentication requirement for access to ePHI systems and for privilege changes, subject to documented exceptions.
• Vulnerability management, which would require automated vulnerability scanning “in accordance with the covered entity’s or business associate’s risk analysis … or at least once every six months, whichever is more frequent,” plus ongoing monitoring, and penetration testing “at least once every 12 months” by a qualified person.
• Data backup and recovery and information systems backup and recovery as their own standards.

As of September 2026 this remains a proposal. The comment period closed on March 7, 2025, HHS received thousands of comments, and the federal regulatory agenda now targets final action in 2027, so the requirements and their timing could still change or be withdrawn. The sensible reading for today: treat encryption and MFA as the default and document any exception, because a documented “addressable” analysis that concludes you do not need encryption is already hard to defend to an auditor or a hospital customer. Our HIPAA penetration testing requirements page tracks the proposed testing and scanning cadence in detail.

What a test evidences for each safeguard

A HIPAA engagement is most useful when the report maps each finding to the safeguard it affects, so a compliance officer can drop it straight into the risk analysis and the periodic evaluation at 164.308(a)(8). A typical mapping:

Safeguard	What the assessment produces
Access control 164.312(a)	Access-control and privilege findings, session-timeout and encryption-at-rest checks
Audit controls 164.312(b)	Whether ePHI access is logged, protected and reviewed
Integrity 164.312(c)	Whether records can be altered undetected
Authentication 164.312(d)	MFA coverage, password and session findings, phishing resilience
Transmission security 164.312(e)	TLS and clear-text findings on portals, APIs and internal traffic
Vulnerability management (proposed)	Validated scan results and the penetration test itself

For the scanning half of that picture, our managed vulnerability scanning runs the internal and external scans the proposed rule would require, validated by an analyst, from $1,500 per scan. For the safeguard mapping and the report, HIPAA penetration testing scopes the engagement to the systems that actually handle ePHI. NIST’s HIPAA resource guide, SP 800-66 Rev. 2, lists penetration testing, where reasonable and appropriate, among the key activities for the evaluation standard, so the test is also your evidence for 164.308(a)(8). You can see the report structure on the sample report page, and the retention rule at 164.316(b)(2)(i) means keeping that documentation for six years.

Who this matters to

The technical safeguards apply the same way to covered entities and business associates, but the reader changes. A medical practice maps them for an OCR inquiry. A health-tech vendor or a business associate maps them because a hospital’s vendor risk team asks for the evidence before signing a business associate agreement. Both need the same thing: a report that names the safeguard, states the finding, and shows the fix verified. Our page for healthcare and medtech companies covers what healthcare buyers usually scope. Choosing a firm first? Compare the best healthcare penetration testing companies.

Frequently asked questions

What are the HIPAA technical safeguards? Five standards in 45 CFR 164.312: access control, audit controls, integrity, person or entity authentication, and transmission security. Each protects ePHI and controls access to it, and each carries required or addressable implementation specifications.

Is encryption required under HIPAA? Today, no. Encryption at rest and in transit are both addressable, which means you implement them or document why not and use an equivalent measure. The proposed 2025 rule would make encryption of ePHI at rest and in transit required, subject to narrow documented exceptions.

Does “addressable” mean optional? No. An addressable specification must be implemented if it is reasonable and appropriate. If it is not, you document the reason and put an equivalent alternative in place. Ignoring it entirely is a compliance gap.

Do the technical safeguards require a penetration test? Not by name. The current rule requires a risk analysis and a periodic technical evaluation and leaves the method open, and a penetration test is the usual way to evidence both. Under the proposed update, a yearly penetration test and a scan at least every six months would sit inside 164.312 itself, as part of a new vulnerability management standard.

How do the technical safeguards differ from the administrative safeguards? Administrative safeguards (164.308) are the program: risk analysis, workforce training, access management policies, the evaluation. Technical safeguards (164.312) are the controls in the systems themselves. A test produces evidence for both, and our HIPAA compliance checklist lists every administrative, physical and technical item with the evidence to keep.

The short version

The HIPAA Security Rule technical safeguards are access control, audit controls, integrity, authentication and transmission security, spelled out in 45 CFR 164.312, with a mix of required and addressable specifications and a technology-neutral standard behind each one. A test that maps its findings to these five standards gives your compliance team evidence for the risk analysis today and a head start on the encryption, MFA and testing the proposed rule would require. To get that mapping at a published price with a free retest, scope an engagement.