Delegated and Proxy Access in CIAM: Let Carers and Attorneys Act Without Sharing Passwords

When a customer service has no way for a carer, parent or attorney to act for someone else, people share passwords, and the service loses its audit trail, its MFA and its ability to spot abuse. Patient portals, online banking, utilities, insurers and public services all serve customers who need help: a parent managing a child's account, an adult child helping an elderly parent, an attorney under a lasting or durable power of attorney, an executor closing a deceased person's accounts. This guide covers how to model proxy relationships as first-class objects, how to verify both the proxy's identity and their authority, how to scope delegation, how to audit and revoke it, and the abuse cases a design must withstand. It is for CIAM architects, product owners and fraud teams. The wider customer identity platform is covered in the Customer IAM (CIAM) Guide; this page goes deep on one capability it only introduces.

Key takeaways

• Delegation, not impersonation. The proxy should sign in as themselves and act on behalf of the account holder, so every action records both people. RFC 8693 draws exactly this line and gives the act claim to carry it in tokens.
• Verify identity and authority separately. Proving who the proxy is does not prove they may act; check the legal or consented basis (power of attorney, guardianship, parental responsibility, the holder's own consent) and record the evidence.
• Scope narrowly and time-box. View-only, transact, and manage are different grants; a proxy should almost never be able to change the holder's sign-in or recovery details.
• The account holder must be able to see and end it. Notifications, a visible list of who can act, and one-step revocation are the main defence against coercion and abuse by the proxy.
• Plan for relationship change. Children come of age, powers of attorney are revoked, carers move on and people die. Every relationship needs an end condition and a re-confirmation cycle.

Why shared credentials are the failure you are designing out

Without a delegation feature, the proxy uses the holder's username, password and often their phone for one-time codes. That causes problems on every axis.

• No attribution: logs show the holder doing everything, so disputes, fraud investigations and complaints cannot be resolved.
• Broken authentication: MFA protects nothing when the second factor is shared, and risk engines learn the proxy's device and location as "normal" for the holder.
• No scope: the proxy has every right the holder has, including changing contact details and closing the account.
• No revocation: ending the arrangement means the holder must change credentials they may not be able to manage alone.
• Abuse is invisible: financial abuse of older customers and coercive control look identical to normal use.

Account sharing is also a pattern fraud and account takeover programmes try to suppress, so the delegation feature should be the easy, legitimate route. See the Account Takeover Prevention Guide.

Proxy relationship types

Each relationship has a different source of authority, evidence and end condition. Model them as distinct types rather than a single "proxy" flag.

Scope follows authority. In healthcare, HHS guidance on the HIPAA Privacy Rule (45 CFR 164.502(g)) says a personal representative stands in the individual's shoes only to the extent of their legal authority: broad authority means treatment as the individual for all purposes, while authority limited to particular decisions covers only the health information relevant to those decisions. In England and Wales, a lasting power of attorney is either for property and financial affairs or for health and welfare, and an attorney cannot act until it is registered with the Office of the Public Guardian. A banking portal should not accept a health and welfare instrument as authority over money.

Verifying the proxy's identity and authority

Two separate checks happen at enrolment, and both outcomes are recorded on the relationship.

Identity of the proxy

• The proxy has their own account: proofed and authenticated in their own right, never through the holder's credentials. See the Identity Proofing and KYC Guide.
• Match assurance to what they can do: a proxy who can move money or read health records should be proofed at least to the level required of the holder. NIST SP 800-63A-4 applies the same principle to applicant references, people who vouch for an applicant (it requires minors to be supported this way): the CSP must proof the reference to the same or higher identity assurance level intended for the applicant, request evidence of the relationship where needed, and record the reference's use in the subscriber account.

Authority to act

• Consent-based: the strongest evidence is the holder granting access from their own authenticated session, choosing the scope and duration. Ask a confirmation question that makes coercion harder, such as a re-authentication and a short cooling-off period before high-risk scopes activate.
• Legal-instrument based: check the instrument's type, scope, registration and any restrictions. Where an official online verification route exists, prefer it to scanned paper. The Office of the Public Guardian service lets attorneys and donors share a one-page summary of an LPA registered in England and Wales on or after 1 January 2016 with organisations using an access code that GOV.UK says is valid for 50 days; earlier LPAs still require the registered paper LPA or a certified copy.
• Reliance on documents: HIPAA's verification rule (45 CFR 164.514(h)) requires covered entities to verify the identity and authority of a requester who is not known to them, and lets them rely on documentation that appears adequate on its face where reliance is reasonable. Other sectors have their own rules; build your process so the evidence and the reviewer's decision are stored with the relationship.
• Human review for high-risk relationships: attorneys, deputies and executors usually need a trained operations team, not an automated check, and those agents need tight controls of their own. See the Account Recovery and Help Desk Security Guide.

Scoped delegation design

Build the delegation as a relationship record with explicit scopes, not as a second login to the holder's account.

• Token design: issue the proxy a token whose subject is the account holder with an act claim identifying the proxy, or an equivalent custom claim, so every API sees both. RFC 8693 (OAuth 2.0 Token Exchange, a Proposed Standard) defines act for the current actor and may_act for parties authorised to become the actor, and says access decisions should use the current actor, not earlier ones in a chain. The OAuth Token Exchange and Delegation Guide covers the mechanics.
• Context switching: the user interface should show clearly whose account the proxy is acting in, and the proxy should switch explicitly between their own account and each account they manage.
• Time limits: consent-based relationships default to a fixed term (for example 12 months) with re-confirmation by the holder; instrument-based ones last until an end event but still get periodic checks.
• Multiple proxies: where an instrument says attorneys act jointly, the system should require both for the actions it covers, not let either act alone.

Minors and changing capacity

Children's accounts change over time, and the delegation must change with them.

• Age transitions: define what happens at each threshold in your jurisdiction and sector: parental access reducing, the young person gaining the right to approve or remove it, and full transfer at adulthood. Automate the change rather than relying on someone to remember.
• Confidential services: HHS guidance notes that a parent is not the personal representative where state or other law does not require parental consent and the minor consents to the care, where someone else is authorised by law to consent, or where the parent agrees to a confidential relationship. Portals must be able to exclude those records from a parent's view.
• Age assurance at sign-up: see the Age Assurance Guide for establishing age in the first place.
• Loss of capacity: a consent-based arrangement made while the holder had capacity may not be enough when they lose it; that is the point at which a registered instrument or court order is normally needed. Flag such accounts for review rather than letting a consent-based proxy quietly expand.

Abuse cases and how to counter them

Delegation features help vulnerable people and are also a tool for exploiting them. Design for these cases explicitly.

In healthcare, the HIPAA Privacy Rule lets a covered entity decline to treat someone as a personal representative where it reasonably believes the individual has been or may be subjected to domestic violence, abuse or neglect by that person, or that doing so could endanger the individual, and it judges that declining is in the individual's best interests. Build an operational path to suspend a relationship quickly when staff raise that concern.

Audit, notification and revocation

• Dual attribution in every log: record actor (the proxy), subject (the holder), relationship ID and scope used for every action, from the token claims, not just the session.
• Holder visibility: a page listing everyone who can act, their scope, when it started, when it ends and what they did recently.
• Notifications: notify the holder when a proxy is added, when scope changes and for high-risk proxy actions, unless the relationship type or a safeguarding decision means notifications would cause harm.
• Revocation triggers: holder revokes, proxy resigns, instrument revoked, death notified, age threshold reached, court order, safeguarding concern, or re-confirmation not completed.
• Revocation effect: end the relationship, revoke tokens and sessions issued under it, cancel pending proxy-initiated transactions where appropriate, and tell both parties.
• Bereavement: on notification of death, suspend consent-based proxies immediately and route to an estate process; an attorney's authority under a power of attorney ends with the donor's death.

Metrics

• Share of proxy activity performed through the delegation feature rather than shared credentials (estimate from device and behaviour signals on holder sessions).
• Median time to verify instrument-based relationships, and rejection rate by reason.
• Percentage of relationships with an end date or re-confirmation due date.
• Time from revocation trigger to token revocation.
• Safeguarding referrals and confirmed abuse cases involving proxy access.

Shared household accounts

Streaming, utilities, telecoms and retail often have one contract owner and several users. The same principles apply at lower risk: give each person their own login under the owner's account, let the owner set what each member can do (for example purchases, profile changes, payment methods), log actions per person, and let the owner remove members. Avoid a single shared password, which leaves the owner unable to remove one person without disrupting everyone.

Rolling out delegated access

1. Map the demand: analyse support contacts, complaints and shared-credential signals to find the relationship types customers actually need.
2. Agree policy with legal, safeguarding and fraud: relationship types, evidence, scopes, age thresholds, end conditions and abuse handling, per jurisdiction.
3. Build the data model: a relationship entity with type, parties, scopes, evidence reference, verification outcome, start, end and status.
4. Start with consent-based view access for adults, which needs no document checks, and measure uptake.
5. Add instrument-based relationships with an operations workflow and official verification where available.
6. Add transaction scopes with step-up, limits and monitoring once audit and revocation are proven.
7. Test abuse scenarios with fraud and safeguarding teams before each launch, and keep a feature flag to suspend new proxy enrolments if abuse spikes.

Small services can start with a simple invite-and-accept flow for consenting adults and handle legal instruments by exception. Large regulated organisations need the full model, an operations team and regulator-ready audit.

Framework mapping

Common failure patterns

• Proxy logs in as the holder: implementing delegation as a second password on the same account, so nothing distinguishes the two people.
• Identity checked, authority not: a well-proofed person with no right to act is given full access because their own identity passed.
• All-or-nothing scope: a carer who only needs to book appointments can also change bank details or close the account.
• No end condition: parental access persists into adulthood, or an attorney keeps acting after the donor's death because nothing triggered revocation.
• Proxies added through the support line: social engineers exploit a phone process that adds a "carer" without the holder's authenticated consent.
• Holder cannot see the arrangement: without a visible list and notifications, coercion and financial abuse continue unnoticed.

Practitioner checklist

• Model each proxy relationship type separately with its source of authority, evidence and end condition.
• Require every proxy to have their own proofed and authenticated account; never share the holder's credentials.
• Verify authority separately from identity and store the evidence and decision with the relationship.
• Carry the proxy in tokens (for example the RFC 8693 act claim) and log actor, subject and scope for every action.
• Define view, routine, transact and manage scopes; never delegate the holder's credentials or recovery details.
• Give the holder a visible list of proxies, notifications and one-step revocation.
• Automate age transitions and revocation on death, instrument revocation and re-confirmation lapse.
• Add cooling-off periods and monitoring for high-risk scopes, and a fast path to suspend a relationship on safeguarding concerns.
• Block support staff from adding consent-based proxies without the holder's authenticated approval.
• Test coercion, forged-instrument and takeover scenarios before launch and after every major change.

Standards and references

• IETF: RFC 8693 OAuth 2.0 Token Exchange
• NIST: SP 800-63A-4 Digital Identity Guidelines, Identity Proofing and Enrollment
• US HHS: HIPAA guidance on personal representatives
• eCFR: 45 CFR 164.514 Other requirements relating to uses and disclosures of protected health information
• GOV.UK: Using a lasting power of attorney
• GOV.UK: Use a lasting power of attorney online
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · OAuth Token Exchange and Delegation Guide · Identity Proofing and KYC Guide · Healthcare Identity Security Guide · Financial Services Identity Security Guide