Nobody plans for the identity that outlives its owner

An executor arrives at a bank with a death certificate and a court appointment and is asked for a password. Meanwhile the accounts nobody can reach are perfectly reachable by someone else. Death ends a life, and it does not end a single digital authority.

Picture the fourth week. The funeral is done, the casseroles have stopped arriving, and someone in the family has been handed a folder. Inside it is a death certificate, a copy of the will, and a letter from a probate court naming them executor. They are, in the eyes of the law, now authorised to gather and administer everything the deceased owned.

They open a laptop and start with the bank, because the bank feels like the serious one. The bank is helpful, in the specific way institutions are helpful when they have a process: mail the original death certificate, the court order appointing the executor, and a completed form, and allow six to eight weeks. Fine. Slow, but fine. That is a process built for this.

Then they try the email account, because the bank statements are in it, and so is the correspondence with the accountant, and so is a decade of photographs. The email provider offers a form. The form asks a series of questions the executor cannot answer, because the answers were in the head of a person who is dead. Somewhere in the flow it offers to close the account. It does not offer to open it.

Then they discover the rest. A password manager whose vault is encrypted with a key nobody has. A phone that is the second factor for eleven services and is locked. A brokerage that will talk only to the account holder. Two subscriptions still billing a card that is still working. A cloud storage account holding the only copy of the family videos, on a plan that will lapse in ninety days. A domain name renewing automatically, holding the family business website, on an account with an email address that is the locked email account. And, somewhere the executor will not find for another year, a small set of API keys and standing authorisations that let software continue to act in the deceased's name.

Every one of those is a separate institution with a separate process, a separate document requirement, and a separate answer. Several of them will end in a polite refusal. And while the executor works through them one by one, holding a court order that says they are entitled to all of it, an ordinary criminal with a copy of an obituary and thirty seconds of the deceased's voice from a wedding video has a materially easier time of it than the person the court appointed.

What actually happens to your accounts when you die?

Nothing. That is the honest and slightly startling answer, and it is worth sitting with, because almost everyone assumes otherwise.

There is no event in any of these systems called death. There is no signal that propagates. Your bank does not learn it from the hospital. Your email provider does not learn it from your bank. A death certificate is a piece of paper issued by a local authority, and it enters the digital world only when a human being carries it, one institution at a time, and persuades a support representative to act on it.

In the United States there is a partial exception worth knowing about: the Social Security Administration maintains death records that feed a widely used file, and certain financial institutions and government programmes check against it. That is genuinely useful and it is also narrow. It covers a subset of institutions, it has a lag, and it has never been intended as a general revocation signal for the internet.

So in the absence of a signal, every credential the deceased held remains exactly as valid as it was the week before. The password still authenticates. The saved card still charges. The OAuth grant still refreshes. The API key still works. If the person had configured software to act on their behalf, which a growing number of people now have, that software keeps acting, because it was never told either, and it has no way to find out.

This is the same structural problem we have written about in a workplace context, where authority survives an employee's departure because the departure is an event in one system and the authority lives in forty others. Death is that problem with the notification path removed entirely and the person who would have noticed permanently unavailable.

Why is the digital estate problem three problems, not one?

Most writing on this topic treats it as a single thing called digital legacy, and that is precisely why nothing gets fixed. There are three problems here. They have different victims, different timescales, and different remedies, and a mechanism that helps one can actively harm another.

Problem one: access, which is slow and maddening

The executor problem is a coordination failure. The legal authority exists. Probate courts issue documents specifically to establish that this person may act for the estate, and in the United States most states have adopted a uniform law on fiduciary access to digital assets, promoted through the Uniform Law Commission, which was written precisely to give fiduciaries a legal route to digital property. The law is, broadly, on the executor's side.

The implementation is not. Each platform built its own process at a different time for a different reason, and each one weighs the risk of handing an account to the wrong person against the cost of a family's grief, which is not a cost that appears on any dashboard. The result is a set of processes that are individually defensible and collectively unusable. The executor is not fighting a policy. They are fighting forty policies, none of which know about the others.

The practical consequence is delay, and delay is expensive in the specific way estates are expensive: professional fees accrue, assets sit unmanaged, and a house cannot be sold until someone can prove what is owed on it.

Problem two: the fraud window, which is quiet and cheap

Here is the asymmetry that ought to be a scandal and is instead a footnote. Between the moment of death and the moment each institution finally updates its records, the deceased is an unusually attractive target: an identity with real history, real credit, real accounts, and nobody checking the statements.

The window is long, it is measured in months rather than days, and it is not a secret. Obituaries are published. They carry a full legal name, a date of death, often a birth date, a place of residence, and the names of surviving relatives, which is a set of fields that maps uncomfortably well onto the knowledge based questions some institutions still use to verify a caller.

