Patient Portal Security: Enrolment, Proxy Access and Account Takeover

A patient portal is an internet-facing application holding medical records, operated for a user population you cannot train, on devices you do not manage, with a password reset flow that has to work for someone who last logged in three years ago. It is the hardest authentication problem in healthcare, and it is usually treated as a vendor checkbox.

Enrolment is the real attack surface

Most portal compromise does not defeat the login. It defeats registration — the attacker enrols as the patient before the patient does.

The weakness is identity proofing. If enrolment requires a name, date of birth and a medical record number, then anyone holding a leaked billing statement can register as that patient. Those three data points are not secrets; they appear on paperwork, in old breaches, and on the envelope.

Stronger options, roughly in order of assurance:

• In-person or at-registration activation — a code issued at check-in, tied to a verified identity. Highest assurance, and free if the workflow already exists.
• Out-of-band code to a phone or email already on file from a prior clinical encounter — not one supplied during registration.
• Knowledge-based verification against clinical facts the patient would know and a records thief would not — last appointment date, prescribing clinician.
• Third-party identity proofing for fully remote enrolment.

Proxy access, where the real complexity lives

Someone other than the patient legitimately needs access in many cases, and the rules differ by relationship and jurisdiction.

Two failure modes recur. The first is the adolescent transition — access that was correct at twelve must change at the age of majority for confidential services, and a portal that does not handle this automatically will disclose protected information to a parent. The second is revocation: proxy access granted during an illness and never removed, still live years later, sometimes after a relationship has ended.

Every proxy grant needs a review date. Treat it like any other privileged access, because that is what it is.

Authentication for people who are not employees

MFA is the right default, but the implementation has to account for a population that includes patients without smartphones and patients who will lock themselves out.

• Offer more than one second factor. SMS is weak against SIM swap but it is vastly better than nothing and many patients can use nothing else.
• Make account recovery as strong as enrolment. A recovery flow weaker than the front door is the front door.
• Rate-limit and lock progressively. Credential stuffing against portals is routine, using passwords leaked from unrelated sites.
• Do not expire passwords on a schedule. It drives reuse and recovery load without reducing risk.

Monitoring worth having

Portal-specific detections that catch real abuse:

• One IP address enrolling or attempting many distinct accounts
• A single account accessed from many IPs in a short window
• Bulk record downloads — normal for one patient, suspicious at scale
• Proxy relationships added shortly after a password reset
• Access to a record immediately after a name or contact change

Where this sits in HIPAA

Patient right of access is a legal obligation, and the portal is how most organisations meet it — so security controls that make the portal unusable create a different compliance problem. The balance to strike is strong identity proofing at enrolment, where friction is acceptable and happens once, rather than heavy friction on every login.

An attacker who successfully enrols as a patient has obtained records through a mechanism you built and authorised. Reconstructing what happened depends entirely on whether enrolment, proxy grants and record views are logged with enough fidelity to tell one person from another.

GuardsArm tests patient portals the way an attacker approaches them — enrolment abuse, proxy escalation, enumeration and account recovery — rather than only scanning the login page. Book a scoping call.