HIPAA Security Rule for Patient Portals: The Definitive 2026 Guide

A patient portal has two very different user populations: the workforce that runs it and the patients who log in to it. The HIPAA Security Rule, and the overhaul HHS proposed in January 2025, were written largely around the first group. Several of the portal incidents on public record, though, ran through patient-facing pathways: tracking code on logged-in pages, reused passwords, and caregiver logins shared outside any proxy feature.

This guide separates what is enforceable today from what is only proposed, then works through the portal-specific questions the rule text does not answer directly.

What applies today

• The current Security Rule at 45 CFR 164.312 (technical safeguards) applies to any portal that creates, receives, maintains, or transmits ePHI for a covered entity or business associate.
• Risk analysis, unique user IDs, audit controls, and person or entity authentication are required now. Automatic logoff and encryption are "addressable" specifications.
• OCR's guidance on tracking technologies still treats logged-in portal pages as generally having access to PHI.

What changes only if the proposal is finalized

• Multi-factor authentication, encryption at rest and in transit, and the end of the "addressable" category.
• Fixed patching windows, real-time activity monitoring, and annual compliance audits.
• As of the verified date above, the Unified Agenda lists the final rule as a long-term action with a July 2027 target.

Where the HIPAA Security Rule stands

Short answer: The updated HIPAA Security Rule is still a proposal. HHS published the notice of proposed rulemaking on January 6, 2025, and the most recent Unified Agenda edition (labelled 2026 on reginfo.gov) lists the final action under "Long-Term Actions" with a July 2027 target. That date is an agency estimate, not a commitment, and the existing rule remains fully enforceable in the meantime.

If a final rule is published, the proposal says it would take effect 60 days later, and the general HIPAA compliance period of 180 days would then apply, according to the applicability section of the proposed rule. That structure is itself proposed and could change.

Cost is a central point of contention. HHS's own regulatory impact analysis in the proposed rule estimated first-year costs of roughly $9 billion, and a coalition of industry associations including CHIME and MGMA asked the White House to rescind the proposal, calling that figure a "woefully inadequate estimate." OCR Director Paula M. Stannard, speaking at HIMSS in March 2026, said OCR was reviewing about 4,700 comments and that "the Trump administration may have a different view on the burdens and benefits of some of the proposed changes," while also arguing that "[t]here's a very high cost of doing nothing".

For portal owners, the practical reading is simple: plan against the current rule, and treat the proposal as a signal of where OCR expects security programs to go.

Does the HIPAA Security Rule apply to your patient portal?

Short answer: It applies when the portal handles electronic protected health information for a HIPAA covered entity (a health plan, clearinghouse, or provider that conducts standard electronic transactions) or for that entity's business associate. A portal run by a company that is neither, such as a direct-to-consumer health app, usually falls outside HIPAA and under other rules.

Three ownership patterns cover most portals:

• Provider or health plan portals. The covered entity is directly responsible, whether the portal is built in-house or licensed.
• Vendor-hosted portals. HHS treats cloud service providers and IT vendors that handle ePHI for a covered entity as business associates, so a vendor that hosts or maintains a portal typically is one. Business associates are directly liable for applicable Security Rule requirements and need a business associate agreement.
• Pharma patient support program and hub portals. These need a case-by-case answer. Drug manufacturers are generally not covered entities, but a hub or program vendor may act as a business associate of providers or pharmacies for some functions, and may collect data under patient authorization for others. Map each data flow, because the answer can differ within one program. Our guide to patient support programs and our comparison of PSP rules in the US and EU cover the wider program context.

When a portal or app sits outside HIPAA, it is not unregulated. The Federal Trade Commission's 2024 changes to the Health Breach Notification Rule underscore that the rule applies to "health apps and similar technologies not covered by HIPAA," and state privacy laws may also apply.

Patient portal security requirements, safeguard by safeguard

