Patient Portal Security Features to Require

A patient portal looks simple from the outside: a login screen, a list of test results, a button to message the doctor. Underneath, it is one of the highest-risk pieces of software a healthcare organization will build, because it puts protected health information directly in front of the public internet and hands access control to the patient rather than a trained staff member. This article walks through the security features a patient portal actually needs, where the HIPAA Security Rule and ONC interoperability rules apply, and the architecture decisions that determine whether those features hold up under real use.

This is written for healthcare organizations and software teams scoping a new patient portal or auditing an existing one. It assumes you already know what a portal should do for patients; the focus here is what has to be true underneath for that functionality to be safe.

What a Patient Portal Actually Exposes

A typical portal surfaces lab results, visit summaries, medications, billing, secure messaging with care teams, and appointment scheduling. Some portals also expose proxy access for caregivers and parents, document uploads, and increasingly a connection to a patient-facing mobile app over a FHIR API.

Each of those features widens the attack surface in a different way:

• Lab and visit data is protected health information the moment it is tied to an identifiable patient, so every screen that renders it is in scope for the HIPAA Security Rule.
• Secure messaging creates a persistent record that needs the same retention, access logging, and breach-notification handling as any other PHI.
• Proxy and caregiver access multiplies the number of identities that can reach one patient's record, which is where portal security most often breaks down in practice.
• A public API behind the portal (for a mobile app, or for a patient-authorized third-party app under the information blocking rules) extends the trust boundary outside your own front end entirely.

None of this means a portal needs exotic security technology. It means ordinary controls (authentication, authorization, encryption, logging) have to be designed deliberately rather than inherited from a generic web application template.

Authentication and Access Control

Authentication is where most patient portal incidents start, because patients reuse passwords, share logins with family members, and rarely notice a suspicious session the way staff might. A few design decisions matter more than the rest:

• Unique identity per user, not per household. Every patient and every caregiver needs their own login, even when several people legitimately need to see the same chart. Shared logins make it impossible to satisfy the unique user identification requirement in the HIPAA Security Rule's technical safeguards, and they destroy the value of your audit log.
• Identity proofing before account creation. Verify that the person registering is actually the patient (or an authorized representative) before granting access, typically through a combination of demographic matching against the medical record and a verification code sent to a phone number or email already on file.
• Multi-factor authentication. HIPAA's current Security Rule does not name MFA explicitly, but it is the most direct way to satisfy the person-or-entity authentication standard for anything handling PHI, and it is the control that actually stops credential-stuffing attacks, which are the most common way portal accounts get compromised. NIST's digital identity guidelines are a reasonable technical baseline to design against, even outside federal systems.
• Proxy and delegate access with explicit scope. A parent accessing a minor's record, or an adult child helping an aging parent, needs access that is scoped, time-bound where appropriate, and revocable without disabling the patient's own account. Role-based access control at the record level, not just at the application level, is what makes this manageable.
• Session timeouts and automatic logoff. Because patients log in from shared or public devices more often than staff do, automatic logoff after inactivity is a baseline control, not an inconvenience to design around.

Worth noting: HHS proposed a significant overhaul of the Security Rule in late 2024 that would make several of these controls, including MFA, mandatory rather than addressable. As of this writing that rule has not been finalized, so it does not change your compliance obligations yet, but it is a reasonable signal of where enforcement expectations are heading, and building these controls now avoids a disruptive retrofit later.

Encryption and Transmission Security

PHI in a patient portal exists in three states, and each needs its own handling:

• At rest, in the application database, file storage for uploaded documents, and backups. Database-level encryption plus encrypted storage volumes covers most of this; the detail teams miss is backups and logs, which often contain the same PHI as the primary database but get a lower level of protection.
• In transit, between the patient's browser or mobile app and your servers, and between your servers and any EHR or lab system behind them. TLS for every connection, with no fallback to plain HTTP, is the minimum; internal service-to-service traffic deserves the same treatment, not just the public-facing edge.
• In use, meaning what is cached in browser memory, written to application logs, or included in error messages and analytics events. This is where PHI leaks most often in practice: a stack trace that includes a patient's name, or an analytics event that logs a lab result value because a developer needed it for debugging.

The HIPAA Security Rule's technical safeguards (45 CFR 164.312) treat encryption of data at rest and in transit as "addressable" rather than strictly required, which means you have to either implement it or document an equivalent alternative and the reasoning behind it. In practice, for a patient-facing system exposed to the public internet, there is rarely a credible alternative to encryption, so most organizations build it as a hard requirement regardless of the regulatory label.

Audit Logging That Holds Up Under Review

The Security Rule requires audit controls that record and examine activity on systems containing PHI. For a patient portal, that means logging who accessed which record, when, from where, and what they did, not just that a login occurred. A few practical requirements:

• Log access to specific records, not just application-level events. "User logged in" is not useful during an investigation; "user viewed lab result X for patient Y" is.
• Make logs tamper-evident. If the same credentials that can modify patient data can also edit the audit trail, the log cannot be trusted as evidence after an incident.
• Retain logs long enough to support a real investigation, and store them somewhere that survives the compromise of the primary application.
• Review logs proactively for anomalies (a staff account accessing an unusual volume of records, a patient account accessed from two distant locations within minutes) rather than only pulling them after something has already gone wrong.

We have covered the design details of healthcare audit logging, including what the rule actually requires and how to structure logs so they are useful during a security review, in a separate article on audit logging in healthcare software.

