The HIPAA Security Rule Finalization Is Coming in May 2026. Your AI Authorization Gap Is Already Here.

In May 2026, the Office for Civil Rights is expected to finalize the first meaningful update to the HIPAA Security Rule in over a decade. The words "AI authorization" will not appear in the text. That is precisely the problem — because every obligation the final rule does impose will land on AI systems that have no authorization layer capable of satisfying it.

Healthcare CISOs who read the rule looking for an "AI section" will miss the enforcement. Healthcare CISOs who read it assuming every existing control now applies to every AI agent touching ePHI — with no "addressable" escape hatch, under a continuous reassessment standard — will understand what is actually about to happen.

This is a compliance deadline disguised as a cybersecurity update.

Table of contents

• What the May 2026 final rule will and will not change
• What the NPRM actually says about AI
• A scenario OCR auditors will recognize
• The Authorization Gap in healthcare AI
• Five controls the final rule will force you to prove
• Why traditional IAM cannot close the gap
• A 90-day readiness path

What the May 2026 final rule will and will not change

The HIPAA Security Rule has not received a meaningful update since the 2013 Omnibus Final Rule. On December 27, 2024, HHS OCR issued a Notice of Proposed Rulemaking (NPRM) that would substantially rewrite it. The comment period closed in March 2025 with nearly 5,000 submissions. OCR has kept the final rule on its official regulatory agenda with a target publication date of May 2026, and most legal analysts expect a compliance window of 180 to 240 days — putting the effective deadline between late 2026 and early 2027.

What will change is significant. The NPRM eliminates the distinction between "required" and "addressable" implementation specifications — meaning previously optional controls like multi-factor authentication, encryption of ePHI at rest and in transit, and vulnerability scanning become mandatory with narrowly documented exceptions. It introduces written technology asset inventories, network segmentation, 72-hour system restoration, annual penetration testing, six-month vulnerability scanning, and annual written evaluations of technical safeguards by subject matter experts.

What does not change is the foundation. HIPAA still requires covered entities and business associates to ensure the confidentiality, integrity, and availability of ePHI, and to enforce the Minimum Necessary Standard — the principle that access to protected health information must be limited to what is strictly required for the permitted purpose.

That last part is where AI breaks the model.

What the NPRM actually says about AI

Be precise here, because the industry has not been.

OCR deliberately declined to set standalone AI rules in the NPRM, instead requesting additional input — a restraint noted by McGuireWoods, Alston & Bird, and others. What OCR did do is fold AI into the broader Security Rule architecture in four ways:

1. Technology asset inventory. AI software that creates, receives, maintains, or transmits ePHI — or interacts with ePHI, including systems where ePHI is used to train models — must appear in the regulated entity's written technology asset inventory, which feeds directly into the required risk analysis.

2. Risk analysis on AI systems. Regulated entities must consider the type and amount of ePHI accessed by any AI tool, who the data is disclosed to, and who receives the output. OCR references the NIST AI Risk Management Framework as a suggested resource.

3. Continuous risk reassessment. Risk analysis is no longer a one-time exercise. The NPRM requires repeated analyses that account for changes affecting confidentiality, integrity, and availability of ePHI — including changes to AI models, training data, and downstream prompts.

4. Audit logging and patch management. Covered entities must monitor authoritative sources for known AI vulnerabilities, remediate critical and high-risk issues promptly, and document every interaction involving PHI — prompts, responses, file uploads.

Layer these AI-specific obligations on top of the NPRM's broader mandates — mandatory MFA, mandatory encryption, mandatory access controls, mandatory decision-level audit trails, elimination of the "addressable" escape hatch — and the effective obligation becomes unambiguous, even if the word "authorization" never appears next to "AI" in the final text.

Healthcare CISOs will have to prove, on demand, that every AI system touching ePHI is inventoried, access-controlled, continuously risk-assessed, and fully audit-logged.

That is an authorization problem. It just has not been labeled one.

A scenario OCR auditors will recognize

Picture the request a compliance officer will receive in the first round of Phase 4 audits.

A regional health system has deployed an ambient documentation AI across 400 clinicians. The model listens to patient encounters, drafts clinical notes, and writes back to the EHR. The health system also runs a prior authorization agent that reads patient charts and submits coverage requests to payers, and a patient-facing triage chatbot that pulls problem-list summaries for logged-in users.

The OCR audit letter asks three things:

• Produce the complete inventory of AI systems with access to ePHI, including model versions, training data provenance, and the service identities each uses.
• Produce the authorization policies that govern which records each AI can access, under which permitted purpose, with which Minimum Necessary constraints.
• Produce the decision-level audit log showing every access request made by these AI systems over the prior 90 days — approvals, denials, and the policy evaluations that drove each outcome.

Most healthcare organizations today can produce one and a half of these three. The inventory exists in a spreadsheet updated quarterly. The policies exist in PDFs that describe intent, not enforcement. The audit log exists in fragments — EHR access logs over here, API gateway logs over there, nothing correlated at the decision level.

After May 2026, one-and-a-half of three is a finding.

The Authorization Gap in healthcare AI

Authentication answers "who is this?" Authorization answers "what is this identity allowed to do, with which data, under which conditions, right now?"

Healthcare IT has always handled authorization through a patchwork: EHR role-based access controls, identity governance provisioning workflows, database row-level security, application-layer permissions. The model assumed two things that are no longer true.