Short answer: Today a portal needs a documented risk analysis, unique user identification, audit controls, person or entity authentication, and transmission security. Automatic logoff, encryption, and transmission integrity controls are addressable, which means you implement them or document why an equivalent measure is reasonable. The proposal would make nearly all of these mandatory and more specific.

The current safeguards come from the eCFR text of 45 CFR 164.312 and the risk analysis standard in 45 CFR 164.308. The proposed column reflects the HHS fact sheet and the proposed regulatory text in the Federal Register notice, which would also add a technology asset inventory and network map, vulnerability scanning at least every six months, penetration testing at least every 12 months, and a 72-hour restoration plan for relevant systems.

For implementation detail, NIST's SP 800-66 Revision 2 (February 2024) is a resource guide for implementing the Security Rule that maps its standards and implementation specifications to NIST Cybersecurity Framework subcategories and SP 800-53 controls, which makes it a practical starting point for a portal control set.

Does HIPAA require MFA for patient portal logins?

Short answer: No current HIPAA rule requires multi-factor authentication for patient logins. The current rule requires authentication that fits your risk analysis. The proposed rule would require MFA for "users," defined as persons with authorized access, but its text does not say whether patients logging into a portal count. That question remains open.

Three layers matter here.

1. The current rule. Section 164.312(d) requires procedures "to verify that a person or entity seeking access to electronic protected health information" is "the one claimed," without naming a method. Your risk analysis decides what is reasonable, and a portal exposed to the internet carries credential risk.

2. The proposed text. Proposed 164.312(f)(2)(ii) would require entities to "deploy multi-factor authentication to all technology assets" in relevant systems "to verify that a person seeking access to the relevant electronic information system(s) is the user that the person claims to be." The proposal defines "user" as "a person with authorized access." The listed exceptions cover assets that cannot support MFA, emergencies, and certain FDA-authorized devices. None mentions patients or portals, according to the proposed regulatory text.

3. The preamble. The closest HHS comes to the question is an example about apps. When a provider lets individuals reach their records through an application that connects to its patient portal, the preamble says "not only must the individual be authenticated as a user, but the application must be authenticated" as well. That confirms patients must be authenticated. It does not say how.

Our reading, which counsel should confirm for your situation: a final rule could reach patient logins through the broad "user" definition, or HHS could clarify the scope. Either way, the safer path is to offer MFA to patients now and encourage it, rather than wait. HHS's voluntary Healthcare and Public Health Cybersecurity Performance Goals already list multifactor authentication among the essential goals, and NIST's SP 800-63B-4, finalized in July 2025 for government systems, is a useful reference for choosing authenticator strength by analogy.

Patient MFA has to stay usable. Older patients, caregivers, and people without a personal phone need recovery paths that do not push them back to shared passwords.

Three portal risks the rule text never names

Short answer: The Security Rule is technology-neutral, so it never names tracking pixels, credential stuffing, or shared caregiver logins. These three patient-facing risks appear repeatedly in reported portal incidents, and each one maps back to a safeguard you are already required to address through risk analysis.

1. Tracking technologies on logged-in pages

OCR's guidance on online tracking technologies names patient portals as user-authenticated webpages and states that tracking technologies on such pages "generally have access to PHI." The same page notes that on June 20, 2024, a federal court in Texas vacated the guidance only to the extent it covered certain visits to unauthenticated public webpages. The position on logged-in portal pages was not the part vacated.

Reported cases show the scale. Kaiser Permanente disclosed that tracking code on its websites and apps may have sent data on up to 13.4 million individuals to third parties. Advocate Aurora Health said it would notify about 3 million people potentially affected by tracking tools on its website, MyChart portal, and scheduling app. Novant Health disclosed that a Meta Pixel on its MyChart portal affected up to 1,362,296 individuals.

Control: inventory every script on authenticated pages, remove any vendor without a business associate agreement, and add script review to change control.

2. Credential stuffing and account takeover