Voice makes it worse. Any funeral livestream, wedding speech, podcast appearance or voicemail greeting is now enough raw material for a convincing clone, and the cost of producing one collapsed over 2024 and 2025. A contact centre agent asked to verify a caller by voice is being asked to do something the technology no longer supports, which is the argument we make at length about voice deepfakes in the call centre. When the account holder is dead, that problem acquires a nasty edge: the one person who would have called back to say "that was not me" cannot.

Research firms tracking publicly reported deepfake fraud have put losses in the billions, with Surfshark's 2026 research reporting roughly 1.65 billion dollars in 2025 alone and around 3.7 billion documented since 2020. Those are aggregate figures across all deepfake fraud rather than a measure of fraud against the deceased specifically, and we are not aware of a credible published figure isolating that category. We are reasoning here from the structure of the opportunity rather than from a count, and it is only fair to say so.

Problem three: the likeness, which is new and largely unlegislated

The third problem did not meaningfully exist five years ago. A dead person's face and voice are now cheap to reconstruct from public material, and the uses divide into two categories that the law treats very differently.

One is fraud against the family, which is straightforwardly criminal in most places: a cloned voice used to extract money from a grieving relative, or a synthetic video used to lend credibility to an investment scheme. The other is commercial or expressive use of a deceased person's likeness, which sits in the genuinely unsettled territory of post mortem publicity rights. Those rights vary enormously. Some jurisdictions recognise them for decades after death, some recognise them briefly, and some do not recognise them at all. In Europe, data protection law is of limited help here for a structural reason worth understanding: the General Data Protection Regulation states in its recitals that it does not apply to the personal data of deceased persons, while leaving member states free to make their own rules, which they have done inconsistently.

We are going to be disciplined about this problem. It is real, it is growing, and a signature on a device does not fix it. Identity infrastructure can make it harder to impersonate a dead person to an institution. It cannot stop somebody generating a video. Anyone who tells you otherwise is selling something.

Why do platform legacy features not add up to a solution?

They are good features. That should be said first, because the people who built them were trying to solve a real problem with genuine care, often before anyone else was thinking about it.

Apple's Legacy Contact, introduced in 2021, lets you nominate people who can request access to your account data after your death, with an access key and a death certificate. Google's Inactive Account Manager takes a different and rather elegant approach: rather than trying to detect death, it detects inactivity, and after a period you choose it can notify contacts and share data or delete the account. Meta offers memorialisation, which freezes an account into a remembrance state, and allows a designated legacy contact limited abilities.

Each of these is sensible. None of them compose. Consider what the executor actually holds after using every one of them: access to some Apple data, possibly some Google data if the deceased configured it and the inactivity period has elapsed, and a memorialised Facebook profile. They still have no route to the bank, the brokerage, the domain registrar, the password manager, the accounting software, the two subscription services, or the standing authorisations. And critically, none of these features revokes anything anywhere else. Apple cannot tell your bank. Google cannot cancel your API keys.

The OpenID Foundation put this on the standards agenda with work published in 2026 under the title The Unfinished Digital Estate, which argues that the absence of a shared approach to deceased persons' accounts creates risk across platforms and jurisdictions. We think that framing is right, and the fact that a standards body reached it independently is a reasonable signal that the gap is structural rather than a matter of individual platforms being lazy.

What is the actual missing primitive?

Here is the reframing that we think matters, and it runs against how the topic is usually discussed.

The digital estate problem is presented as an access problem: how do heirs get in. That framing produces solutions like password sharing, sealed envelopes, and estate planning services that store credentials, all of which are attempts to hand over secrets. Handing over secrets is a bad mechanism. It is bad while you are alive, because it creates a copy of your credentials in someone else's custody. It is bad afterwards, because a shared password gives the recipient everything or nothing, with no scope, no expiry, and no record of what they did.

The deeper problem is not access. It is revocation. The reason the fraud window exists is that death does not revoke anything. The reason agents keep acting is that death does not revoke anything. The reason the deceased's accounts remain a live attack surface with no defender is that death does not revoke anything. Access for the heir and revocation for the deceased are the same event viewed from two sides, and every existing mechanism addresses only the first half.

So the primitive we want is one object that does both: an instruction, signed by the person while they are alive and capable, that names who inherits which authority, under what scope, activated by a verifiable attestation of death, and which at the moment of activation revokes the authority the deceased still holds.

Think of it as the difference between leaving your house keys in a drawer and changing the locks the day the estate passes. The drawer is what we have now. Everyone hopes the right person opens it first.

What would a successor delegation look like in practice?