Patient Data Rights and the Information Blocking Rules

Patient portal security is not only about keeping data out of the wrong hands; federal rules also require getting it into the right ones without unnecessary friction. Under ONC's information blocking regulations, once a patient requests their electronic health information, a covered actor generally has to provide the full scope of that information electronically, not a curated summary, unless a specific exception applies. ONC has been explicit that this covers the full breadth of a patient's electronic health information, not a limited subset defined by convenience.

This has direct implications for portal design:

• Clinical notes, not just structured lab values, generally need to be accessible through the portal unless an exception (such as a documented risk of harm) applies.
• Delays built into the workflow to let a clinician review a result before the patient sees it need a legitimate basis; "we always hold results for review" as a blanket policy is the kind of practice the information blocking rule was written to discourage.
• If you expose a FHIR API so patients can connect third-party apps to their own data, as encouraged under the CMS interoperability and patient access rule, that API needs the same authentication, scoping, and rate-limiting discipline as the portal itself. A patient-authorized third-party app is a legitimate use case, not an edge case to bolt on later.

None of this is legal advice, and exceptions and enforcement details are genuinely complex; a compliance or healthcare attorney should review how these rules apply to your specific organization and patient population before you finalize a release policy.

Architecture Decisions That Determine Whether Security Holds Up

Features are only half the picture. How the portal is built determines whether those features keep working as the system grows.

• Portal as a client, not a data store. The more clinical data you copy into the portal's own database instead of retrieving it live from the EHR through a well-defined API, the more places that data can be exposed, and the more systems have to be kept in sync and secured. A thin portal that calls a FHIR API behind the scenes, discussed in more depth in our guide to FHIR and EHR integration, usually ages better than one that maintains its own duplicate copy of the chart. This is also the model behind our EHR and EMR integration work: keep the portal as a thin, well-secured client rather than a second system of record.
• Separate the public-facing layer from internal clinical systems. The portal's web and API layer should sit in its own network segment with tightly scoped access to backend systems, so a vulnerability in the public-facing code does not translate directly into access to the EHR.
• Design for account recovery abuse. Password reset and account recovery flows are a common weak point because they are tested less rigorously than login itself. Treat them with the same scrutiny: rate limiting, identity verification, and alerts on recovery attempts.
• Plan for mobile from the start if you will ever need it. A portal built only as a server-rendered website often needs a painful rebuild to support a native app later. If mobile access is even plausible within a few years, build the backend as an API first and the web portal as one consumer of it.

We go into more detail on the architecture and technical safeguards that apply across healthcare software generally, including telemedicine platforms that share many of the same patient-facing concerns, on our security and compliance overview page and in our telemedicine app development guide.

Common Mistakes

• Treating MFA as optional for patients because it adds friction to login. It adds friction, and it is also the single control most likely to stop a compromised account.
• Building proxy access as a shared login instead of scoped, individually authenticated delegate accounts.
• Logging enough to satisfy a checkbox but not enough to actually investigate an incident six months later.
• Storing more PHI inside the portal's own database than the portal needs, simply because it was easier than calling the EHR live.
• Assuming a vendor's marketing claim of "HIPAA compliant software" transfers compliance to you. Compliance is a property of how an organization implements, configures, and operates a system, including its administrative and physical safeguards, not a label a vendor can sell you.

Getting Started

Whether you are building a new patient portal or assessing one you already operate, the cheapest time to fix these issues is before launch. A short architecture and security review, covering authentication design, data flow between the portal and your EHR, audit logging, and how proxy access is handled, usually surfaces the gaps that matter most. If you are scoping a new portal or evaluating your current one, our team can walk through the architecture with you; see our healthcare software development services or book a strategy call to talk through your specific situation.

Frequently Asked Questions

Does a patient portal need to be "HIPAA compliant" to launch?

There is no certification that makes software itself "HIPAA compliant" in isolation. Compliance depends on how the organization operating the portal implements technical safeguards, administrative policies, workforce training, business associate agreements with vendors, and physical security, in addition to how the software is built. Treat any vendor claim of guaranteed compliance with caution and verify the underlying controls yourself.

Is two-factor authentication legally required for patient portals?

Not under the current HIPAA Security Rule, which treats most technical controls as "addressable" rather than mandatory. A proposed 2024 update to the rule would make multi-factor authentication required rather than addressable, but that update has not been finalized. Most organizations implement it anyway because it is the most effective control against the credential-based attacks that actually target portal accounts.

Can we delay releasing test results to patients through the portal?

Under ONC's information blocking rules, routinely delaying release of results as a blanket policy, without a patient-specific or legally recognized reason, can itself be considered information blocking. Any delay policy should be based on documented, defensible criteria rather than a general preference to have a clinician review results first.

What is the single highest-impact security control for a patient portal?

There is no single answer that fits every system, but unique per-user authentication combined with multi-factor authentication addresses the failure mode responsible for the largest share of real-world portal compromises: a reused or stolen password letting someone log in as the patient. Audit logging is a close second, because it determines whether you can even detect and respond to the incidents the other controls miss.

Do we need to expose a FHIR API if we already have a web-based portal?

Not necessarily for the web portal itself, but if you want patients to be able to connect their data to third-party apps of their choosing, which the CMS interoperability and patient access rule encourages, a standards-based FHIR API is the expected mechanism. Many organizations build the web portal as a client of that same API rather than maintaining two separate data paths.