Where the Account Outlives the Owner: Designing a Verifiable Handover for UK Estates

An executor's work in the UK has always been administrative. There is a grant of probate to obtain, an inheritance tax account to settle, institutions to notify, and a household to dismantle or preserve. What has changed is the shape of the estate. Alongside the house and the savings account sit an email address that receives password resets, a cloud photo library that may be the family archive, a domain name that hosts a small business, marketplace seller accounts, and a chain of monthly subscriptions that will happily continue charging a card that has not yet been cancelled.

The service design problem is not that digital assets are new. It is that most products still assume the account holder is alive, present, and able to authenticate. Bereavement is handled as an exception path: a generic contact form, a request for a death certificate, a promise to respond within ten working days. For the person doing the work, that is not an edge case. It is the whole task.

The account that outlives its owner

UK data protection law is often assumed to solve this. It does not. The UK GDPR does not extend to the personal data of deceased persons, so there is no statutory subject access right for an executor to rely on. Data protection therefore offers little procedural guidance, and services are left to interpret their own contracts and policies. That discretion is precisely why the interface matters. When the law is silent, the product becomes the policy.

Too often, that policy is improvised. A support agent asks for a death certificate by email. A form requests the executor's address, date of birth, and relationship to the deceased, then routes them to a password reset they cannot complete. A subscription continues because the only cancellation route sits behind a login that no one can legitimately perform.

Bereavement is not a password reset

The most common anti-pattern is the shared credential. An executor is advised, informally, to log in as the deceased using a password found in a notebook or a password manager. This appears compassionate and is quietly corrosive. It creates an unaudited session under a false identity, undermines the service's own terms, exposes the executor to suspicion, and puts every other account protected by that email address at risk. It also compounds grief with the anxiety of doing something technically and legally ambiguous.

The second anti-pattern is forcing the executor to become a customer. Requiring a new account, a mobile app, and two-factor authentication before a bereavement request can even be submitted adds friction precisely where capacity is lowest. The third is the telephone-only route with limited hours. Grief does not arrange itself around a contact centre rota.

A protocol, not a postbox

UK public services already have Tell Us Once, which notifies a range of government departments after a death. The financial sector has the Death Notification Service, which lets participating banks and building societies be told once. Consumer digital services have no equivalent. Each product builds its own bereavement inbox, and each executor repeats the same labour.

A better model is a verifiable notification event: an assertion, issued once by a trusted party and accepted by many services, that a death has been registered and that a named person has authority to act. The assertion need not carry the full estate. It should carry scope: who is notifying, what they are entitled to do, and for how long. Solicitors, registrars, and probate services already produce evidence; the missing layer is a standard way for a digital service to verify it without demanding a fresh PDF upload each time.

This is not a call for a single national database of the dead. It is a call for a sector protocol, closer in spirit to open banking consent than to a central register: signed, scoped, revocable, and auditable.

States, not switches

Digital inheritance is usually framed as a binary: delete the account or memorialise it. Neither is sufficient. Product teams should model the account lifecycle explicitly. An account can be active, notified, restricted, memorialised, transferred, or closed. Each state should have defined capabilities.

Memorial mode, for example, is not one feature. It may mean a read-only archive for family, a tribute surface for friends, a prohibition on new logins, and a scheduled deletion date. Executor access is narrower still: the ability to download a copy of data, cancel a subscription, transfer a domain, or close a seller account, each with its own proof threshold. High-value assets may warrant two-person verification or a delay period. Low-risk actions, such as stopping marketing email, should not require probate.

The interface should show the state plainly. Executors need to know what has been done, what remains, and who is responsible. A status page is not administrative decoration; it is the difference between a process that can be completed and one that quietly stalls.

Verification without surveillance

Proof of death and proof of authority are different things. A death certificate establishes the former; a grant of probate or letters of administration establishes the latter. Asking for both at the first contact is often disproportionate. A graduated approach is more respectful and more secure: accept a notification with minimal evidence, restrict the account, then request stronger proof only for actions that carry risk.

Access should be purpose-bound and time-bound. A one-time link is preferable to a password. An audit log visible to the executor is preferable to an opaque back office. Where verification requires identity checks, offer alternatives that do not assume a smartphone, a scanner, or fluency in English. Bereavement is not a Know Your Customer maze, and grief is not a justification for collecting more data than the task requires.

Designing for the person who is not your user

The executor may be a spouse in their eighties, a dyslexic adult child, a professional solicitor, or a friend named in a will. They are not your typical user, and they did not choose your product. Plain language, save-and-resume, generous session times, and no countdown timers are baseline requirements. Avoid repeated confirmation dialogues that read as suspicion. Avoid retention dark patterns dressed as condolences. Avoid asking someone to "upgrade to Premium" while they are trying to close a dead relative's account.

Account holders should also be able to record a legacy contact or executor in advance. That feature must be revocable, verified, and narrowly scoped. It must not become a backdoor, and it must not silently expire when circumstances change. A legacy contact is a designation, not a spare key.

The handover is a service surface

Bereavement journeys deserve the same operational discipline as checkout or onboarding: named ownership, service-level targets, accessibility testing, and metrics that measure completion rather than conversion. Track time to resolution, abandonment, and repeat contact. Research with bereaved executors, ethically and at a distance from the acute period. Publish the process in plain English, including what proof is needed and what cannot be done.

In 2026, as estates become digital by default, the executor's login is no longer an afterthought. It is a test of whether a service can recognise that its account holder is also a person with a life, a death, and an aftermath. Dignity, in this context, is not a memorial page. It is a verifiable, narrow, auditable handover that does not ask the grieving to impersonate the dead.