Subscribe to the Non-Human & AI Identity Journal

What do healthcare IAM teams get wrong about patient portals and telehealth?

They often treat patient access as a front-end usability problem instead of a governance issue. Once portals, telehealth, and EHR-connected apps are linked, authentication, consent, and token scope all become part of the same identity surface. Ignoring that connection creates fragmented controls and higher operational burden.

Why This Matters for Security Teams

Patient portals and telehealth are often framed as UX and availability problems, but they create a shared identity surface that includes patients, support staff, clinicians, apps, APIs, and delegated access paths. Once token scope, consent, recovery, and session handling overlap, identity governance becomes the control plane. NIST’s NIST Cybersecurity Framework 2.0 emphasizes governance and access control for a reason: these services fail when identity decisions are left to application teams.

Health systems also underestimate how quickly one weak portal pattern propagates into telehealth and downstream EHR-connected apps. A single mis-scoped token or overbroad delegated consent can expose scheduling, prescriptions, messaging, and records access in one chain. NHIMG research shows how quickly identity exposure becomes operational risk, including Azure Key Vault privilege escalation exposure, which is a useful reminder that identity boundaries are rarely isolated once integrations begin.

In practice, many security teams encounter portal abuse, account takeover, or unauthorized proxy access only after patient data has already been accessed through a legitimate session, rather than through intentional identity design.

How It Works in Practice

The core mistake is treating patient access as a single login event instead of a lifecycle that spans registration, proofing, recovery, consent, delegation, session issuance, and revocation. For healthcare, the right question is not only “can the user authenticate?” but “what exactly is this identity allowed to do, on behalf of whom, for how long, and in which channel?” That aligns with the governance model reflected in NHI Mgmt Group’s Ultimate Guide to NHIs, because tokens, API keys, service accounts, and delegated access are all part of the same control surface once patient-facing apps integrate with clinical systems.

In practice, stronger programs separate the control planes:

  • Use step-up authentication for sensitive actions such as record sharing, medication changes, and caregiver delegation.
  • Bind sessions and tokens to specific scopes so a telehealth visit cannot silently expand into broader portal privileges.
  • Apply short-lived credentials and automatic revocation for app-to-app or provider workflow integrations.
  • Review consent continuously, not only at onboarding, especially when family members, proxies, or care coordinators are involved.
  • Track identity events across the portal, telehealth platform, and EHR-connected apps as one audit stream.

Current guidance suggests using policy-based decisions at runtime rather than static role assumptions, because patient intent, care context, and delegated access change from one interaction to the next. That is why the 2024 Non-Human Identity Security Report is relevant here: healthcare teams that manage integrations with long-lived secrets and broad privileges are managing the same risk pattern that drives account misuse elsewhere. These controls tend to break down when legacy EHR integrations require persistent credentials and the portal is forced to preserve backward compatibility.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance patient convenience against security, continuity of care, and support burden. That tradeoff is especially visible in family proxy access, interpreter workflows, urgent-care telehealth, and seasonal patient spikes, where rigid policies can create unsafe workarounds.

There is no universal standard for this yet, but best practice is evolving toward context-aware access. A patient may authenticate once, but the system still needs to distinguish between viewing lab results, joining a video visit, requesting a prescription refill, and authorizing a caregiver. Those are different risk levels and should not share the same token scope or session duration. For higher-risk actions, short-lived authorization and explicit re-consent are safer than permanent trust.

Healthcare teams also need to account for recovery edge cases. Account recovery, contact-center resets, and proxy re-linking are common attack paths because they bypass the normal login flow. That is where the portal and telehealth stack becomes a governance problem: if recovery rules are weaker than primary authentication, attackers target the weakest path. A practical program treats patient identity, delegated access, and downstream app tokens as one policy domain, not separate systems.

For organisations building around modern identity governance, the lesson is to design for least privilege, short duration, and auditable consent across every channel rather than assuming the portal boundary will contain the risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-4 Portal and telehealth access need least-privilege and session-aware authorization.
OWASP Non-Human Identity Top 10 NHI-03 Long-lived credentials and token misuse are core non-human identity risks in healthcare integrations.
NIST AI RMF Identity decisions for AI-assisted telehealth must be governed by risk, context, and accountability.

Inventory all portal, API, and integration secrets, then rotate or replace long-lived credentials.