Access control, audit controls, integrity, authentication, and transmission security — specification by specification.
What this category is — and is not
Technical safeguards, at 45 CFR §164.312, are the technology controls protecting ePHI and controlling access to it: five standards covering access control, audit controls, integrity, authentication, and transmission security. Two framing points before the specifics. First, the rule is deliberately technology-neutral — it names no products, no algorithms, no key lengths — so “compliant” is a property of your implementation and your documented reasoning, never of a tool you bought. Second, this is the safeguard category engineering teams handle best and over-weight worst: a flawless §164.312 implementation covers five standards out of the Security Rule’s eighteen-plus, and most findings live in the administrative safeguards next door. Do this section well; do not mistake it for the programme.
Every choice here should trace back to the risk analysis. That is not compliance poetry — it is how a reviewer reads your configuration: “you identified stolen credentials as a high risk; show me the authentication controls that answer it.”
Access control §164.312(a)
Unique user identification and emergency access are required. Automatic logoff and encryption at rest are addressable — which in 2026 means implement them or write a rationale you would be willing to read aloud in a deposition.
Unique user identification is the specification with the least ambiguity and the most violations: every human gets their own identity in every system touching ePHI. Shared logins — the front-desk account, the on-call credentials in a wiki, the service account four engineers use interactively — destroy accountability and make your audit logs unattributable, which quietly breaks §164.312(b) as well. The emergency access procedure is the one nobody remembers until asked: a documented way to reach ePHI when normal mechanisms fail — the break-glass account, sealed and logged. For the addressable pair: automatic logoff is a screen-lock timeout policy enforced by MDM, and encryption at rest is a checkbox in every major cloud provider — meaning the “not reasonable and appropriate” rationale is nearly impossible to write honestly. Encryption also carries a bonus far beyond the rule: properly encrypted ePHI is “secured” for Breach Notification purposes, so the lost laptop becomes an incident log entry instead of a 60-day notification exercise.
Audit controls §164.312(b)
Required. Hardware, software, or procedural mechanisms that record and examine activity in systems containing ePHI. Recording without examining fails the standard.
The standard has two verbs and organisations reliably implement only the first. Logs accumulate in cloud consoles by default; examination — a named person, a defined cadence, a record that the review happened and what it found — is the part that requires deliberate construction. The examination record also feeds §164.308(a)(1)(ii)(D), information system activity review, which is the administrative twin of this technical standard. Practical shape for a small organisation: centralise authentication and access logs, define a handful of alerts worth waking up for (impossible-travel logins, mass export, privilege changes), review the rest weekly or monthly, and log the review itself. Retention of the logs should follow your documented policy; retention of the review records follows the six-year rule like everything else.
Integrity §164.312(c)
Protect ePHI from improper alteration or destruction. In practice: checksums, database constraints, backup verification, and change control.
Integrity is the least glamorous standard and the one whose failure is most dangerous clinically — a corrupted allergy list is worse than a disclosed one. The addressable implementation specification asks for mechanisms to corroborate that ePHI has not been improperly altered or destroyed. In modern stacks most of the machinery exists already: transactional databases, checksummed storage, immutable audit trails on record changes, versioned backups. The two pieces teams actually miss are backup verification — a backup restored successfully on a documented date, because an unverified backup is a hope — and change control, since the most common improper alteration is a well-meaning engineer’s migration script. Ransomware also lands here: it is an availability and integrity attack, and your tested restore procedure is the integrity control that answers it.
Authentication and transmission §164.312(d)-(e)
Verify the person is who they claim, and protect ePHI in transit. MFA is not named in the text and is effectively expected in every assessment we have seen.
Person or entity authentication (§164.312(d)) is where password policy, MFA, and SSO live. The rule predates all three by name, which is the technology-neutrality working as designed: the standard is “verify identity”, and the 2026 reasonable-and-appropriate answer for anything internet-reachable is multi-factor. Password rules belong in a written policy your systems actually enforce — a policy stricter than your configuration is evidence against you. Transmission security (§164.312(e)) requires guarding ePHI against unauthorised access while in transit across networks, with integrity controls and encryption as its addressable specifications. TLS everywhere handles the bulk of it; the residue that causes findings is the informal channels — ePHI in email to patients, in SMS, in support tickets, in the shared Slack with a vendor. The transmission policy’s real job is naming the approved channels and making the unapproved ones a training point rather than a surprise.
The gaps engineering teams actually have
Reviewing technically strong organisations produces a consistent shortlist, worth checking against your own stack. Non-human identities: service accounts and API keys with broad ePHI access, no owner, and no rotation story — governed by nobody because they belong to nobody. The staging leak: production data copied into test environments “temporarily”, where none of the production controls follow it. The logging blind spot: application-level access to ePHI (which user viewed which record) unlogged because only infrastructure logs were ever configured. The recovery path: password resets and MFA re-enrolment handled by a help desk that verifies identity by friendliness. And the offboarding tail: SSO revoked on day one, while direct database credentials, SSH keys, and vendor-portal logins linger for months. None of these is exotic; all of them sit exactly where the org chart’s responsibility lines blur, which is why a policy with named owners closes more of them than another tool does.
Turning this section into evidence
For each of the five standards, the audit-ready artefact set is the same: the configuration itself, the written policy describing it, and a dated record showing it was checked. Screenshots age; exports with timestamps and lineage hold up. If you want to know which of the five you would fail today, the free readiness assessment covers all of them, and the full checklist puts them alongside the administrative and physical items they depend on. The pattern to aim for is boring symmetry: every technical claim in a policy verifiable in a configuration, every configuration described by a policy, and a dated check connecting the two at least annually.
Where SuperHIPAA fits
Everything above is work. The platform does the parts that are mechanical — evidence collection, acknowledgement tracking, register maintenance, renewal reminders — and our team does the parts that need judgement. You keep the parts that need to be yours.
Start where you are
Take the free readiness assessment — 24 questions, about eight minutes, no call required. You get a scored report identifying which required specifications you are missing and what to fix first. If it turns out you are further along than you thought, we will tell you that too.