Some patients reuse passwords, and attackers test leaked username and password pairs against portals. HHS's Health Sector Cybersecurity Coordination Center describes credential stuffing as attackers reusing compromised credentials tied to an individual. In 2023, attackers used credentials from other breaches against the UnitedHealthcare member app, and the company reset affected passwords. UW Health notified 4,318 patients after an unauthorized party accessed MyChart accounts over several months, and said it was moving to two-step validation and deactivating accounts inactive for 15 months. In 2026, Epic warned patients about scams that use the MyChart name, a brand-abuse problem rather than a flaw in the portal itself.

Control: failed-login lockout, breached-password screening, bot detection, patient MFA, alerts for new-device logins, and dormant-account deactivation.

3. Proxy access and shared passwords

ONC's analysis of 2024 national survey data found that 77% of individuals were offered online access to their records and that proxy access more than doubled between 2020 and 2024, from 24% to 51%. Where proxy features are weak, patients may share passwords instead. In a JAMA Internal Medicine study, personnel at 42 of 94 surveyed hospitals (45%) endorsed patients sharing passwords with caregivers, and few hospitals with proxy accounts let patients restrict what a proxy could see. For adolescents, a JAMA Network Open study estimated that more than half of adolescent accounts with outbound messages had been accessed by guardians at least once.

Control: a real proxy feature with its own credentials, granular sharing settings, age-based rules for adolescent records, and audit logs that show who acted, patient or proxy.

How do you secure a portal without blocking patient access?

Short answer: Security controls are allowed to limit access, but only when they meet the conditions of the information blocking security exception. Controls should be tailored to a specific risk, applied consistently, and documented, so that MFA, lockouts, and encryption protect records without becoming a barrier to a patient's right of access.

The ONC information blocking rule includes a security exception: it is not information blocking to interfere with access "in order to protect the security of EHI, provided certain conditions are met," per the ONC exceptions fact sheet. In practice, that means written policies, controls tied to identified security risks, and consistent application across patients.

The proposed Security Rule adds one portal-specific point. It would let an individual who asks for unencrypted delivery of their records under the right of access receive them that way after being told the risks, but that exception "would not apply when the individual would receive their ePHI using technology controlled by the regulated entity, such as a patient portal," according to the proposed rule's encryption discussion. A portal, in other words, would be expected to encrypt even when a patient would accept less.

A 2026 action plan for portal owners

Short answer: Start with a portal-specific risk analysis, a current OCR enforcement focus. Then close the patient-facing gaps (tracking scripts, credential attacks, proxy sharing), confirm business associate coverage, and use the proposed rule as your target architecture without waiting for it to be finalized.

OCR described its March 2026 settlement with MMG Fusion as the 12th enforcement action in its Risk Analysis Initiative. The wider threat picture explains why: OCR's 2024 breach report to Congress counted 663 breaches affecting 500 or more individuals in 2024, affecting about 242.9 million people in total, with hacking and IT incidents making up 81% of them.

1. Scope the portal in your risk analysis. List the web app, mobile app, APIs, identity provider, hosting, and every third-party script as assets.
2. Audit authenticated pages for tracking code. Remove or contract every vendor that can see portal traffic.
3. Harden patient login. Offer MFA, add lockout and breached-password checks, and monitor for credential stuffing.
4. Fix proxy access. Give caregivers their own accounts and stop advising password sharing.
5. Log patient and proxy activity. Make audit trails attributable to the person who acted.
6. Review business associate agreements. Ask portal and hosting vendors for their latest risk analysis summary, MFA coverage, encryption approach, patch timelines, and incident notice terms.
7. Document recognized security practices. Under Public Law 116-321, signed January 5, 2021, OCR must consider whether an entity can show recognized security practices were in place for the prior 12 months when determining fines and other remedies, so evidence of controls matters.
8. Gap-assess against the proposal. Treat MFA, encryption everywhere, asset inventory, and patch windows as your roadmap, so a final rule becomes a documentation exercise.