Manav's delegation model already has most of the pieces, because they were built for a different purpose: letting a human grant scoped, time bound, revocable authority to software. A delegation is a signed object naming a delegate key, the actions it may take, constraints on when and how, and a revocation identifier. Anyone holding the published verification key can check it offline, without calling us, which is the property that matters here because the person who would have vouched for it is gone.

A successor delegation is that same object with an activation condition and a revocation instruction attached. Conceptually it looks like this.

{
  "type": "successor-delegation",
  "root":     "did:manav:z6Mk...9f2",     // the person, signed while alive
  "delegate": "did:manav:z6Mk...c41",     // the named successor
  "scope": {
    "actions":   ["account.read", "account.close", "asset.transfer"],
    "resources": ["bank:*", "broker:*", "storage:family-photos"]
  },
  "constraints": {
    "activation":  "death-attestation",
    "attesters":   2,               // e.g. registrar + one named person
    "notBefore":   null,            // inert until activation
    "notAfter":    "2044-01-01T00:00:00Z"
  },
  "onActivation": { "revokeRoot": true },
  "revocationId": "rv:8f31...",
  "sig": "ed25519:..."
}

The verification a relying party performs is deliberately boring, which is the point. It is arithmetic, not judgment.

verify(delegation, presented_by, action):
    assert sig_valid(delegation, published_key(delegation.root))
    assert action in delegation.scope.actions
    assert presented_by == delegation.delegate
    assert now() < delegation.constraints.notAfter

    act = activation_record(delegation.revocationId)
    assert act.present                       # inert without it
    assert act.attester_count >= delegation.constraints.attesters
    assert sigs_valid(act, trusted_attesters)

    # and the other half, which is the part everyone forgets
    assert root_revoked(delegation.root, since=act.timestamp)
    return ALLOW

Read the last assertion again, because it carries the argument of this entire post. The relying party does not merely check that the successor may act. It checks that the deceased may not. Those two facts arrive in the same object, at the same moment, from the same signature, which is exactly what no current mechanism does.

The activation record is where the honest engineering difficulty lives, and we will come to that in the limits. But note what the design deliberately avoids: it does not require a central registry of dead people, it does not require every institution to integrate with a government death database, and it does not require the successor to hold the deceased's secrets at any point. The successor holds their own key. They always did.

How do the available mechanisms compare?

The row that tends to surprise people is the power of attorney one. A durable power of attorney is the instrument most families assume covers this, and it is a genuinely valuable thing to have, and it ceases to be effective at the moment of death. The authority to act for a living person and the authority to act for an estate are different authorities granted by different instruments, and the gap between them is measured in the weeks it takes a court to issue the second one.

What about the AI agents?

This section would have been speculative two years ago and is now simply an inventory question.

People increasingly grant standing authority to software: an assistant with access to a calendar and inbox, a trading rule with a spending limit, a home system with a payment method, a research agent with API keys. Each of these is authority that flows from a human and continues to execute without them. We have written elsewhere about the difficulty of enumerating that authority even for a living person, in the authority graph problem, and about why revoking it in one place does not revoke it anywhere else.

Death makes both problems worse in a specific way: it removes the only party who knew what was delegated. An executor cannot revoke an agent they cannot see, and the agent has no mechanism for noticing that its principal no longer exists. It will keep executing until a payment method fails or a token expires, which may be a long time.

If authority is granted as a chain rooted in a human key, this becomes tractable, because revoking the root invalidates everything beneath it in one operation, and the executor can enumerate the chain rather than guessing. That is the same property described in the delegation chain post, applied at the end of a life rather than the end of a task. It only covers authority that was granted that way, which today is almost none of it. We think that is an argument for granting it that way, not an argument that the problem is solved.

Honest limits

This is a design proposal. Manav has shipped no estate features, and we want to be precise about the distance between what exists and what is described above.

• Conditional activation is not shipped. Today Manav can sign delegations, express scope and expiry, and revoke a root. Activation triggered by a multi party death attestation is roadmap, not product. The code above is a design sketch, not an API reference.
• Adjudicating death is not a cryptography problem. Somebody has to attest, and attesters can be wrong, coerced, or conflicted. Requiring two independent attesters raises the bar and does not eliminate the risk, and a premature activation is a serious harm: it would revoke a living person's authority. Any real design needs a challenge period and a route for the living principal to reverse it, which adds latency exactly where families want speed. That tension is genuine and we do not think it has a clean answer.
• Legal effect belongs to succession law. A signed instruction is evidence of intent. It is not a will, it does not override succession law, and succession law differs enormously between jurisdictions and sometimes between states within one country. In a contested estate, a court decides. A technical artifact that claimed otherwise would be both wrong and dangerous. Nothing here is legal advice.
• Coverage is the whole game. A successor delegation is worth exactly as much as the number of relying parties that check it. Today that number is small. This is the standard cold start problem and it is why the OpenID Foundation's standards work matters more to this outcome than any single vendor's product.
• It does nothing about likeness. Preventing a synthetic video of a dead person is not an authority problem and this mechanism does not touch it.
• It does not help the unprepared. Every mechanism in this post requires the deceased to have done something in advance. For the many people who did not, the executor is still facing forty processes and a stack of paper.

