Of all the parts of HIPAA, the technical safeguards are the ones that land most directly on the software team. They are the specific, enforceable expectations for how electronic protected health information (ePHI) is protected inside your systems — access control, audit logging, integrity, authentication, and transmission security. Understanding them is not optional for anyone building healthcare software, because they shape the architecture, and getting them wrong is both a security risk and a compliance liability. This guide explains each technical safeguard in plain terms, clears up the widely misunderstood “required versus addressable” distinction, and describes how each is actually implemented in software.
A note before we start: this is an educational overview, not legal advice, and technical safeguards are only one piece of HIPAA compliance. Your full obligations — including administrative and physical safeguards, a formal risk analysis, and Business Associate Agreements — are broader and belong to your compliance team and counsel. We cover where the technical safeguards stop later in the article.
Where Technical Safeguards Fit in the Security Rule
The HIPAA Security Rule organizes its requirements into three categories: administrative safeguards (policies, workforce training, risk analysis, and the management of security), physical safeguards (facility access, workstation and device controls), and technical safeguards (the technology and the controls around it that protect ePHI). Technical safeguards live at 45 CFR §164.312, and they are the category software engineers own most directly. The other two categories matter just as much for overall compliance — but they are largely organizational and operational, whereas the technical safeguards are built into the software itself.
Required vs. Addressable — The Distinction That Trips People Up
Each safeguard has implementation specifications labeled either “required” or “addressable,” and this is the single most misunderstood concept in the Security Rule. Required means exactly what it says — you must implement it. Addressable does not mean optional. It means you must assess whether the specification is reasonable and appropriate for your environment, and then either implement it, or document why it is not reasonable and appropriate and implement an equivalent alternative measure that achieves the same goal. In practice, for most software handling ePHI, the addressable specifications — including encryption — are reasonable and appropriate, so treating “addressable” as “skippable” is a common and dangerous mistake. The bar is a documented, defensible decision, not a free pass.
It is also worth knowing that the Security Rule is being strengthened. A proposed update would, among other changes, make many currently addressable specifications explicitly required and mandate measures like encryption and multi-factor authentication more firmly. As of now this is a proposed rule rather than final, but the direction is clear: the floor is rising, and building to the stronger standard today is the prudent choice. Confirm the current state of the rule with your compliance team.
The Five Technical Safeguards
1. Access Control (§164.312(a))
Access control ensures that only authorized people and software can reach ePHI, and that they can reach only what they are permitted to. Its specifications include unique user identification (required) — every user has their own identity, never shared logins — and an emergency access procedure (required) so authorized people can reach ePHI during an emergency. It also includes automatic logoff (addressable) to end inactive sessions, and encryption and decryption (addressable) of ePHI. In software, this translates into role-based access control, the principle of least privilege, per-user accounts, session timeouts, and encryption of stored data — designed in, not retrofitted.
2. Audit Controls (§164.312(b))
Audit controls require mechanisms to record and examine activity in systems that contain ePHI. This is a required standard, and in practice it means comprehensive, tamper-resistant audit logging — who accessed which record, when, and what they did — retained and reviewable. Good audit logging is also one of your most valuable assets if a breach is ever investigated, because it lets you reconstruct exactly what happened. In custom software, this means building structured, secured access logging into the data layer from the start, not bolting on minimal logging at the end.
3. Integrity (§164.312(c))
The integrity standard requires protecting ePHI from improper alteration or destruction. Its addressable specification is a mechanism to authenticate ePHI — to confirm that data has not been changed or destroyed in an unauthorized way. In software, integrity is protected through controls like checksums or hashing to detect tampering, database constraints and transaction integrity, version history, and safeguards against unauthorized modification. The goal is that you can trust the clinical data is what it is supposed to be, because corrupted or silently altered health data is a patient-safety problem, not just a compliance one.
4. Person or Entity Authentication (§164.312(d))
This required standard ensures that anyone (or any system) seeking access to ePHI is who they claim to be. Authentication is the front door, and in software it is implemented through credentials, and increasingly through multi-factor authentication, which the proposed Security Rule update would push toward requiring. Strong authentication — unique credentials, MFA, secure session management, and protection against credential attacks — is foundational, because every other safeguard assumes the system actually knows who is on the other end.
5. Transmission Security (§164.312(e))
Transmission security protects ePHI while it moves across networks. Its specifications are integrity controls (addressable) to ensure data is not improperly modified in transit, and encryption (addressable) of ePHI being transmitted. In practice this means encrypting data in transit with modern transport security such as TLS, securing every API and integration that carries ePHI, and never sending health data over unprotected channels. For healthcare software that exchanges data with EHRs and other systems, transmission security is constant and central — see our data security practice.
Encryption: Addressable, but Effectively Expected
Encryption appears as an addressable specification in two places — at rest (under access control) and in transit (under transmission security) — and it deserves special attention because of how it functions in practice. For most software handling ePHI, encryption is reasonable and appropriate, so the realistic default is to encrypt, not to argue your way out of it. Modern practice means strong encryption at rest (for example, AES-256) and in transit (for example, TLS 1.3). There is also a powerful incentive beyond the safeguard itself: properly encrypted ePHI that is breached may fall under the breach-notification safe harbor, meaning a lost or stolen encrypted dataset may not trigger breach notification obligations the way unencrypted data would. Encryption is one of the highest-leverage controls you can implement, and the proposed rule strengthening only reinforces that.
What Technical Safeguards Do Not Cover
This is the boundary that matters most for buyers. Implementing the technical safeguards in your software is necessary for HIPAA compliance, but it is not sufficient on its own. Full compliance also requires the administrative safeguards — a formal risk analysis, security management processes, workforce training, and policies — and the physical safeguards around facilities and devices. It requires Business Associate Agreements with every vendor that handles ePHI on your behalf. And it requires treating compliance as an ongoing program, not a one-time build. A vendor who builds excellent technical safeguards into your software has done their part of the job well, but your organization’s overall HIPAA compliance is broader and belongs to your compliance team and counsel. See our HIPAA risk assessment and HIPAA consulting practices for the parts that surround the software.
How to Implement Technical Safeguards in Custom Software
The recurring theme is that technical safeguards belong in the architecture from day one, not bolted on before launch. That means role-based access control and least privilege designed into the data model, structured and secured audit logging in the data layer, integrity controls on clinical data, strong authentication including MFA, and encryption at rest and in transit as defaults. Retrofitting these into software that was not built with them is expensive and error-prone, which is exactly why a healthcare-experienced team builds them in from the first commit. Our practical companion to this article — the HIPAA-compliant software development checklist — turns these principles into a working list.
How Taction Helps
We build the technical safeguards into healthcare software as a matter of course — role-based access control, comprehensive audit logging, integrity controls, strong authentication with MFA, and encryption at rest (AES-256) and in transit (TLS 1.3) — backed by ISO 27001-certified information security management and BAA-readiness. We provide the technical implementation and work alongside your compliance team and counsel, who own the broader administrative and physical safeguards, the risk analysis, and the overall compliance program. Our HIPAA-compliant development practice and our custom healthcare software development hub show how this fits into a complete build.
Related reading: “Business Associate Agreements: What Developers Need to Know” and “How to Choose a Healthcare Software Development Company.“
Frequently Asked Questions
What are the HIPAA technical safeguards?
They are the technology-focused requirements of the HIPAA Security Rule (45 CFR §164.312) for protecting electronic protected health information: access control, audit controls, integrity, person or entity authentication, and transmission security. They are the category of safeguards most directly implemented in software.
Does “addressable” mean optional?
No — this is the most common misunderstanding. Addressable means you must assess whether the specification is reasonable and appropriate, then either implement it or document why not and implement an equivalent alternative. For most software handling ePHI, including encryption, the addressable specifications are reasonable and appropriate, so treating them as optional is a serious mistake.
Is encryption required under HIPAA?
Encryption is technically “addressable” rather than strictly required, but for most software handling ePHI it is reasonable and appropriate, so the realistic default is to encrypt at rest and in transit. Encryption also enables the breach-notification safe harbor, and a proposed Security Rule update would strengthen encryption expectations further.
Do technical safeguards alone make us HIPAA compliant?
No. Technical safeguards are necessary but not sufficient. Full compliance also requires administrative safeguards (including a formal risk analysis and policies), physical safeguards, Business Associate Agreements, and an ongoing compliance program. The technical safeguards are the software team’s part of a larger picture owned by your compliance team.
Is the HIPAA Security Rule changing?
A proposed update would strengthen the rule, including making many currently addressable specifications explicitly required and firming up measures like encryption and multi-factor authentication. As of now it is proposed rather than final, but the direction is toward a higher floor, so building to the stronger standard now is prudent. Confirm the current state with your compliance team.
Should technical safeguards be built in from the start or added later?
Built in from the start. Retrofitting access control, audit logging, integrity controls, authentication, and encryption into software that was not designed for them is expensive and error-prone. A healthcare-experienced team designs these into the architecture from the first commit.
Building healthcare software that needs these safeguards done right? Schedule a free consultation →
This article is an educational overview of HIPAA technical safeguards, not legal advice. Reviewed by Taction Software’s healthcare engineering team. ISO 27001-certified information security management. PHI is handled under a signed BAA; overall HIPAA compliance rests with your organization and counsel.