How Zelthy approaches portal security

Zelthy treats patients and staff as separate user groups, each with its own security settings. Each pharma program runs in its own isolated tenant, and every security setting is something you configure and can document, not a fixed default. Compliance still rests with the covered entity or business associate. The platform supplies the controls and the evidence that they are in place.

Many PSP and hub portals run on Zelthy. Here is how the platform handles the risks covered above.

Security settings for each user role. In Zelthy, authentication is set per user role, not once for the whole portal. A role can require multi-factor authentication through an authenticator app or SMS/email codes. It can also set how often passwords must be reset, how long a login token lasts, and whether a trusted device can skip MFA for a set number of days. So a program can require MFA for its staff today and offer it to patients, or phase it in for them, while the patient MFA question in the proposed rule is still open.

Protection against automated logins. The login page can score each sign-in attempt for bot risk with reCAPTCHA v3, using a cut-off the program sets. This slows the credential-stuffing attacks described earlier.

Tighter controls for staff. Staff roles can be limited to approved IP addresses, required to sign in through the organization's SSO, or blocked from API access. Patient logins are configured separately and are not affected.

Isolation between programs. Each program runs in its own tenant. One manufacturer's patient data is never stored alongside another's, and a security setting changed in one program does not affect any other.

Records you can audit. Patient records note who created or last changed them and when. Role assignments are tracked over time, so staff access can be reconstructed during an investigation or an OCR inquiry.

Code you can inspect. Zelthy is built on Zango, our open-source framework, and customers keep ownership of their application code. Security teams can review the actual controls instead of relying on a vendor questionnaire. That helps when you need to document recognized security practices.

Whatever platform you choose, use the action plan above as the checklist. Ask how each requirement is met, where the evidence lives, and who owns each control.

Frequently asked questions

Is the updated HIPAA Security Rule final?

No. As of October 29, 2026, the HIPAA Security Rule update is still a proposed rule published on January 6, 2025. The most recent Unified Agenda edition lists the final action as a long-term action with a July 2027 target, which is an agency estimate rather than a deadline.

Does HIPAA require MFA for patient portals?

No current HIPAA rule requires multi-factor authentication for patient logins, though patients must be authenticated. The proposed rule would require MFA for users with authorized access, but it does not say whether that includes patients, so offering MFA to patients now is the lower-risk choice.

Does a patient portal have to be encrypted?

Under the current rule, encryption is addressable, so you must encrypt or document why an equivalent measure is reasonable. The proposed rule would make encryption at rest and in transit mandatory, and its patient-request exception would not apply to portal delivery.

Are tracking pixels allowed on a patient portal?

They are not categorically banned, but OCR guidance says tracking technologies on logged-in portal pages generally have access to PHI. A vendor that receives that data needs a business associate agreement and a permitted purpose, and a 2024 court ruling did not change this for authenticated pages.

Can patients share their portal login with a caregiver?

Sharing a login defeats unique user identification and makes audit trails unreliable. The better practice is a proxy account with its own credentials and settings that let the patient control what the caregiver sees.

Does HIPAA apply to a pharma patient support program portal?

It depends on the data flow. Manufacturers are generally not covered entities, but a hub or program vendor can act as a business associate for some functions. Portals outside HIPAA may fall under the FTC Health Breach Notification Rule and state privacy laws.

Who is responsible if a portal vendor is breached?

Both parties carry obligations. A vendor that hosts a portal for a covered entity is typically a business associate that is directly liable for applicable Security Rule requirements and must report breaches to the covered entity, which in turn must notify affected individuals and HHS under the HIPAA Breach Notification Rule.

What is the expected timeline for the final rule?

The most recent Unified Agenda edition targets July 2027. If a final rule is published, the proposal says it would take effect 60 days later, with compliance generally due 180 days after that, so roughly eight months after publication.