HIPAA 2026 Identity Controls: Was die geplante Regel vorschreibt und wie Sie sich vorbereiten
Die geplante Überarbeitung der HIPAA Security Rule schließt die "addressable"-Lücke und macht MFA, Access-Reviews und Asset-Inventare zur Pflicht. Was sich ändert - und wie Sie sich vorbereiten, bevor die Uhr tickt.
8 Min. Lesezeit · Zuletzt aktualisiert Juli 2026
Statushinweis (Juni 2026): Die in diesem Beitrag beschriebene Überarbeitung der HIPAA Security Rule ist noch eine geplante Regel - OCR hat noch keine endgültige Regel veröffentlicht, und der Zeitplan für die Finalisierung ist weiterhin offen. Das NPRM wurde am 6. Januar 2025 veröffentlicht; die Kommentierungsfrist endete am 7. März 2025. [1] bestätigt, dass das für Frühjahr 2026 erwartete Finalisierungsfenster verstrichen ist, ohne dass etwas veröffentlicht wurde. Sobald eine endgültige Regel in Kraft tritt, ist mit einem Umsetzungszeitraum von etwa 180 bis 240 Tagen zu rechnen. Bereiten Sie sich jetzt vor - implementieren Sie präzise, sobald der endgültige Text vorliegt.
Das Gesundheitswesen hat ein offenes Geheimnis, das jede Compliance-Verantwortliche und jeder Compliance-Verantwortlicher kennt: Der Identity-Perimeter wird mit Excel-Listen, manuellen Tickets und gutem Willen zusammengehalten. Die geplante Überarbeitung der HIPAA Security Rule wird das unhaltbar machen. Zum ersten Mal seit über einem Jahrzehnt schlägt OCR vor, die Unterscheidung zwischen "required" und "addressable" abzuschaffen - jene Regelung, die es Organisationen ermöglichte, sich durch Dokumentation um Kontrollen wie MFA herumzudrücken. Wenn die Regel in ihrer vorgeschlagenen Form in Kraft tritt, gibt es kein Opt-out mehr - und der schwierigste Teil wird nicht die Technologie sein. Es werden die Menschen sein.
Was die geplante Regel konkret ändert
HHS veröffentlichte den Notice of Proposed Rulemaking (NPRM) am 6. Januar 2025 - die bedeutendste geplante Aktualisierung der HIPAA Security Rule seit Inkrafttreten der ursprünglichen Regel. Die strukturelle Verschiebung ist klar, aber weitreichend: [2] beschreibt, wie die geplanten Änderungen die Unterscheidung zwischen "required" und "addressable" abschaffen und MFA, Verschlüsselung sowie weitere Schutzmaßnahmen zu verpflichtenden Kontrollen machen - nicht mehr zu optionalen, "addressable" Maßnahmen.
Was das in der Praxis bedeutet: Organisationen können sich nicht länger durch die Dokumentation eines alternativen Ansatzes aus der Pflicht stehlen. [3] bringt es auf den Punkt - Organisationen können sich nicht mehr durch Dokumentation um die Umsetzung einer Kontrolle drücken; wenn die Regel die Implementierung vorschreibt, muss sie implementiert werden.
Die sechs Kontrollen, die für Identity am wichtigsten sind
Die geplante Regel führt eine Reihe identitätsspezifischer Anforderungen ein, die Compliance-Teams auf operativer Ebene verstehen müssen:
1. Verpflichtende MFA - überall, wo ePHI berührt wird
[4] fasst die drei Zugriffskategorien zusammen, für die MFA verpflichtend wäre: privilegierter und administrativer Zugriff (Cloud-Konsolen, EHR/EMR-Systeme, Datenbanken); Workforce-Zugriff (interne Tools, E-Mail, Webanwendungen); sowie Zugriff durch Dritte und Anbieter (VPNs, Patientenportale, Remote-Support-Tools). Die geplante Regel würde die Möglichkeit abschaffen, auf MFA auf Basis einer Risikobewertung zu verzichten.
Eine wichtige Nuance: [5] weist darauf hin, dass SMS-basierte Zwei-Faktor-Authentifizierung gemäß der geplanten Regelung nicht zulässig ist - HHS verweist auf NIST SP 800-63B Authenticator Assurance Level 2 oder höher, was SMS ausschließt. Wenn Ihr aktueller MFA-Rollout auf SMS-Nachrichten basiert, ist das eine Lücke, die jetzt geschlossen werden muss.
2. Technologie-Asset- und Identity-Inventar
[6] beschreibt die geplante Anforderung: Jede Organisation muss ein aktuelles Inventar aller Technologie-Assets führen, die ePHI verarbeiten, speichern oder übertragen - einschließlich einer Netzwerkkarte, die den Datenfluss von ePHI zwischen internen Systemen und externen Partnern nachverfolgt. MFA lässt sich nicht auf Systemen durchsetzen, die nicht erfasst wurden - und Access-Reviews lassen sich nicht für User durchführen, deren App-Zugriffe nicht sichtbar sind.
3. Regelmäßige Access-Reviews und Beendigung des Workforce-Zugriffs
[7] hebt eine der operativ anspruchsvollsten Bestimmungen hervor: Die geplante Regel enthält eine Anforderung zur Beendigung des Workforce-Zugriffs innerhalb einer Stunde. Das ist kein Tippfehler. Eine Stunde von der Kündigung bis zur vollständigen Deprovisionierung über alle ePHI-berührenden Systeme hinweg - EHR, VPN, Cloud-Portale, SaaS-Apps, alles.
4. Jährliche Compliance-Audits
[2] stellt fest, dass Covered Entities und Business Associates mindestens einmal jährlich umfassende Compliance-Audits durchführen und dokumentieren müssen - mit formaler Prüfung und Verifizierung administrativer, physischer und technischer Schutzmaßnahmen alle 12 Monate.
5. Gleichstellung der Business Associates
[1] ist eindeutig: Die verpflichtenden Bestimmungen der aktualisierten Regel gelten für Business Associates ebenso wie für Covered Entities. Als BA wird Ihre Compliance-Position zum Wettbewerbsvorteil - Covered Entities werden zunehmend erwarten, dass Sie diese nachweisen können.
6. Compliance-Zeitplan
[7] erläutert die Mechanik: Sobald die endgültige Regel veröffentlicht wird, tritt sie 60 Tage später in Kraft, und die Compliance ist 180 Tage danach erforderlich - insgesamt 240 Tage. [8] schätzt die Compliance-Kosten im ersten Jahr auf rund 9 Milliarden US-Dollar für Covered Entities und Business Associates zusammen. Diese Zahl erklärt, warum Organisationen, die jetzt beginnen, deutlich weniger ausgeben werden als jene, die nach der Veröffentlichung in Hektik verfallen.
The proposed rule is not yet final. OCR has not published a final rule as of June 2026, and the finalization timeline is unconfirmed. A coalition of 100+ hospital and provider groups has asked HHS to withdraw the proposal. Prepare your identity program against the proposed controls — they represent security best practices regardless — but implement formally once the final text is published and your 180-day clock is confirmed.
Warum die hohe Fluktuation im Gesundheitswesen dieses Problem zum schwierigsten im Raum macht
Hier wird die Compliance-Diskussion konkret. Jede Identity-Kontrolle in der geplanten Regel - MFA-Enrollment, Access-Reviews, Deprovisionierung - setzt voraus, dass man weiß, wer gerade auf was Zugriff hat. Und das Gesundheitswesen macht genau das außerordentlich schwierig.
Die Fluktuationsrate in Krankenhäusern sank 2024 auf 18,3 %, im ambulanten Pflegebereich liegt sie jedoch bei rund 79,2 % jährlich. ([9]) Selbst auf Krankenhausebene bedeuten diese 18,3 %, dass etwa jede fünfte Mitarbeiterin oder jeder fünfte Mitarbeiter jedes Jahr das Unternehmen verlässt. Pflegekräfte, medizinische Fachangestellte, Auftragnehmer, Vertretungsärzte, Reisepersonal - die Belegschaft ist in ständiger Bewegung.
Das daraus resultierende Zugriffsrisiko potenziert sich. Eine Pflegekraft, die im Januar geht, hat möglicherweise im März noch aktive Zugangsdaten zum EHR. Ein Auftragnehmer, dessen Einsatz beendet wurde, hat möglicherweise noch VPN-Zugriff. [10] empfiehlt, HR-Daten regelmäßig mit aktiven Konten in kritischen Systemen abzugleichen, um verwaiste Konten zu identifizieren - aber in einer manuellen Welt findet dieser Abgleich bestenfalls quartalsweise statt und deckt nur die Systeme ab, an die jemand gedacht hat.
Die geplante Einstunden-Anforderung für die Zugriffsbeendigung erhöht nicht nur die Messlatte - sie legt die Lücke offen. Die meisten Gesundheitsorganisationen können heute eine ausscheidende Mitarbeiterin oder einen ausscheidenden Mitarbeiter nicht innerhalb einer Stunde aus allen ePHI-berührenden Systemen deprovisionieren. Sie haben keine vollständige Liste dieser Systeme, und der Deprovisionierungsprozess umfasst manuelle Tickets an IT, HR und Abteilungsleiter.
Das Problem mit der Abdeckung von Auftragnehmern und klinischem Personal
Auftragnehmer und Reisekliniker verschärfen das Problem zusätzlich. Sie greifen häufig über nicht standardisierte Wege auf EHRs und klinische Apps zu - direkte Logins, gemeinsam genutzte Zugangsdaten oder Zugriffe, die außerhalb des normalen Provisionierungs-Workflows gewährt wurden. [11] weist darauf hin, dass der Joiner-Mover-Leaver-Lifecycle eine Automatisierung von Provisionierung, Rollenänderungen und schneller Deprovisionierung erfordert - aber dieser Lifecycle funktioniert nur, wenn jede App im Scope ist, einschließlich jener ohne SCIM-Konnektoren oder API-Integrationen.
Genau hier hinterlassen SSO-only- und SCIM-only-Identity-Tools eine gefährliche Lücke. Wenn Ihre Governance-Plattform nur die Apps abdeckt, die SCIM unterstützen, haben Sie einen blinden Fleck für jedes klinische Tool, jedes Legacy-System und jede Long-Tail-SaaS-App, die das nicht tut. Ein Auditor, der eine vollständige Access-Zertifizierung über alle ePHI-berührenden Systeme anfordert, wird diesen blinden Fleck sofort finden.
Ein praxisorientierter Identity-Readiness-Plan
Das Compliance-Fenster der geplanten Regel - rund 180 Tage nach der Finalisierung - klingt nach viel Zeit. Für ein Gesundheitssystem mit mehreren Standorten oder einen Business Associate mit einem komplexen App-Stack ist es das nicht. So sollten Sie die Arbeit sequenzieren.
You cannot govern access to systems you haven't catalogued. Start with a complete inventory of every application, system, and cloud service that creates, receives, maintains, or transmits ePHI — including apps without SCIM or APIs. Map which users (workforce, contractors, vendors) have access to each. This inventory is the foundation for every other control: MFA coverage mapping, access reviews, and deprovisioning workflows.
For every system on your inventory, document whether MFA is currently enforced and what factor type is in use. Flag any reliance on SMS-based 2FA — the proposed rule aligns with NIST SP 800-63B AAL2, which excludes SMS. Prioritize remote access (VPN, ZTNA), EHR/EMR systems, cloud admin consoles, and any internet-facing application tied to ePHI.
The proposed one-hour termination requirement is operationally impossible to meet manually at scale. Automate deprovisioning triggers from your HRIS so that a termination event immediately kicks off access revocation across all connected systems — not just the SCIM-enabled ones. Include contractors and traveling staff, not just full-time employees.
Periodic access reviews need to become a continuous, documented process — not a quarterly spreadsheet exercise. Implement access certification campaigns that route to data owners and department heads, capture attestations, and auto-revoke access that isn't recertified. Every certification decision needs an immutable audit trail that an OCR investigator can pull on demand.
Apply least-privilege principles to all third-party accounts: time-limited access, MFA-protected, scoped to only the systems they need. Reconcile vendor access against active BAAs quarterly. For high-risk vendors with EHR or medical device access, implement heightened monitoring and more frequent access reviews.
The proposed rule shifts HIPAA from a principles-based framework to an evidence-based one. Every control needs documentation: MFA enrollment rates, access review completion records, deprovisioning timestamps, audit logs. Build your evidence library now so that when the compliance window opens, you're validating — not scrambling to create artifacts from scratch.
Wo Iden ins Spiel kommt
Der schwierigste Teil der HIPAA-Identity-Readiness ist nicht MFA in Ihrem EHR - das übernimmt wahrscheinlich Ihr EHR-Anbieter. Der schwierige Teil ist alles andere: die 40+ SaaS-Apps, die Ihr klinisches und administratives Personal täglich nutzt, die Auftragnehmer-Accounts, die außerhalb des normalen Workflows provisioniert wurden, die Legacy-Tools, die kein SCIM unterstützen und daher bei den meisten Governance-Plattformen komplett außen vor bleiben.
Idens universelle Konnektoren-Technologie deckt Apps ab, unabhängig davon, ob sie SCIM, APIs oder beides nicht unterstützen - das bedeutet, dass Ihr Zugriffsbestandsverzeichnis und Ihre Zertifizierungskampagnen sich auf Ihren gesamten Stack erstrecken, nicht nur auf die unkomplizierten Apps. Automatisierte Offboarding-Trigger aus Ihrem HRIS werden gleichzeitig über alle verbundenen Systeme ausgelöst und machen die Einstunden-Anforderung zur Zugriffsbeendigung erreichbar statt nur wünschenswert. Und jede Provisionierungsentscheidung, jedes Access-Review und jedes Deprovisionierungsereignis wird in einem unveränderlichen Audit-Log erfasst - genau das Artefakt, das ein OCR-Ermittler oder externer Auditor anfordern wird.
Für Gesundheitsorganisationen, die an der Schnittstelle von hoher Fluktuation und verpflichtenden Zugriffskontrollen navigieren, ist diese Abdeckungslücke der Unterschied zwischen einer vertretbaren Compliance-Position und einem Befund.
HIPAA 2026 Identity-Readiness-Checkliste
Nutzen Sie diese Checkliste, um Ihre aktuelle Position gegenüber den Identity-Kontrollen der geplanten Regel zu bewerten. Sie ist gleichzeitig die Artefaktliste, die ein Auditor durcharbeiten wird.
Fazit
Die geplante Überarbeitung der HIPAA Security Rule ist das folgenreichste Identity-Compliance-Ereignis im Gesundheitswesen seit zwei Jahrzehnten. Die Ära der "addressable"-Ausnahmen geht zu Ende. Wenn die endgültige Regel veröffentlicht wird - und die 180-Tage-Uhr zu ticken beginnt - werden Organisationen, die bereits kontinuierliche Access-Governance, automatisiertes Offboarding und ein vollständiges Identity-Inventar aufgebaut haben, dieses Fenster zur Validierung nutzen. Alle anderen werden unter Termindruck von Grund auf neu aufbauen.
Die Identity-Kontrollen, die die geplante Regel vorschreibt, sind keine neuartigen Sicherheitsideen. Sie sind das, was ein gut geführtes Identity-Programm ohnehin bereits tut. Die Frage ist, ob Ihr aktuelles Tooling Ihren gesamten App-Stack abdeckt - oder nur die einfache Hälfte davon.
Weiteren Kontext zum regulatorischen Hintergrund finden Sie in unseren Beiträgen zu Der größte HIPAA Security Rule-Umbruch seit Jahren und HIPAA & DSGVO navigieren.
Is the 2026 HIPAA Security Rule final?
No. As of June 2026, OCR has not published a final rule. The NPRM was published January 6, 2025, and the comment period closed March 7, 2025. OCR's regulatory agenda had targeted a May 2026 finalization, but that window has passed with no final rule issued. The proposed requirements and their timing could still change, be delayed, or be withdrawn. Organizations should prepare against the proposed controls — which represent security best practices regardless — but implement formally once the final text is published.
What does the proposed rule mean for MFA specifically?
The proposed rule would make MFA mandatory for all interactive access to ePHI — including EHR/EMR systems, VPNs, cloud admin consoles, and third-party vendor access. It eliminates the current 'addressable' flexibility that allowed organizations to document an alternative approach. The proposed rule also aligns with NIST SP 800-63B AAL2, which excludes SMS-based 2FA as an acceptable factor.
What is the proposed compliance window after the final rule publishes?
The proposed rule includes a 240-day total window: 60 days until the rule takes effect, then 180 days until compliance is mandatory. Business Associate Agreements must be updated within one year of the effective date. The exact window will be confirmed in the final rule text.
Why is healthcare staff turnover a HIPAA identity risk?
High turnover — hospital rates around 18.3% annually, home-care rates near 79.2% — means a constant churn of accounts that need to be provisioned and deprovisioned. The proposed rule includes a one-hour workforce access termination requirement, which is operationally impossible to meet manually across a complex app stack. Orphaned accounts from departed staff represent both a security risk and a compliance finding.
Does the proposed rule apply to business associates?
Yes. The proposed mandatory provisions apply to business associates just as they do to covered entities. Covered entities will increasingly expect their BAs to demonstrate compliance, making a strong identity governance posture a competitive differentiator for BAs operating in the healthcare space.
What identity artifacts will an OCR auditor ask for?
Expect requests for: a complete technology asset inventory showing all ePHI-touching systems; MFA enrollment and coverage reports by system and user population; access certification records with attestation timestamps; deprovisioning logs showing time-from-termination to access revocation; audit logs capturing ePHI access events; and updated BAAs. Every artifact needs to be producible on demand, not reconstructed after the fact.