What to do this month

All of the above is infrastructure that mostly does not exist yet. Here is what a person can actually do now, and it is more effective than it sounds, because the bar is currently so low.

1. Write the inventory, not the passwords. A single document listing every institution, account type, and roughly what is in it. Not credentials. An executor who knows where to look can use legal process; an executor who does not know an account exists cannot.
2. Configure the legacy features you already have. Apple Legacy Contact and Google Inactive Account Manager take a few minutes each and are the only mechanisms on this list that work without a lawyer.
3. Name a person in your password manager's emergency access feature if it has one, and check the waiting period is one you are comfortable with.
4. Find out where the second factors live. If eleven accounts recover through one phone, the phone's passcode is the estate's single point of failure. Make sure someone can get into it, through a legal route rather than a sticky note.
5. List your standing authorisations. Every API key, connected application, and agent with a spending limit. This is the section nobody writes and the one that will still be running in two years.
6. Talk to whoever will do this work. The single highest value item on this list is that the executor knows they are the executor and knows where the inventory is.
7. Ask your institutions what they do. If enough customers ask a bank how it handles a deceased customer's standing authorisations, it becomes a product question rather than an operations one.

If you build systems rather than plan estates, the equivalent list is shorter: find out what your product does when a user dies, find out whether anything in it revokes, and read the documentation on scoped delegation and revocation with that case in mind. You can also see what a signed, offline verifiable authorisation looks like in the signing demo.

Frequently asked questions

What happens to my online accounts when I die? Legally, they form part of your estate and your executor is generally entitled to administer them. Practically, nothing happens automatically. No system is notified, your credentials keep working, and your executor must approach each institution separately with a death certificate and court documents. Several platforms will close an account but not open it.

Does a power of attorney cover my accounts after death? No, and this catches many families. A power of attorney is authority to act for a living person and it ends at death. Authority over the estate comes from the will and from the court, through a court order appointing an executor or administrator, which takes time to obtain. The gap between the two is one reason estates stall in the first weeks.

Why is a dead person's identity attractive to fraudsters? Because the account holder cannot notice. Records take months to update across institutions, obituaries publish exactly the fields used in knowledge based verification, and public recordings supply enough audio for a convincing voice clone. The window between death and record updates is long, quiet, and well understood by the people who exploit it.

Can I delegate authority that only activates when I die? Not yet, in any general way. Some platforms offer legacy contacts or inactivity based handover within their own ecosystem. A cross institution version, where you pre sign a scoped delegation that activates on a verifiable death attestation and revokes your remaining authority at the same time, is a design proposal rather than a shipped product, and it is on the standards agenda.

Should I write my passwords down for my family? It is better than leaving nothing, and it is a poor mechanism. A shared credential list grants everything or nothing, goes stale, cannot be scoped or expired, leaves no record of who did what, and creates a second copy of your credentials while you are still alive. Prefer an inventory of where accounts exist, plus the legacy features each platform provides.

What happens to AI agents and API keys that were acting for someone who has died? They continue. Software has no way to learn that its principal has died, so standing authorisations keep executing until a payment fails or a token expires. Because nobody but the deceased knew what was granted, an executor usually cannot enumerate them, which makes this the longest lived and least visible part of a digital estate.

Does GDPR protect a dead person's data? Not directly. The regulation states in its recitals that it does not apply to the personal data of deceased persons, while allowing member states to legislate their own rules, and they have done so inconsistently. Protections for a deceased person's likeness come instead from post mortem publicity or personality rights, which vary widely by jurisdiction.

Sources

1. OpenID Foundation, standards work and publications including 2026 material on deceased persons' accounts: openid.net
2. Uniform Law Commission, uniform legislation on fiduciary access to digital assets: uniformlaws.org
3. General Data Protection Regulation, Recital 27 on the personal data of deceased persons: gdpr-info.eu
4. Apple, Legacy Contact and account access after death: support.apple.com
5. Google, Inactive Account Manager: myaccount.google.com/inactive
6. Meta, memorialised accounts and legacy contacts: facebook.com/help
7. Surfshark research on reported deepfake fraud losses, 2026: surfshark.com/research
8. US Social Security Administration, death record programmes: ssa.gov

Every mechanism we have for digital death is about letting the family in. None of them is about locking anybody else out, and that is the half that criminals use.