Assumption one: the identity doing the work is a human. Clinicians, administrators, billers, occasionally a service account running overnight ETL. Today, non-human identities — AI agents, copilots, pipelines, service accounts, model endpoints — outnumber humans by roughly an order of magnitude in most enterprise environments. Ambient scribes, prior authorization bots, clinical decision support models, triage chatbots, and the service identities that orchestrate them. Most were provisioned without authorization policies attached.

Assumption two: access decisions can be made once, at provisioning time. Role-based access control assigns a role, grants permissions, and moves on. An AI model that summarizes patient records at 9:00 a.m. has the same access at 2:00 a.m., the same access when queried by an unapproved downstream application, the same access after its behavior drifts from training distribution. The NPRM's requirement for continuous risk reassessment cannot be satisfied by a provisioning-time decision.

This is the Authorization Gap: the delta between what healthcare organizations have deployed and what the NPRM will require them to prove — continuous, policy-governed, fully logged authorization for every identity, human and non-human, interacting with ePHI.

HIPAA did not create the gap. HIPAA is the regulator about to force it into view.

Five controls the final rule will force you to prove

Reading the NPRM against the operational reality of healthcare AI, five controls matter most:

1. A live inventory of every AI identity with access to ePHI. Not a spreadsheet. A continuous, queryable inventory of every AI system, agent, model, API key, and service account that can see, move, train on, or produce ePHI — refreshed as environments change, not as surveys are sent.

2. Authorization policies versioned and tested as code, before they reach production. This is the control that distinguishes compliant programs from compliant-on-paper programs. Policies governing AI access to ePHI — Minimum Necessary enforcement, permitted purpose constraints, sensitivity-based access logic — written as policy-as-code (OPA/Rego or equivalent), versioned in Git, unit-tested in CI, reviewed in pull requests. When an OCR auditor asks "how do you know this policy was in force on April 14?", the answer is a commit hash, not a meeting note.

3. Continuous authorization for non-human identities. AI agents are not permanent employees. Their authorization context changes based on who invoked them, what task they are executing, which data is in scope, and what the downstream consumer will do with the output. Evaluated at every call, not granted at onboarding.

4. Decision-level audit logs. Not "agent X accessed record Y." Every authorization decision — approvals, denials, policy evaluations, the contextual inputs that drove the outcome — in an immutable log producible for OCR on request.

5. Risk signal integrated into authorization. When a foundation model vulnerability is disclosed, when an AI system's behavior drifts, when a prompt injection attempt is detected, the authorization layer responds — narrowing scope, requiring re-authentication, or blocking access — without waiting for a human to file a change ticket.

Any regulated entity that cannot demonstrate these five in 2027 will have a hard time closing an OCR investigation.

Why traditional IAM cannot close the gap

Existing identity and access management was built for a human-first, provisioning-time world. It does three things well: federate identity, assign roles, log session-level access. It does three things poorly, which are precisely the things the final rule will demand.

• It conflates authentication with authorization. Okta, Entra, and Ping answer "who is this?" They do not make per-action authorization decisions for an AI agent operating against ePHI.
• It is provisioning-time, not runtime. SailPoint, Saviynt, and comparable platforms assign access and review it quarterly. The NPRM requires continuous, risk-informed authorization — a different architecture.
• It was not designed for non-human identities at 10:1 or 100:1 scale. The lifecycle assumptions — HR feed, joiners-movers-leavers, quarterly access reviews — do not translate to AI agents that spawn, execute, and terminate in seconds.

Closing the gap requires a control plane alongside existing IAM: a policy-as-code authorization layer that evaluates every action, for every identity, against every policy, every time. That is the category EnforceAuth was built for.

A 90-day readiness path

The final rule is expected in May. Compliance dates will likely land six to eight months later. Organizations that wait for publication will be behind.

Days 1–30 — inventory and gap analysis. Identify every AI system, model, agent, and service identity touching ePHI across clinical, administrative, and research environments. Map current authorization mechanisms. Flag systems with no authorization layer beyond authentication — that is the gap surface area.

Days 31–60 — policy foundation. Codify the authorization policies that should govern AI access to ePHI: Minimum Necessary, permitted purpose, sensitivity classifications, context-aware logic. Draft them as policy-as-code, not PDFs. Test them against historical access patterns.

Days 61–90 — runtime enforcement pilot. Deploy continuous authorization against a bounded set of AI systems — an ambient documentation tool, a prior authorization agent, a clinical decision support model. Instrument decision-level audit logs. Validate that denials, approvals, and evaluations are captured in a form that satisfies an OCR records request.

By the time the final rule publishes, the regulated entities that win are the ones with working enforcement in at least one production environment and a repeatable path to scale it.

See EnforceAuth in a healthcare environment

EnforceAuth is the AI Security Fabric purpose-built to close the Authorization Gap across applications, infrastructure, data, and AI workloads — for human and non-human identities. Continuous, policy-as-code authorization. Decision-level audit logs. Built for the reality where AI identities outnumber human ones.

Book a healthcare-specific demo →

See how a healthcare organization inventories every AI identity touching ePHI, enforces Minimum Necessary at runtime, and produces OCR-ready decision logs — in 30 minutes.

Informational only; not legal advice. The HIPAA Security Rule final rule has not yet been published; all citations reference the NPRM issued December 27, 2024 and OCR's official regulatory agenda. Consult counsel on your specific compliance obligations.