They should replace informal password sharing with explicit delegated access tied to the actual relationship being represented. That means scoped permissions, visible account linkage, and reviewable authority for dependents or household members. Without that structure, privacy, accountability, and entitlement scope all become difficult to defend.
Why This Matters for Security Teams
Shared access in healthcare portals is often treated as a convenience problem, but it is really an identity and authorisation problem. When one login is reused by a spouse, parent, caregiver, or adult child, the portal loses the ability to prove who acted, under what authority, and for which patient context. That creates exposure across privacy, auditability, and entitlement scope, especially where appointment changes, prescription visibility, and message routing are involved.
Security teams should treat delegated access as a first-class governance model, not an informal exception. The operational goal is to bind access to a verifiable relationship, then scope that access narrowly enough to match care responsibilities. That aligns with broader NHI governance concerns described in the Ultimate Guide to NHIs and the control expectations in the OWASP Non-Human Identity Top 10, where identity scope and lifecycle discipline matter more than convenience shortcuts. In practice, many security teams encounter unauthorized visibility only after a family member has already used a shared credential to view or change information that was never meant to be broadly accessible.
How It Works in Practice
Effective governance starts by replacing shared passwords with delegated access records. The patient remains the primary account holder, but the portal issues a separate relationship-based entitlement for each caregiver or family member. That entitlement should define what the delegate can do, which patient records they can see, whether they can message clinicians, and whether they can act only under supervision or independently.
From a security perspective, this is closer to non-human identity governance than to consumer account sharing. Each delegate should have a unique identity, a clear approval trail, and a revocation path that is easy to execute when the relationship changes. Security teams should also log the relationship type, approval date, expiry, and any scope limits so audits can answer who had authority at the time of access. This is consistent with lifecycle discipline in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- Use explicit delegation workflows instead of password sharing.
- Bind each delegate to a named relationship and a specific patient record.
- Limit permissions by action, not just by portal login.
- Set expiry dates for temporary caregiving or household access.
- Review and re-certify access when care arrangements change.
Technical controls should include step-up verification for sensitive actions, event logging for every delegated action, and clear separation between patient-owned and delegate-owned communications. Where possible, policy should be enforced through central identity controls and reviewed against the control expectations in NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when the portal is built around a single household login and the organisation has no reliable way to distinguish convenience use from approved delegation.
Common Variations and Edge Cases
Tighter delegation controls often increase administrative overhead, requiring organisations to balance patient convenience against stronger privacy and audit requirements. That tradeoff becomes more visible in paediatric care, elder care, behavioural health, and emergency access, where the right answer is not always full visibility or zero visibility.
Current guidance suggests using different access models for different relationship types, but there is no universal standard for this yet. A parent may need broad access for a minor, while an adult child may only need appointment and medication coordination privileges for an older parent. In some cases, proxy access should be time-limited and tied to a documented care episode rather than left open-ended. The best practice is to design for revocation first, because family structures, guardianship status, and consent can change quickly.
One practical edge case is emergency access. Break-glass workflows may be justified, but they should be rare, strongly logged, and reviewed after use. Another is account recovery, where a delegate should not be able to reset credentials or alter contact details without additional validation. Where an organisation exposes broad third-party integration or patient messaging features, the risk profile moves closer to the visibility and entitlement problems described in The State of Non-Human Identity Security and the incident patterns in 52 NHI Breaches Analysis. In practice, the hardest failures appear when a portal allows proxy use to persist long after the care relationship has ended.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Delegated portal access needs unique identities and scoped entitlement, not shared credentials. |
| CSA MAESTRO | GOV-02 | Proxy access requires governed approval, scope, and revocation across the lifecycle. |
| NIST AI RMF | GOVERN | Patient-delegate access decisions need accountable governance and traceable oversight. |
| NIST CSF 2.0 | PR.AA-01 | Identity verification and authorization are central to distinguishing patient from delegate actions. |
| NIST SP 800-63 | IAL/AAL | Delegated access depends on reliable identity proofing and authenticators for both parties. |
Issue separate identities for delegates and remove any shared-login pattern from patient portals.
