HIPAA Access Control in 2026: What's Required Now, What's Proposed, and What It Takes
What the rule in force actually says
HIPAA’s Security Rule does not say “implement identity and access management.” Section 164.312(a)(1) says to allow access only to those persons or software programs that have been granted access rights. One sentence. The evidence an investigator expects is considerably more than one sentence.
Under the rule as it stands today, access controls split into two categories. Required specifications you must implement. Addressable ones you must implement, or document why they are not reasonable and appropriate and what you did instead. Addressable has never meant optional — that misreading is the single most common finding.
Encryption and automatic logoff are addressable. Unique user identification and emergency access are required.
Today versus what is proposed
Multi-factor authentication
- Rule in force
- Not named explicitly. Reaches you through the required risk analysis — remote access without it is difficult to justify.
- Proposed (not binding)
- Explicitly required for ePHI access, with limited exceptions.
Addressable specifications
- Rule in force
- Implement, or document a reasoned alternative.
- Proposed (not binding)
- The distinction is removed. Addressable items become mandatory.
Asset inventory
- Rule in force
- Implied by risk analysis; no prescribed format or cadence.
- Proposed (not binding)
- Written inventory and network map, reviewed at least annually.
Encryption of ePHI
- Rule in force
- Addressable, at rest and in transit.
- Proposed (not binding)
- Required at rest and in transit, with limited exceptions.
Testing
- Rule in force
- No prescribed frequency.
- Proposed (not binding)
- Vulnerability scans every six months, penetration testing annually.
| Identity control | Rule in force | Proposed (not binding) |
|---|---|---|
| Multi-factor authentication | Not named explicitly. Reaches you through the required risk analysis — remote access without it is difficult to justify. | Explicitly required for ePHI access, with limited exceptions. |
| Addressable specifications | Implement, or document a reasoned alternative. | The distinction is removed. Addressable items become mandatory. |
| Asset inventory | Implied by risk analysis; no prescribed format or cadence. | Written inventory and network map, reviewed at least annually. |
| Encryption of ePHI | Addressable, at rest and in transit. | Required at rest and in transit, with limited exceptions. |
| Testing | No prescribed frequency. | Vulnerability scans every six months, penetration testing annually. |
Left column is enforceable today. Right column is a proposal under review and may change or never take effect.
The four artifacts that get sampled
Investigations do not begin with your policy binder. They begin with a sample and a request to trace it.
1. Termination evidence. Section 164.308(a)(3)(ii)(C) requires termination procedures. Investigators pick separated staff and trace HR separation date, to identity deactivation timestamp, to access removal in each system. Gaps measured in weeks fail. Gaps measured in hours pass. This one artifact justifies automating joiner-mover-leaver more than any security argument will.
2. Access authorization mapped to reality. Not the template — the document describing how clinical roles translate to permissions in the record system, who approves exceptions, and where that mapping lives. If it references a role model nobody maintains, that is the finding.
3. Periodic access review records. Who reviewed, what they saw, what changed as a result. A review that removed nothing, every quarter, reads as a rubber stamp.
4. Emergency access, tested. Required, not addressable. Clinicians must reach records in a crisis. The control is that it expires on its own, raises an alert, and is logged — and that you have tested it, with dates.
What it actually takes
For a hospital with four people running everything, the honest sequence looks like this. Effort assumes an existing Entra ID or Okta tenant.
- 1
Put multi-factor authentication in front of remote access
1–2 weeksOne conditional access policy covering every externally reachable system, then switch off the older authentication protocols that bypass it. This is the single change that answers the question a board asks after a neighbouring hospital is hit.
- 2
Wire separation into identity deactivation
2–4 weeksConnect the HR record to the identity platform so a termination date disables the account rather than raising a ticket. Until this exists, termination evidence has to be assembled by hand every time.
- 3
Scope vendor accounts to their agreements
2–3 weeksList every third-party account with access to the record system, check each against what its business associate agreement actually covers, cut it back, and set an expiry date. Most organizations find accounts belonging to vendors they no longer use.
- 4
Rebuild emergency access so it proves itself
1 weekAuto-expiring, alerting, logged, and tested with clinical staff before it counts. Then keep the test dates — the dates are the evidence.
- 5
Write the asset inventory down
3–5 daysNot required in a prescribed form today, and squarely in the proposal. Doing it now costs a few days and removes a scramble later.
Total, realistically: six to ten weeks of focused effort, spread across a team that also has a phone system to run. That is why it slips, and it is why sequencing matters more than completeness — step one closes the exposure the others are protecting.
Where vaultIAM fits
We run a read-only assessment against your existing systems, using a query list published before you grant any access, and score identity risk across ten categories weighted for healthcare. You get the gaps ranked by risk reduction per hour of work, mapped to the Security Rule sections above.
If you want the work done, we take one item at a time — six to eight weeks each, fixed scope — and hand it back with the runbook. The four-person team runs it afterwards; that is the point.